>React: favorite library for UI management
>Remix: blazingly fast, progressive enhancement, and first-class support for react
>Tailwindcss: Small bundle size, easy to use, great docs
2 / π§΅
>Fly.io: is just simple to set up and comes integrated with Remix's pre-built indie stack.
>Prisma: Amazing ORM
>SQLite: simple database
>Github as CMS: Open source my blog so others can contribute to articles and fix typos π inspired by @\kentcdodds
3 / π§΅
>Vitest - Extremely fast test runner, will use for my unit tests
>Cypress - E2E testing, actually fun to create tests with this framework
>MSW - will mock all services so I can work offline if needed (again heavily inspired by @\kentcdodds) kentcdodds.com/blog/how-i-buiβ¦
With that out of the way, I went straight to setting it up. Remix has a cool adjacent feature: github.com/remix-run/indi⦠comes pre-built with testing, authentication, deployment, styling, etc.
Easy first pick to quickly get bootstrapped.
4 / π§΅
Folder structure comes next, Remix uses routing based on the folder structure. So the actual pages will go in routes
But for the actual app itself, It'll be something like this. My API calls will go in models. Components in components. Commonly used Assets in Assets.
5 /π§΅
I personally prefer keeping globally-used hooks in their own folder. Utils contain utility functions and a ton of the code used to refresh and pull my content from Github (more on that later).
Constants will contain the names of my routes and commonly used variables
6/π§΅
I wanted something nice to look at as I designed my page so first I wanted to build my ideal navbar. I've always loved the more minimalistic look. Especially for a blog. The posts should be the highlight.
Let's break down every section.
7/ π§΅
>Blog - Duh this is a blog site
>Snippets - useful coding snippets that I just use on a daily or weekly basis but don't merit a blog post
>Free Stuff (name pending) - I plan on including some cheatsheets and resources I've made
8/ π§΅
>Stream- I do want to stream on either youtube or twitch. I'm a bit nervous about it but I consume so many streams anyway it's something I've always wanted to do. (Might just end up taking it out π )
>Dark mode toggle - Here's how it looks:
I do want to animate the main header as well. This is the first iteration. Simple typing-like animation.
I don't really like it and plan to change it to something cooler ....but I have no ideas.
10/ π§΅
With a simple header out of the way (changes pending) I now started to migrate my blog. I had been crosspoting to hashnode and they have a nifty little exporter to GitHub.
Now comes the more difficult part. Everytime anyone makes a change to the markdown files the repo should automatically make the changes to the flyio DB.
And began constructing something similar for my posts
13/π§΅
Why is this necessary?
Similiar to the two other repos above. I'm using mdx-bundler and saving the response cache the compiled mdx.
Also I want to keep the front-end for the page private but the posts public.
14/π§΅
The GitHub actions in question. One to refresh all content if necessary and the other to update whenever a new push is made to main.
This will save a ton of time and writes to the DB (hopefully)
15/π§΅
Finally getting to the frontend (my favorite part). #buildinpublic
Mocked up how my post previews are going to look like on the front page. Subject to change but I like it initially:
16/π§΅
The structure should be something like this:
Navbar
Newsletter / Hero
Featured Posts
Testimonials
Footer
Times like this makes me wonder if I should dedicate some time initially to Figma. π
17/π§΅
Definitely want to have some fun with animations as well. But I'm making sure to disable them where prefers-reduced motion is enabled (Always important!)
Heres the first iteration of the subscription button for reference:
18/π§΅
Continuing to work through my main blog page. Got some sweet filter animations going.
Although I'll probably take them out #buildinpublic
(they all have the same image as a placeholder π )
19/π§΅
Not that big of an adjustment today. Added the error handling for a 404 page.
Remix makes this super simple, just a few lines of code in the end.
20/π§΅
I'll probably revisit this later but the landing page is looking good
SSR makes such a huge difference.
21/π§΅
Did a small redesign on the the way blog posts look like. Did not like the borders.
And added two buttons I would appreciate on tech blogs to copy links and open in new tab.
I often get messages asking about how to go about refactoring code and when its necessary
The following are some tips I've learned along the way. π
Before refactoring I typically like to take stock of everything that the code touches and see if any tests are already written for that code.
This so I can understand the larger implications of any change.
If the original code already works I try not to rewrite absolutely everything. Not only is this a huge timesink but it can even introduce more bugs in the end.
Incremental refactors are superior and easier to test.
When you ask yourself what would the user do its good to remember that most users aren't programmers and don't think that way.
2. Keep in mind that a user usually uses the app in the same way, consistently.
Some common things that can be noticed is that users typically tend to complete tasks in the same order and "mistakes" (bugs really) happen in the same places.