Diego Profile picture
Apr 9 β€’ 32 tweets β€’ 13 min read
I originally used a WordPress site for my blog to get bootstrapped as fast as possible.

I am now going to design and develop my own site πŸš€. This thread is an open resource to document the process. I plan on updating it regularly.

#BuildInPublic #LearnInPublic

1 / 🧡
Tech stack:

>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 /🧡 Image
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/🧡 ImageImage
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/ 🧡 Image
>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/ 🧡 Image
>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:

9/ 🧡
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.

And all ready to go in markdown!

11/🧡 Image
This is the repo: github.com/diballesteros/…

But the posts cannot be 1:1 so I changed their names, added some frontmatter with more details.

New and improved posts:
github.com/diballesteros/…

12/🧡
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.

Took some inspiration from:
github.com/Girish21/speed…

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/🧡 GitHub actions
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/🧡 404 page
I'll probably revisit this later but the landing page is looking good

SSR makes such a huge difference.

21/🧡 100 lighthouse
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.

#buildinpublic

22/🧡
After that finally started working on processing the markdown. The compiled code already exists in the database thanks to mdx-bundler.

Tailwind helps out with the styling with the prose utility

23/🧡 compiled page from mdxtailwind prose configuration
I really wanted to add a table of contents that scrolls with the content and highlights the current section. This took me longer than I thought.

I initially tried generating the table of content at runtime from the existing headers. This was very wonky and didn't work.

24/🧡
It ended up being way easier to just generate it when first compiling the MDX with markdown-toc.

Couldn't find types for it so had to fall back on ts-ignore. This is so much faster and easier to manage.

25/🧡 Generating table of content...
Before continuing with blog posts I decided to quickly set up a loading state when transitioning inbetween pages.

26/🧡
Nothing too big today. Just used highlight.js and and oembed to style code blocks and embed codesandbox/youtube respectively.

(Both at MDX compile step)

27/🧡 ImageImageImage
Continuing to work through the blog posts. Added in all the meta tags and SEO stuff:

With Remix its just exporting a single function from the route.

28/🧡 ImageImage
Added copy/paste functionality to the pre-compiled codeblocks. Got to use the new React 18 hook useId.

29/🧡
Used Remix's resource routes to integrate with a Twitch webhook. So if i ever go online my page's button changes.

Might make a blog on how to set it up later

#LearnInPublic

30/🧡 live streamwebsite onlineoffline streamstream offline in webpage
First version of the site is out now.

Still got a lot of iterating to do to fix up some small style errors and bugs. But I like the progress so far.

relatablecode.com

β€’ β€’ β€’

Missing some Tweet in this thread? You can try to force a refresh
γ€€

Keep Current with Diego

Diego Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @relatablecoder

Mar 8
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.
Read 5 tweets
Mar 3
One question I've received quite often is

"How to take into consideration UX?" (user experience) πŸ§‘β€πŸ’»πŸ‘©β€πŸ’»

Here are some things I've learned along the way.
1. Users aren't programmers (normally)

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.
Read 7 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us on Twitter!

:(