Coding with Callie

https://lnkd.in/eVgQAf3g

There are two users that I’m keeping in mind while developing the Coding with Callie website builder: 👩🏻💻 The end user that will be viewing the final content 👩🏻💻 The admin that creates that content I don’t want either user to have a bad experience on the website, so it was clear that I needed a draft-mode/publish feature to make sure the end user isn’t witnessing all of the edits the admin makes on the website before they are ready to make those changes live 💡 When an admin adds a page to their website, a NULL value is added to the ‘publish_date’ column in the database. The end user will have no idea that the new draft page even exists! The admin, however, will see the page appear in their menu (along with a little draft icon) and have the ability to edit the page details and add content to it 📝 While the admin is making their changes, the new data is saved in ‘draft’ columns of the database. Once the admin is ready to publish the page, they can click the ‘Publish Page’ button on the UI. The backend will then replace the published data with the draft data and set the ‘publish_date’ or ‘modify_date’ column based on whether or not this is the page’s first publish 🚀 At this point, the user can see the new page and its content! What do you think?! 🤔 In-depth demo + code walkthrough in comments 🎥

https://lnkd.in/ev-ej_hx

Eeekk! We’re finally getting to the fun part of the Coding with Callie website builder: adding a page 🥳 What seems like a pretty simple CRUD operation had a few gotchas during development... 😅 Updating the router after a page is added In past projects, my router and all of its routes were hard coded in the ‘main.tsx’ file of my application. Each route was associated with a component to load when the user navigated to that route. This works fine with routes loaded from the database, but it doesn’t quite work when you add a NEW route from the UI. In order to see that route/page, you would need to hard refresh the application to update the router 🥸 That doesn’t sound like a good user experience to me, so I had to get a little creative and wrap my router within a PageProvider that holds the context for my pages. That way, if any new pages are added, I can update my pages context and that update will trigger my router to reload all of my dynamic routes with the new page included 👩🏻💻 😅 A page must have a creator id When I first wired up the login functionality, I only saved the user’s username in my access token’s claims. When trying to create a page, however, I realized that I needed a user ID 😬 So, I had two options: use the username from the auth middleware to do a DB query for the user ID OR save the user ID during the login process so it can be pulled during the auth middleware and used to create the page 🤔 I went with the claims option because it will be faster (no time wasted querying the DB) and adding an arbitrary id to my claims will not affect security ⏲️ 😅 Okay, this one isn’t really a gotcha…but, I hate writing forms and had to write one for this task Instead of reinventing the form every time I need one, I took some time to create a reusable form component that takes an object of initial values and uses that object to create the input elements and standardize the onChange and onSubmit handlers 💡 To create a form, I only need to come up with the initial values object, the route I want my form to POST to, the action I want my form to take on response from the API, and a heading for my form’s UI 🍳 What do you think?! 🤔 Code walkthrough in comments 🎥

Need some default data in your database?! Seeding for the win! https://lnkd.in/e3N5dKDg

For my Coding with Callie website builder to function properly, an admin user (aka me), a home page, and a wild card page need to exist in my database 👩🏻💻 So, I wrote a Seed function that my Go API calls when it starts up to create everything automatically 🌱 ✅ It pulls my admin password from my environment variables, hashes that password using bcrypt, and then adds an admin user to the Users table. ✅ Then, it creates a published home page so that end users have something to see immediately when they load ‘www.coding-with-callie.com’. ✅ Finally, it creates a wildcard page so that any other route an end user types into their browser shows a ‘Page Not Found’ component. A potential issue with this plan is that we only want the Seed function to add these items if they don’t already exist. I didn’t want to make extra database calls to check for an admin user, home page, or wildcard page before first; so, instead, I added a unique constraint on the username and email columns in the Users table and the menu_name and path columns in the Pages table 🙅🏻♀️ Then, I added ‘ON CONFLICT (<columns with unique constraints>) DO NOTHING’ to my SQL commands. This way, my Seed function works as I intended and only adds the data I want to the database one time 🥳 What do you think?! 🤔 Code walkthrough in comments 🎥

Coding with Callie website builder progress 🥳👩🏻💻 I can log in with my sneakily hidden login button, see my draft pages, and log out 💃🏼 What do you think?! 🤔

Log in using HTTP Only cookie! https://lnkd.in/eJCz4Y5t

Last week, Egor Ushakov brought up a solid point about my website builder: if I were using an HTTP only cookie, I wouldn’t be able to access my cookie with code on my UI before deciding whether or not to make an API request 💡 I thought I was setting an HTTP only cookie, so this stumped me a bit at first 🤔 Then I realized that using Postman to login was the issue…well kind of. My ‘/login’ route was setting as an HTTP only cookie with the JWT, but it was also returning the access token to the client. I was copying the returned token and pasting it into a regular cookie in the browser. That cookie was accessible with JavaScript on my frontend 🤦🏻♀️ So, I had a few options: 👩🏻💻 Return the entire cookie from the ‘/login’ route and manually save that in the browser 👩🏻💻 Just code a login form and stop being lazy I decided to go with option 2 and wired it up this weekend 💃🏼 Now, I can log in and log out safely directly from the UI. I even used Egor’s workaround of setting an additional cookie that can be accessed with JavaScript to know whether or not an access token exists before making API requests. Thank you for commenting, Egor! I really appreciate the feedback. What do you think?! 🙋🏻♀️ Video walkthrough in comments 🎥

I’ve been marathon coding since I got off work yesterday 🥰 The good news: I’m having so much fun and got a tonnnn done The bad news: I have majorly deviated from my sprint plan 🫣😅 What is everyone else working on this weekend?