Welcome to day nine of the useaffiliates.com build log! This series covers my journey of building a business from scratch in public. If you missed day eight, you could check it out here. I also uploaded today's Twitch stream to YouTube if you want to watch the replay.
Last week I wrote an update about making some internet money, well today I am so proud to say that this trend continues! I am officially making some MMR with Twitch subscriptions. Once the first person subscribed, two more followed! 🚀
Two weeks ago, I imagined that becoming an affiliate (not even gaining subscribers) was something two months into the future. It's so fascinating to experience this all.
I appreciate your support! Sending you good vibes!
While last week was a lot of fun, I feel like I could have gotten more done. Creating content and streaming takes a lot of time, but especially during my streaming hours, I feel like I can get a lot more work done.
When watching my footage back, I noticed that I was freewheeling around too much after designing and setting up the project.
This morning I decided to clean the kanban board, which you can view here, and merge todos into EPICS (I guess). This means that I now split the project up into a couple of more significant milestones, consisting of multiple smaller todos, which makes it easier for me to make progress on the application by tackling one of these big tasks one at a time.
After working with this system today, I can say that it already feels like I am making way more progress. Even if I am stuck on something, I can work on another todo from the list. This is great since now I don't feel bad anymore for leaving something for the next day, since I can still show you guys some progress!
My god, this was a pain in the ass to implement. I took some time before the stream today (sorry) to dig into the documentation of SWR and figure out why I couldn't get it set up the way I wanted it to.
If I opted to go for client-side fetching only, this implementation would be a breeze. However, I want to serverside render, or now statically generate, the first 12 rows of the listing. This is great for SEO and UX since users don't have to wait around for the first programs to load.
After refactoring everything inside of a React hook, I finally implemented this feature and passed
initialData as an
fallbackData option value for
useSWRInfinite. Now that's not all; to make this work without error, I had to wrap the
initialData into an array that has the same format as the SWR results. While this is a bit cumbersome, I don't mind it since I don't have to change my API implementation, and I can do it from the hook.
Finally, it all worked! 🚀 ... Until someone in my Twitch chat asked me, "why are you fetching programs two times" as it turned out, SWR by default (#!%*) revalidates your first page, and you have to disable this via
revalidateFirstPage: false. It's a handy feature, but why enable it by default? Or highlight it a little better in the documentation, because it's not obvious that it isn't a bug when you watch your network tab. 😅
After all these years, it works as intended now! Okay, that's a little overdramatic, but it took me a few more hours than I had anticipated and feel were needed.
After implementing the data fetching, I was tired of writing logic and wanted to put in some CSS work. Last week I created the front-end for the listing but had yet to make the listing responsive.
Since we don't have much horizontal space on mobile, I decided to stack the row information on top of each other. While doing this, I placed labels in front of the payment type and cookie period, so the user knows what those values are about.
Besides updating the listing, we also had to resolve some z-index issues (you have to love your z-indexes 💀). The listing was on top of the mobile navigation, so I had to move some elements around to fix the stacking order. Having a stacking order that makes more sense makes it easier to prevent these kinds of bugs in the future.
With an hour left on the clock today, we styled the select boxes to prepare ourselves for implementing the filters tomorrow.
However, I think my brain blocked out how to style select elements because of past nightmares. It's 2022, and we still have to wrap an
<select> element inside a
<div> and use an absolutely positioned icon to style a dropdown properly.
But that wasn't all; let me ask you this (before giving you the answer), how do you create a placeholder for an
<select> element and provide only the placeholder a light gray color?
If you know the answer, you are a legend.
If not, here is the answer:
- Make the select
requiredand set the
- Add an
<option value="" disabled hidden>Placeholder</option>to your select.
- In your CSS file, give your select option a default text color.
- Finally, in your CSS file, use
select:invalidto give your placeholder option a color.
- Oh, and don't forget to give your
<select>a z-index and a transparent background; otherwise, clicking on your icon doesn't open the dropdown.
How, in 2022!? 🤯
After going through a mental breakdown thinking I suck at front-end for not knowing how to style a select element, I called it a day. I actually had other things to do, but my brain still hurts a little bit from the whole experience.
Tomorrow, I will hook up the logic for filtering the lists based on category, payment type, and cookie period. After implementing that, we are very close to launching the first version of useaffiliates.com!
Thanks again for reading this build log, and I hope to see you tomorrow!
Have a great and lovely week!