DEV Community: Elian Ibaj

Modern Web Dev - State Management & Data Fetching

Elian Ibaj — Tue, 11 Jul 2023 20:58:02 +0000

Oh wow it's been quite some time since I last updated this series. You don't need to read the previous articles, just read the last paragraph from the intro to the series to set your expectations right about what this is.

On the flip side of me taking so long to write this article, coming back to it months after having written some parts was the same as coming back to code you've written weeks ago: nothing made sense anymore. So I made a table of contents while thinking about how to restructure it in a way that makes more sense, and you get that bonus table of contents here for free:

UI State
- Local
- Global
Server State
- aside: Data fetching in javascript (fetch API)
- Data fetching in react
  - loading, errors, data
  - race conditions
  - Caching
- React query
Example
- (serverless) backend aside
- another aside about REST vs GraphQL vs tRPC
- Code and demo
  - last aside ever: animations

In the tradition of past articles, let's start with suggested reading. This is the only one I felt I needed to read to get up to speed with state management:

https://leerob.io/blog/react-state-management

One major point to get from that article is that there are different types of state, most importantly two:

UI state
Server state

UI state

Further divided into local and global state.

Local State

The react docs have been rewritten since the last time I was writing an article in this series. Whether you're learning react for the first time, or need a quick refresher, that is the perfect excuse to go through all of the new docs site, or, at least, just the managing state part. In my opinion, state is react, so you'd be doing yourself a favor by learning and understanding it very well.

Global State

Have you ever felt like quitting programming and becoming a farmer in a place far away isolated from the rest of civilization? If not, now you, too, can experience that feeling by setting yourself on a quest to find the best way to handle global state in react apps.

To avoid that feeling I suggest you follow the advice from Lee's article above:

Start with local state
When your app evolves to become like figma such that "... [interacting with one element] affect other elements outside of its "local" state, or where the component is rendered", reach for useContext so you can keep state in one place and read/write to it from anywhere, and maybe useReducer to make the writing part easier.
"If optimizing requires a state management library, you can track that metric (e.g. frame rate), measure it, and verify it solves a real problem." In this case pull for a granular library solving that very specific use case.

Also, I particularly liked one of his suggested solutions to "ask your tech lead." If you're a junior dev you shouldn't have to make decisions like this on your own.

With all that said, if for some reason, you must still follow that route that leads to you in a farm, here's an entry to that rabbit hole that I discovered recently (at least recent as of july 2022 when I wrote about 99% of this blog and then procrastinated on finishing up and publishing it for another year):

https://frontendmastery.com/posts/the-new-wave-of-react-state-management/

Server State (Data Fetching)

aside: Data Fetching in JavaScript

Here's a word I bet you haven't heard in a long time: AJAX. Or maybe you've never even heard it before. But it's what got this whole JS-industrial-complex™ started.

We all know browsers can make web requests. It's what web browsers do. You type kosovahackersclan.com (okay maybe you don't, but I did... around 2005... a lot) in your address bar and your browser (aka the client, aka the user agent) makes a request on your behalf to that l33t forum's server. The server runs phpBB to get the forum posts out of MySQL, marks them up in HTML and sends it back to you. You want to know if the user named n0thinG responded to your thread asking for some warez? You press the refresh button.

But what if the JavaScript you already loaded in the page could also send requests on your behalf, without you having to type in a new address, click a link, or hit that refresh button? It could do that in the background (asynchronously). It could do it every second. And it could update the current page's markup with the new response every second without the browser updating the whole page. What would that result in? Infinite warez!!! Or a web page that shows charts of real-time stock prices. Or a web app that shows you a feed of your friends' posts, each one complete with stats of how many likes and comments it got, while simultaneously overloading your sensors with everything it can crunch in one screen from a live chat window to dopamine-inducing red counters of how much engagement your own content got.

As it turns out, if you're building an app like that, it makes sense to go full Single Page Application mode (get new data in background, only update the relevant parts without refreshing the whole page) and even try an experiment where you throw out the old markup each time you want to make a change and generate completely new markup as a pure function of the new data you got.

As you know, Facebook did exactly that with React and as they say the rest is history. Now, with the recent one eighty of "server first", this whole way of doing front end engineering might become history in a different way, but that's a topic for my next article in the series.

JavaScript Fetch

So, how do you fetch data in the background from javascript? You use the aptly named Fetch API. Straight from the MDN page:

fetch("http://example.com/movies.json")
  .then((response) => response.json())
  .then((data) => console.log(data));

Pretty straightforward, especially compared to what we had before. What we had before was another browser API called XMLHttpRequest and many libraries that wrapped around it to offer cross-browser compatibility and much better APIs.

The most famous of those libraries, axios, is still widely used today. Now that Fetch is available in all modern browsers, you would think we'd get rid of libraries and just use Fetch directly. And that's what we did for a while. But to come full circle again, new libraries popped up that wrap around the modern Fetch API, and there are again good reasons to use those.

I will use ky later on, and you can check its readme to find out about some of those reasons in the list of "benefits over plain fetch". This article, which recommends another library called wretch, does an even better job at highlighting what's wrong with using Fetch in its most simple form like the MDN example above.

Here's what safe data fetching with ky would look like:

try {
  const data = await ky.get("http://example.com/movies.json").json()

  console.log(data)
} catch(error) {
  // handle error
}

Data fetching in react

This article, which is even linked to by the react docs, is a good place to start reading about data fetching in react. You don't need to get into all the advanced topics it discusses. What I liked most about it is how it starts as simple as possible like this:

// you fetch data in `useEffect` and update state with results
function App() {
  const [data, setData] = useState([]);

  useEffect(async () => {
    const result = await fetch('url here');

    setData(result);
  }, []);

  return (
    <div>
      {data}
    </div>
  );
}

What's wrong with this example? Well, everything, according to recent tech twitter. But here's how I feel about that recent discourse (again, recent in july 2022 when I wrote most of this blog):

// Detect dark theme var iframe = document.getElementById('tweet-1545699880924053504-337'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1545699880924053504&theme=dark" }

But seriously, I might revisit this topic in the next blog about frameworks and rendering strategies. But for now, I'd like to focus on a few fundamental shortcomings of this simple approach that Robin also addresses in his article.

loading, error, data

The famous pattern of: loading, error, data. You'll notice this pattern everywhere, whether you're rolling data fetching on your own or using different libraries from React Query to Apollo GraphQL. When you go out of the house remember: Phone, Keys, Wallet. When you do data fetching in react remember: Loading, Error, Data.

Adding loading to our simple pseudocode:

function App() {
+ const [loading, setLoading] = useState(false);
  const [data, setData] = useState([]);

  useEffect(async () => {
+   setLoading(true);
    const result = await fetch('url here');

    setData(result);
+   setLoading(false);
  }, []);

  return (
    <div>
+     {loading ? (
+       Loading ...
+     ) : (
      {data}
+     )}
    </div>
  );
}

We already talked about error handling when fetching data with ky. Here's what it looks like when we combine it with state management:

function App() {
  const [loading, setLoading] = useState(false);
+ const [error, setError] = useState(null)
  const [data, setData] = useState([]);

  useEffect(async () => {
    setLoading(true);
+   setError(null)
-   const result = await fetch('url here');
-
-   setData(result);
+   try {
+     const data = await ky.get("url here").json()
+
+     setData(data)
+   } catch(error) {
+     setError(error)
+   }
    setLoading(false);
  }, []);
+ 
+ if (error) return (<div>Error: {error.message}</div>);

  return (
    <div>
      {loading ? (
        Loading ...
      ) : (
      {data}
      )}
    </div>
  );
}

Race conditions

I can't do a better job at explaining this than this exercise from the react docs. If the hash part of the link doesn't work it's the 4th exercise in the challenges section. If you click show solution it explains very simply how a race condition bug happens and how to fix it.

In our running example it goes like this:

function App() {
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState(null)
  const [data, setData] = useState([]);

  useEffect(async () => {
+   let cancelled = false
    setLoading(true);
    setError(null)
    const result = await fetch('url here');

    setData(result);
    try {
      const data = await ky.get("url here").json()
-
-     setData(data) 
+     if (!cancelled) setData(data)
    } catch(error) {
-     setError(error)
+     if (!cancelled) setError(error)
    }
    setLoading(false);
  }, []);

  if (error) return (<div>Error: {error.message}</div>);

  return (
    <div>
      {loading ? (
        Loading ...
      ) : (
      {data}
      )}
    </div>
  );
}

Caching

Caching is one of those big topics in computer science. As I was searching for the easiest way to explain caching I came across the slides for a talk on the subject, and I extracted the following excerpt from it:

[...] The speaker asked the audience “What’s 3,485,250 divided by 23,235 ?” Everyone fell silent. Some people pulled out calculators to do the maths, and finally someone yelled out the answer after a few seconds.

Then the speaker asked the exact same question again. This time everyone was able to immediately call out the answer.

This is a great demo of the concept of caching. The initial time-consuming process was done once, then after that, when the same question was asked, the answer was readily available, and delivered much faster.

Ah! Don't you just love these types of explanations? As always though, that's just scratching the surface and it gets more complicated as you go deeper. For once, this is only talking about one kind of caching — and there are all kinds of those for you to easily get lost in whichever way you want. To narrow it down a bit, lets look at a proper definition of caching, this time from wikipedia, and focus on the second part of it:

In computing, a cache is a hardware or software component that stores data so that future requests for that data can be served faster; the data stored in a cache might be the result of an earlier computation or a copy of data stored elsewhere.

Caching of a computational result (memoization)

Throughout this article (and this series) I've advocated being practical, and only learning the minimum that you need to correctly finish the task that is immediately in front of you. But the beauty of memoizing a recursive fibonacci function was just too much for me not to geek out on. I invite you to also channel your inner geek and watch this 4 minute walkthrough of how that works.

I'm always amazed by the huge difference that memoization makes here. Without memoization, every time you'd want to calculate the millionth fibonacci number you'd have to recursively call the function as many times as needed to calculate all the previous fibonacci numbers before it (2*F(1,000,001)-1 times to be exact). With memoization, once you've got the previous results in the cache, it's just one call that returns the sum of the earlier computations of F(999,999) and F(999,998).

Caching of data previously retrieved from an underlying slower storage layer

And to complete our geeking out field trip let's start this part about the second type of caching with this famous video:

No, of course you don't nEeD To kNoW ThEsE NuMbErS As a pRoGrAmMeR. It's just a cool thing that exists and I thought it would be cool to link to it here.

Aaaand back to front-end development. How does this all relate to the type of caching we need to worry about daily? Well, this second type of caching is exactly what we must keep in mind when fetching data in our web apps. You can probably imagine how the simplest scenario goes:

The first time the user needs the data, they're gonna have to make a network request to get it, no way around that. After that though, if they request the data again, and we have good reason to believe the data hasn't changed since the last time they got it, it would be a waste to make a new network request (going to the "underlying slower storage layer") instead of serving a copy we previously stored in their browser (do I need to give you nanseconds to illustrate the difference it makes for the user?).

And that's the type of caching that we most frequently have to implement as front-end developers. That's how it starts at least. It starts deceptively simple like that. Makes you think "I can code that in five minutes". And you can. I'm sure you can. But you shouldn't. Why? Because it's a dead end. Or more precisely a "death by a thousand cuts". I googled to make sure I'm using that phrase right and here's one explanation that came up: "a slow, painful, demise caused by the cumulative damage of one too many ‘seemingly’ minuscule problems". And here are some of the not so minuscule problems you'll have to think about when implementing caching on your own, as described by people who (I imagine) think about it daily.

As you may have gathered by now, unlike for the other problems we encountered with data fetching in react, I won't try to implement a solution for caching on my own and use react query instead. Do I think I have convinced you to do the same and never implement a full caching solution from scratch in a production app? I don't know. A while ago I would've thought that it's one of those things you can only learn by going through it yourself, but the popularity of react query gives me hope that's that not the case anymore.

React Query

I just realized that this whole section on data fetching with react reads like a giant ad for react query. Here's a list of problems I had, and TADA, react query solves them all!!! Order now!

Lol I swear I didn't write it that way on purpose, but it's true, react query solves all the problems I listed above — especially caching; oh my god caching — and that's not even what I liked most about it (kill me now I just realized I'm a react query fanboy).

What I liked most about it was the declarative way of doing data fetching and how much it simplifies the code. Even in the simple example I'm using the code was simplified to the point of not needing the useEffect anymore, and the shift from fetching the data and then imperatively updating your state to having the data fetching happen as a result of you managing your local state was visible.

Speaking of the example.

Example

As I mentioned in the beginning, when I was almost done writing this article I reorganized it in a way that I think makes it easier to read. That's why I moved everything that had to do with the example project that I've been working on since the start of this series to its own section here at the end of the article. Everything up to here was theoretical enough that it could (hopefully) benefit anyone wanting to learn about data fetching and state management in react and hasn't read the previous articles in this series. This last part is about how I added data fetching to this website.

By the end of this section I will discuss a bit about the data fetching and state management part of the example, but before that I had to write three (not-so) short asides about other stuff that I had to do before getting to that part. The first of these was building a backend for the products.

I left this part at the end of the article, but I still want you to read it though, that's why I will lure you in with this artisanally-crafted-with-my-own-two-hands pepe silvia meme.

APIs amiright. Client-server architecture. "How the web works" youtube videos. "Describe what happens when I visit google.com" interview questions.

All good to know, fundamental stuff — but this is 2023.

(serverless) backend aside

I've mentioned in previous articles that I like "serverless" for many reasons; and one of them is how it changed our way of thinking about the backend. Whereas before we would think of the backend as one big monolithic box (literally called a box to refer to the single machine running everything like the web server, the database server etc.), our thinking now has shifted to picking and choosing only the services we need. Your app needs authentication? Find out who offers authentication as a service. You need a database? Find a serverless solution for that. Need a place to run some code, storage for images, a proxy for caching, load-balancing or any of the other traditional backend needs? Same solution in all cases.

So, what services do we need for our sample website? I'm going to use the products section to learn about data fetching and state management. So we need:

a database to store the products info, and

a place to store the product images.

Here's a quick overview of how I think of some of the most popular solutions that fill our database needs.

Amazon AWS: The biggest of the original cloud computing platforms (alongside Microsoft's Azure). Now, I've talked about different learning styles before, and IME I don't find the AWS docs to be as bad as everyone says. IMO if you're learning about backend concepts for the first time you're gonna have a steep learning curve ahead of you no matter which serverless platform you choose. But that's not a popular opinion. In fact the opposite (that AWS is very hard to learn) is so wide-spread that it has at least two important implications:

You can make a career by learning it well and earning certifications to prove it.

A plethora of other services have proliferated who use AWS under the hood and their entire business model is based on you paying them money to not have to learn AWS yourself.

Google Firebase: Google's cloud solution, also offering virtually everything you might need. For some reason not as well respected in the industry as AWS, so instead of making a career in big tech companies you could get good at building fullstack apps with firebase and make a solo freelancing career.

Supabase: They describe it as "The Open Source Firebase Alternative" and it fully delivers on that promise and more. Literally, if you're thinking of starting a new project with google firebase, I can't think of a single good reason why you shouldn't go with supabase instead. Not just less vendor lock-in but also just better tech like the postgress database most of supabase is built around (they won't shut up about it though, kinda giving me some linux-flavored gatekeeping vibes).

Planetscale: This is the perfect example of what I said above about only picking the services you need. A small company dedicated to a single purpose: offering the best serverless MySQL database out there. And in my experience it delivers — from getting you started in literally two minutes, to all the scaling needs you might have.

Some CMS like Strapi: Or, you know, WordPress. Or shopify. This is the real-world. The above solutions only apply if you're building the back-end yourself. If you're just working on the front-end of a furniture shop like this one, the back-end will be some CMS or e-commerce solution, and you'll only care about the REST API it provides.

Speaking of which:

another aside about REST vs GraphQL vs tRPC

I loved the idea of GraphQL when it came out, especially what it meant for frontend developers. Yet, as one ex-famous javascript guru from the era of javascript gurus, who shall remain unnamed here, used to say: "Who is the first group to go against things that make developers' lives easier? Developers".

Now I know there are many reasons as to why one technology becomes successful or not, but I can't help but think of the big role that cultural reasons play in it.

TypeScript's marketing? "Bringing strong, enterprise-class types to this weakly-typed, toy language finally making it serious enough for you to write it while wearing a suit and tie". No wonder brogrammers flocked to it (don't get me wrong, I love typescript; just commenting on the high number of people who would praise it online, many of them not even javascript programmers.)

GraphQL's — a similar technology to typescript — marketing? "Empowering frontend developers". Get outta here! REST is trad and lindy enough for me, don't need this shiny new thing from these facebook hipsters always reinventing the wheel.

All this rant was just to say that the state of API protocols is in a kind of limbo after GraphQL was supposed to replace REST and it didn't. REST is still the most widely used one. GraphQL is used in many big companies. And tRPC is the new kid on the block.

This article is targeted at juniors, probably preparing to get their first dev job, and I can't tell you for sure that my decision to only use REST examples is befitting towards that goal. If I was a hiring manager and my company used GraphQL, I would still hire a junior dev who only knows REST and expect them to learn GraphQL on the job. But I'm not a hiring manager. I know there are a few hiring managers who think like me and many others who don't. So, depending on your job applying strategy, you'll have to decide where you draw the line when it comes to learning technologies used by the companies you want to apply to, before applying.

Code

CODE
DEMO

Two quick things that may distract you from the data fetching part:

The AWS link. Long story short, I used Amazon's AWS from the options above to setup the backend. Amazon S3 to store the images, DynamoDB for the product info, and API Gateway for the REST API. Ultimately, as a frontend developer, that REST endpoint is the only thing you'll care about.

The other thing which may confuse you in the code is the animation which is now being done with framer, so I have to write my last aside ever about animations.

last aside ever: animations

Okay, so, super quick. Animation is hard. Animation in react is even harder. Learn framer motion and learn it well to survive if you have to work with animations in react.

I made the animation work exactly as I wanted and as I had described in the first article, but it cost me EVERYTHING. Okaybe maybe not, but I had to learn framer motion and that's what it felt like.

Looking back at the code (this is perfect cause I did the animation work quite a while ago but didn't write this part of the blog to explain it until now) it's a bit verbose, VS code even shows me that this exitBeforeEnter property that I had to use to make the animation work right in a few edge cases is now deprecated. Other than that it's pretty readable I think. I like that the transition properties are now in javascript and located close to the animation components. I also like alot the truly(™) declarative style over what we had going on before with React Transition Group.

Would I go back and try to make it work without the deprecated property for a hobby blog/side project/whatever this is? Hell naw.

Here's all the data fetching code with react query:

function ProductsSection() {
  function onChangeFilter(filter) {
    setActiveFilter((activeFilter) => ({
      prev: activeFilter.current,
      current: filter,
    }))
  }

  const [activeFilter, setActiveFilter] = useState({
    current: 'All',
    prev: null,
  })

  let endpoint =
    'https://c300bbvloc.execute-api.us-east-1.amazonaws.com/dev/products'

  if (activeFilter.current !== 'All') {
    endpoint += '/' + activeFilter.current
  }

  const {
    isLoading,
    error,
    data: products = [],
    isPreviousData,
  } = useQuery({
    queryKey: ['products', activeFilter.current],
    queryFn: async () => await ky.get(endpoint).json(),
    keepPreviousData: true,
    staleTime: 1000 * 60 * 5,
  })

  return (
    <Container smPadding="left" mdPadding="horizontal" role="main">
      <ProductsHeading>
        <ProductsTitle>Products</ProductsTitle>
        <ProductsFilters
          filters={filters}
          activeFilter={activeFilter}
          onChangeFilter={onChangeFilter}
        ></ProductsFilters>
      </ProductsHeading>

      {error ? (
        error.message
      ) : (
        <ProductsList
          loading={isLoading || isPreviousData}
          activeFilter={activeFilter}
          products={products}
        />
      )}
    </Container>
  )
}

Again, at the risk of sounding like an ad for react query, look at how much code we removed from what we had before. We got rid of useEffect entirely and that's always a win!

I pretty much said all I had to say about react query in the previous sections. One funny thing though is something I had to do to get animations to work with it.

The way the loading animation works is it expects only the products that are added/removed to be actually added/removed to the markup. If you go let's say from 'All' to 'Tables' it should go from this:

<div>Table 1</div>
<div>Chair 1</div>
<div>Table 2</div>

directly to this:

<div>Table 1</div>
<div>Table 2</div>

That's how it knows to only animate out the "Chair 1" div. But with react query's default behaviour it goes from this:

[
"Table 1",
"Chair 1",
"Table 2",
]

to this for a second:

[]

and then finally to this:

[
"Table 1",
"Table 2",
]

As you can see that will mess with our animation because all the product divs would be gone for a moment before the other ones are loaded. Looking through the docs, I tried to fix it with initialData and placeholderData to no success. My first solution then was this:

<ProductsList
  ...
  products={
    products && products.length
      ? products
      : queryClient.getQueryData([
          'products',
          activeFilter.prev || 'All',
        ]) || []
  }
/>

It worked, but then, spending one friday evening, as one does, watching an episode of "Learn with Jason" with Dominik Dorfmeister, I realized all I had to do was add keepPreviousData: true, to the useQuery call. By the end I also added staleTime: 1000 * 60 * 5, to ease my OCD and make sure it behaves like a proper legacy website not some fancy always up to date app.

Conclusions

Whew! I can't believe it's done. Finished. Complete. And congrats to you if you read all the way to here. If you didn't, and just scrolled here while skimming quickly, that's fine too, no judgement from me. Whatever brings joy. For me it surely brought lots of joy to finally publish this after such a long time, and I can't wait to get started on the next article. That will most probably focus on deployments, rendering strategies, and how different frameworks especially Next.js handle these. Looking forward to that! For now here are my short conclusions about data fetching and state management in react:

I love the movement towards specific state management libraries for specific needs. Feels like a sign of maturity and a good middle ground after the pendulum swang from redux sagas to "just use react context".
Use react query. That's it. That's the second conclusion.
Animations, not even once. Just kidding... Unless? No, but seriously, this one was on me. I approached animations with the seriousness that a backend developer approaches frontend work and found myself in the same surprising position. If you're serious about animations in react, getting good with framer motion can be very rewarding.

Modern Web Dev - UI - CSS-in-JS

Elian Ibaj — Fri, 26 Nov 2021 23:46:48 +0000

CSS in JS! I feel like everything that can be said about the topic (and then some more) has already been said. If you've missed it all, consider yourself lucky. For context, though, I'll only give three links here.

The original presentation of the concept to the wide public (slides here):

An article that does a very good, emotionless, summary of all the backlash it got:

https://css-tricks.com/the-differing-perspectives-on-css-in-js/

And finally, a great, principles-based, article that will help you stay sane while trying to keep up with all the new solutions that come up in this space every day:

https://css-tricks.com/a-thorough-analysis-of-css-in-js/

If that last article did its job correctly, you'll now have the strength to resist clicking this, for example:

🧁🍨 Mark Dalgleish

@markdalgleish

👇 NEW CSS-IN-JS LIBRARY ALERT!

🧁 vanilla-extract

🔥 Zero-runtime Stylesheets-in-TypeScript
✨ Minimal abstraction over standard CSS
🦄 Works with any front-end framework
🌳 Locally scoped classes + CSS Variables
🎨 High-level theming system

github.com/seek-oss/vanil…

05:18 AM - 26 Mar 2021

You still with me? Good, let's get started by:

Bootstrapping react

Contrary to what the ending of the last article might suggest, I've been eager to get rid of as much tooling as possible in development as soon as I saw it as a real possibility. I don't hate tools (instrumentum, for those of you fluent in latin) either, though.

What does a misogynist say when called out on their misogyny? I can't be a misogynist, I have a daughter/wife. What does a misoinstrumentist, like me, say when called out on their misoinstrumenty? I can't be a misointrumentist, I have contributed to Babel.

It shouldn't come as a surprise, then, that I'll use vite to quickly get this react project setup.

Also, last time I did npx create-react-app it created, let me check, ah yes: 41,732 items, totaling 250.7 MB. I've had one SSD and one HDD die of bad sectors in the last two years. Coincidence? I think not!

So, yeah, that's the setup — npm init vite@latest and follow the prompts to start a react project without typescript. Then:

cd what-you-named-your-project
npm install

And to add styled-components, npm install styled-components.

Last part of the setup was deleting the unnecessary stuff before adding the base styles.

Base styles

In the last article, I spent so much time with "suggested reading" before writing the first line of code. For this one, I'll take the opposite approach: do as little reading as necessary to get started, and then go read more when I get stuck. This was my modus operandi when I was working professionally, and I assume it is so for most people.

I read from the Getting Started to the ("to the" == including; english is hard) Coming from CSS parts of the styled-components docs and started converting the base styles.

I started by renaming index.css and replacing the few rules there with my reset styles as well as the google font @import. Keeping this as a CSS file is fine: we don't need createGlobalStyle as we don't need theming or template literal interpolations for these simple CSS rules.

I modified Todo and Container a bit to make them more flexible.

The rest is straightforward: almost a one-to-one correlation of old classes to new components. I liked the collocation of @media rules with the rest of the styles for the component. I changed the --body-padding css variable into a bodyPadding js variable. I don't know why I did that.

For including images, I'm not a big fan of webpack-style importing of assets to get their URL. I was happy to find out that vite also allows the most common alternative approach: a "public" folder where you can put all your images in and have them reachable from anywhere in your code with absolute URLs. That's what I did for hero img's src and srcSet.

Navigation

There isn't much to say about converting the navigation styles to styled-components, and that's a very good thing to say about styled-components. Everything was easy to move over, including transition animations and complex CSS selectors, pseudo-selectors, and whatever this is:

.menu-visible &::before {}

We also had some JavaScript in nav.js to toggle the menu and search input on and off. This is not a React tutorial, but just one quick observation about a subtle change that happens when you port the code to react:

Doing

[document.documentElement, document.body].forEach((el) =>
  menuVisible
    ? el.classList.add('menu-visible')
    : el.classList.remove('menu-visible')
)

instead of

[document.documentElement, document.body].forEach((el) =>
  el.classList.toggle("menu-visible")
)

means we're no longer relying on HTML to tell whether the menu is visible or not. Our only source of truth for that now is the menuVisible state. I'm not pointing this out to say that I'm some genius developer who anticipated this. I only noticed it after I tried to do it with .toggle() first and it didn't work (the first time useEffect ran on mount it was toggling the class on, and then, when the button was clicked, setting menuVisible to true, it was toggling it off).

It was a nice example of react making it easy for you to almost accidentally fall into doing things right (pit of success?).

Showcase

Well, isn't it ironic that as soon as I make the case for not relying on HTML as a source of truth, I decide to go ahead and do just that for the showcase? Sure, I could've rewritten the slider logic in an idiomatic way for react, but that IntersectionObserver was my baby!

Seriously, though, going the uncontrolled component way made more sense to me here. Let's quickly go through the code in Slider.jsx.

Side note on code organization: there isn't any 😝. I didn't make different folders for components and started with one file per component instead (vite used jsx extensions and I went with that). Still, even with region folding of code in the editor, Showcase.jsx got too long even for me, so I turned that into a presentation component, and moved the core styling and functionality into Slider.jsx.

A few refs keep track of the important dom nodes: for the slider itself, the ref is set directly with <StyledSlider ref={slider}>; the useEffect callback, which runs only after the first render, gets the first and last slide nodes from the slider ref with standard DOM properties firstChild and lastChild.

That same callback also initializes the IntersectionObserver. All it does, when an observed slide "intersects" 50% with the parent slider (threshold: 0.5), is set the currentSlide state to that slide's dom node. With that in place, implementing the disabled state and prev/next functions of the buttons becomes trivial.

Warning: Rambling ahead. Remember how I said in the intro to this series that I'll try to keep rambling to a minimum? Well, I failed here. Feel free to skip until the next section.

There is one bug? in chrome, though, which stops scrollIntoView dead in its tracks. I set the threshold to 0.5 to make sure prev/next buttons get the disabled attribute as the last slide is halfway in. For whatever reason, though, chrome was fine with me doing btnPrev.disabled = true;, but it's not fine with React doing it. As you know, all we can do in react is set disabled={currentSlide === firstSlide.current} and let react update the DOM however and whenever it sees fit. Well, however react is doing it, chrome doesn't like it one bit — if you click next and then previous (IMPORTANT: without scrolling the page at all in between the clicks, otherwise it works fine), as soon as the first slide comes halfway through, and the button is disabled, chrome stops the smooth scrolling.

To be honest, this whole implementation of the carousel as not a carousel is a bit flimsy, I'll admit. Its strongest point, the fact that it uses a very light touch, going with the grain of the perennial design pattern that is scrolling, instead of against it, is also its weakness because of differing browser and OS implementations. There is, for example, another bug (also found in the HTML & CSS version from the first blog) in firefox when you tab through the slides.

Nonetheless, I'm keeping it, not because it's hard to fix, but ~~because IntersectionObserver is my baby~~ in an aspirational way (I wanted to write aspiration "towards a better web", but I think I threw up a little in my mouth).

Last thing about the showcase implementation in react: did you maybe wonder what that cloneElement is doing in line 241? That whole acrobatics is just so we don't have to pass an id prop to each slide in Showcase.jsx:

<Slider>
  <Slide title="Lamp" img="lamp" alt="lamp photo" link="#"></Slide>
  ...
</Slider>

Worth it? I don't know; the things we do for ~~love~~ good API design.

Products

Things had been going really smoothly with styled-components so far, so I decided to spice it up a bit by learning about React Transition Group. There really isn't much there, but for some reason, it wasn't clicking for me at all. Maybe I was tired, maybe I was distracted by the thought of React 18 being in beta now.

Anyway, I decided to simply convert the existing animation from the HTML and CSS version to styled-components and react transition group components for now, and do a full example with loading animation and data fetching in a future article. With tailwindcss about to rewrite their documentation for the v3 release, it's very probable that I'll write that article next, before the one on tailwind. And if I ever want an excuse to not write that article either, I could always wait on Suspense for data fetching to be released...

Here's how our simple animation works:

When a new filter is selected, fade out ALL currently shown products. When the fade-out transition ends, fade in just the products that match the filter.

This was the procedural version:

function displayProducts(filter) {
  products.forEach((p) => p.classList.add("faded-out"));

  productsList.addEventListener(
    "transitionend",
    (e) => {
      products.forEach((p) => {
        if (filter === "All" || p.dataset.category === filter) {
          p.classList.remove("hidden");
          setTimeout(() => {
            p.classList.remove("faded-out");
          }, 0);
        } else {
          p.classList.add("hidden");
        }
      });
    },
    { once: true }
  );
}

A bubbling transitionend event, fired on the parent products list element once, controls the fading-in of new products. To account for the fact that you can't animate from display: none to display: block, it removes the hidden class first, and then, a moment later (with the asynchronous setTimeout(() => {}, 0), removes the faded-out class too which transitions the opacity back from 0 to 1.

Here's the react version:

export function ProductsList({ products }) {
  const [listFadeOut, setListFadeOut] = useState(false)

  useEffect(() => setListFadeOut(true), [products])

  return (
    <Transition
      in={!listFadeOut}
      timeout={timeout}
      onExited={() => setListFadeOut(false)}
    >
      {(state) => (
        <StyledProductsList
          id="products-list"
          aria-live="polite"
          aria-atomic="true"
          aria-relevant="additions removals"
          state={state}
        >
          <TransitionGroup component={null}>
            {products.map(({ id, ...props }) => (
              <Transition key={id} timeout={timeout}>
                {(state) => <Product state={state} {...props} />}
              </Transition>
            ))}
          </TransitionGroup>
        </StyledProductsList>
      )}
    </Transition>
  )
}

When a new filter is selected (new products received from parent, monitored in useEffect(() => {}, [products])), the first <Transition> component fades out the products list component itself. Not the same effect as fading out all products individually, but close enough. As soon as it fades out, it fades back in (onExited={() => setListFadeOut(false)}).

The <TransitionGroup> delays the appearing/disappearing of individual products using the same timeout as the fade-out effect of the products list. This is the equivalent of the .hidden class from the vanilla js version. There's no animation in the styling of the StyledProduct component, just:

display: ${({ state }) => (state === 'entering' ? 'none' : 'flex')};

And, as is tradition, here's the full demo and code:

CODE
DEMO

Conclusions

No conclusions :) As I said in the beginning, I feel like everything has already been said about CSS-in-JS. Here's the link to the most important article from the top again.
What I also wrote at the beginning of the article, near the setup part, and then deleted, was a full-on rant against tooling and how we bring a whole class of problems upon ourselves with so much tooling in development. I deleted it because I thought it was too harsh, and then... I spent half a day trying to figure out why Intellisense on VS Code was suddenly so slow. I won't turn this into a rant again, just letting you know that it turned out to be the typescript types library for styled-components. Excluding styled-components from typeAcquisition in a jsconfig.json file did... nothing. So I guess you'll have to turn type acquisition off from the settings if the slow autocomplete becomes too much to handle.

Modern Web Dev - UI - HTML & CSS

Elian Ibaj — Tue, 16 Nov 2021 23:01:08 +0000

As I was wrapping my head around everything I had to review about building web user interfaces in 2021, I came across this "I Design, You Build" challenge here on DEV:

I Design, You Build! - Frontend Challenge #3

Zernonia ・ Oct 14 '21

#webdev #beginners #javascript #idesignyoubuild

Joy sparked. Challenge accepted! With a twist — I'll use this same design to build the website multiple times with all the different technologies that I want to explore:

HTML & CSS
CSS-in-JS (probably react & styled-components)
Tailwind CSS
Component library (probably Chakra UI)

In the intro to this blog series, I imagined I would only write one article about UI comparing all these technologies. But after finishing just the HTML & CSS part, it's obvious they each need their own blog. I will preface them all with "UI -" like I've done for this first one.

HTML & CSS like it's 2009

Except no. We now have very good browser support for Flex and Grid layouts — it would be a shame not to use them. Wait how do you use them for building full responsive pages again? Is mobile-first still the thing to do by the way? To soothe the sudden existential dread caused by the influx of these questions, I read this from start to finish:

https://www.smashingmagazine.com/2018/02/media-queries-responsive-design-2018/

It works. I mean, the best thing would've been a recording of this talk by the author, but such a recording doesn't seem to exist on the internet yet, so the article will have to do.

Okay so:

flexbox and grid are at the core of modern responsive web
mobile-first still makes sense but breakpoints should be set where the design breaks visually instead of actual device widths

Here's a video I watched to review what I know about CSS Grid:

Everyone's learning style is different, but for me, I remember I put that video at 1.5x playback speed, and it captured my attention long enough to watch to the end. After that, when you run into specific problems while building something with grid (as you will), gridbyexample.com will have your answers.

As for flexbox, I don't remember all the different places I've learned it from, but if this doesn't make sense to you, it probably means you should review one of the many good resources on flexbox out there:

// Detect dark theme var iframe = document.getElementById('tweet-1281339741682753542-920'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1281339741682753542&theme=dark" }

While we're on the prerequisites part of this blog, do you know what else is required reading? Accessibility. Yeah, I know you plan on learning about accessibility... someday. And I can't blame you entirely, to be honest — putting the responsibility of making web browsers work correctly with assistive technology entirely on developers, feels akin to fighting climate change with paper straws. Still, there is a grain of truth in both of those outwardly absurd situations: just like the fight against climate change will most probably require some changes in consumer behavior, accessibility in its current form (WAI-ARIA, etc.) is necessary until we have better solutions to the problem of inaccessible technology.

Where do you start? This awesome introduction, right here:

And follow that with this practical one:

And here's the last piece of reading I'll suggest before we start working on the challenge. This is the most fun to read, though — it's an interactive guide about the basics of CSS animations:

https://www.joshwcomeau.com/animation/css-transitions/

Alright, so with our refreshed knowledge of responsive web design with flex and grid, accessibility, and animations, we are ready to jump right in and:

Start Challenge

Here's a first look at the design:

I've highlighted three important components in the desktop design: the top navigation bar, the products listing component which is a grid of items you can filter, and the showcase/slider/carousel.

We'll cover UI component libraries later in this series, but we must take a first look at them now as case studies to ~~steal code~~ copy best practices from. UI components, like the three that we have in our design, are very common patterns, that are implemented again and again in all kinds of websites and apps. It makes sense to get a bit more familiar with how others are doing that.

Ten years ago, that would have meant reading what some distinguished designer had to say about it in his (yes, the distinguished designer was a he) personal blog. Today, a good place to start would be the most popular design systems/component libraries. Of course, you should still read widely, listen to podcasts, and consume all kinds of content you like, but as a culmination (usually — not looking to start any debates here) of current best practices, popular component libraries are a good place to start.

Material Design is the best Google has to say about the subject. Chakra UI is a truly collaborative project built under the watchful eyes of the open-source community. Bootstrap suffers from the plague of having once been uber-popular, but is, in its current fifth version, an invaluable mix of best practices and real-world experience. We'll look at these libraries, and many other sources, to learn about the three components we identified.

Base Styles

I've separated each component into its own git branch, so that you can inspect them in isolation, without getting distracted by unrelated code. The master branch contains all of them put together.

Code

If the others are components one, two, and three, this is like component zero? While writing the base styles for the page, and the two simple sections that I didn't circle in red, we also have to take some things into consideration as they come up, that we haven't covered in the prerequisites section above. It's very easy to fall into deep rabbit holes through each of these topics, though, so I'll keep it super short and give no "further reading" links at all.

CSS Units and (Responsive) Typography

ems everywhere you'd use pixels before (except for stuff like border widths, or when you explicitly don't want something to change). They work well with a custom font size in the browser settings; make it easier to work with padding and generally let you worry only about the font-size of elements and have spacing adapt to it.
Manually set font-sizes at different breakpoints to what looks good at that size. We'll have three main breakpoints: small - under 48em, medium - up to 80em, and large - 80em and above. "Medium" and "large" will basically share the same desktop design but with font sizes and spacing adjusted.

Responsive Images

Doing art direction and handling different resolutions by hand, for a large website with dynamic content, is practically impossible. You will definitely need to reach for some images service like Cloudinary.

In our proof of concept here, I exported two sizes of big images like the hero image and used srcset and sizes to serve the most appropriate one. I didn't export a separate file for the cropped mobile version but achieved the crop effect with object-fit and object-position.

Other

Pixel-perfect-ish. I haven't gone through extra effort to make it pixel-perfect, but for the most part, except for where the design allows more flexibility, sizes and spaces are the same as design.
Modern browsers only. And even then, since this is pure HTML and CSS with no build step at all, I haven't even added browser prefixes that would normally be added by a tool like autoprefixer.

Main Navigation Bar

Probably the most ubiquitous piece of UI in websites. It has always been there in almost all websites, evolving with the time from a dl with links in the first website ever, to uls with padded lis floated left or right for the horizontal look that started in the 90s and continues on today, to the web 2.0 fad of dropdowns on hover, to the proliferation of hamburger menus despite people making the case against them.

From the popular component libraries mentioned above, Material Design's top app bar, even though heavily biased towards apps rather than websites, is still a good high-level overview. The first related link from that page is also a good read to get you to think more in terms of UI/UX rather than solely converting a design into a web page. In terms of implementation, bootstrap's Navbar seems closer to what we're looking for.

Speaking of which, what are we actually looking for in our nav component? We have both desktop and mobile designs so that's good:

Now, I didn't make you read all those articles for nothing, so let's apply our knowledge to fully specify our nav component:

A full-screen off-canvas element that slides in when the menu toggle icon is pressed, seems like the most appropriate solution for the mobile version. It's elegant to match the design. And it's big enough to accommodate all the links to the full catalog that would normally be present in a furniture shop's website like this one.
The search and cart buttons are important enough to not be tucked away behind the hamburger menu, so we can leave them in the same place for mobile too, and move the toggle icon to the left.

Code

Observations:

I think being able to just do display: block; (the default) on mobile, and display: flex; on desktop to get a responsive menu is beautifully simple. Also, I didn't do ul > li for the menu items, and that's fine. You could do it, and that would be fine too.
You'll notice I haven't gone overboard with aria properties. Just some roles and labels for important icon buttons like search etc.
What I did pay attention to, with regards to accessibility, was making sure I don't break stuff that worked before, like navigating the page with the keyboard. And that's exactly what you do when you translate the menu off the screen. If you press tab now to move from the logo to the search button, the focus seems to disappear for a while as it's moving through the menu items (which are not visible on the screen). That's what visibility: hidden is for (as well as for hiding it from screen readers too). For more complicated components, you might have to manage the tabindexes of your elements with JavaScript to fix this, but in this case, using the CSS visibility property, and making sure it works well with our animation, was all that was needed.
I stole the hamburger icon animation from this beautiful solution of the challenge. I must've been procrastinating on something else, though, because instead of copying the SVG animation like a normal human being, I had to go and rewrite it in CSS.
I never knew I needed custom transition timing functions in my life but here we are. The cubic-bezier you see at .search's transition property is the "easeOutQuart" from here. Its inverse, the "easeInQuart", is used to complete the effect of making the search slowly show up (after the backdrop blur has started kicking in) and quickly get out of the way once you dismiss it.

Showcase / Slider / Carousel

Ah, the carousel — web designers' most hated component. This is probably why you won't find it in most of the popular component libraries (okay bootstrap still has one, but that's probably part of why bootstrap is not so hip anymore). The carousel is not going away anytime soon though. Especially on mobile where swiping is second nature. Airbnb's scrolling features on their home page and app are iconic by now. Swiping on, how do we implement it?

You may not find a carousel component in component libraries, but do you know where you can find one? At the WAI-ARIA Authoring Practices.

I took an even simpler approach, though. Here's the code first:

Code

As I said, I took a simpler approach. Not because I'm a contrarian, but because I found out about CSS Scroll Snap! Oh em gee! Is this real? How can this be real?

You add two CSS properties, and things... just... work? This just doesn't happen on the web. Who allowed this? Didn't they think of the slippery slope?

OK, for real, this is awesome, but let's move on.

With scroll snap, our carousel doesn't have to be a carousel at all. All the "slides" content will be present at all times, just waiting to be scrolled into view. As far as screen readers are concerned, this is normal content on the page (I gave slides a role="group", but even without it, screen readers would do fine reading the content in order).

For keyboard navigation, when the showcase has focus, pressing left or right arrow keys would normally just scroll the content horizontally by a little. Thanks to snap scroll, that little scroll becomes a complete scroll to the previous/next slide. scroll-behavior: smooth; ensures the same happens when you tab through, moving the focus from one slide to another (except for firefox apparently, but that's easy to fix with some JavaScript if you want).

The JavaScript for the buttons becomes trivial too: next/previousElement.scrollIntoView(). The IntersectionObserver keeps track of the current slide to conditionally disable the prev and next buttons as needed.

(Filterable) Products Listing Component

Have you seen that "drawing spiderman in 10 min, 1 min, 10 seconds challenge" that went viral a while ago?

The 10-second version of our page would just be the products listing component. It's the main function of the site. The reason why visitors are there. I learned to recognize this most basic pattern as soon as I got into web development. I started with WordPress — you had this index.php template to design the page that lists all the blogs/items, and single.php to design the individual view that shows up when the user clicks one of those items. That pattern is everywhere in different variations: youtube, twitter, news sites, your portfolio. See a bunch of things, click one.

Now, because this is so often the main functionality — it is closely tied to the business logic of the website/app — you won't usually find a generic "product listing" component in the component libraries. Instead, you'll find helpful bits intended to aid you while you're building this core feature yourself. For example, you'll find cards in material design, and this nice link overlay in chakra. Bootstrap also has cards, list groups, pagination etc.

Pagination is interesting because it's one of those "variations" that I mentioned above — a property of the items listing component. Filtering is, in this way, also a property of the component. An important property for sure, since it changes fundamentally the way users interact with the component, but it's still just a property, something that the component "has". I guess what I'm trying to say is don't think of this component as a filtering component first, but as a products listing component, with filtering. This will set the framework for thinking on how to implement it. Let's do that now.

The desktop layout screams CSS Grid. Three columns, and as many rows as needed. The mobile layout is horizontally scrollable. I made this snappy-scrollable (word?) as well, but it is a UX question to think about. The keyword here is reducing inertia. Is it easier for the user to scroll through the products with or without scroll snap?
The classic masonry is the first effect that comes to mind for animating the filtering. It animates both the items that are appearing/disappearing individually, as well as the movement of the surrounding elements to perfectly illustrate the filtering that is taking place. But I don't think it's a good fit in our case for a few reasons:
1. In this proof of concept we can have all the products in the HTML at all times, and hide those that must be filtered out with CSS. But in a real-world implementation of this e-commerce website, you would be fetching the products from some backend. All that movement after a loading animation would make for a disjointed experience.
2. It seems like animating the position of items would be rather complicated with CSS Grid. Because I made my decision after thinking of the first reason above, I haven't investigated this further, but I'm including it here as something to think about. This is not about being lazy, but about being mindful of budget and time restrictions. As mentioned above, this is the core feature of our website, so if you were to decide that having a masonry style effect was important enough, it would make sense to plan for and implement a solution for it. That solution might be anything, from researching libraries you could use that animate CSS grid, to switching to absolute position altogether. The point that I'm trying to make is... actually two points: 1) decide what is important and how much time you're going to spend on it, and 2) when you see something implemented differently from how you would do it, consider they most probably had a reason to do it the way they did — if appropriate, ask them why.

Code

Notes:

For animation, I ended up fading the elements in and out. Seems unobtrusive enough, and in line with the design and the rest of the animations. The js code might seem a bit complex, but it has to be that way because of the classic problem where you can't animate from display: block; to display: none;.
- To make it work with loading, I would only fade the contents inside of .product, and infinitely animate the background color to indicate loading. I might do this in one of the upcoming blogs.
Using a radio group for our filter buttons solves most of the accessibility problems we would otherwise encounter. Keyboard navigation? Check. Focus on labels with :focus-visible? Check. The product list itself is a ul, and aria-live="polite" announces to screen readers when its content changes.

And without further ado (lol as if I could drag this out any longer), here's the full challenge demo and code:

Conclusion

I'll try to do this in a bulleted list form too. Here are my observations from building a website with HTML and CSS in late 2021:

EVERGREEN BROWSERS BABY!!! You have no idea how bad this was before. In immigration law terms, I believe our jobs qualify as "highly skilled labor". Well, for a long time, 99% of the high skill a web developer had was knowing about and resolving browser inconsistencies. I don't know how to tie a tie, but the information that Internet Explorer 6's XMLHttpRequest was not a native JavaScript object but an ActiveX one, is still taking up space somewhere in my brain.
This is still very much a full-time job. We only scratched the surface of accessibility here and didn't even get into performance. Anyone who speaks of full-stack has either stumbled upon — and is underpaying — the rare 10x coding creature or, much more probably, is neglecting many of the specialized areas just mentioned. (I have nothing against full-stack roles where responsibilities shift from time to time; this was just for the specific situations I mentioned here.)
The kids are alright. Not looking to rehash all the debates on tooling and over-engineering from the past few years (almost a decade now, really). Just making my observation, that, even when building a simple website in 2021, the "just opening up notepad and coding" ideal feels very self-limiting without getting much benefit in return.

Alright then, on the next blog we'll rebuild this in React and some CSS-in-JS library like styled-components. Follow me on twitter. I almost never tweet, but if someone follows me from here, I'll make an exception and tweet about the next article when it comes up.

Modern Web Dev - Intro

Elian Ibaj — Tue, 16 Nov 2021 22:58:27 +0000

I was a professional web developer from 2009 to 2015. As I'm getting ready to get back into it, I thought I'd write about the process of catching up with modern web dev. You don't need to be in the same place as me to benefit from this blog, though. I imagine, the biggest skills that will transfer over for me, will be my core knowledge of HTML, CSS, and JavaScript. If you're also at the place where you feel confident with your knowledge of these three foundational technologies of the web, and are thinking about what the actual job of doing web development in 2021 looks like, then this article series is for you.

OK, that's a big statement so let me qualify it further by saying that I will focus only on a few parts of this job that I'm most interested in pursuing for myself. I've split up my study plan (and hence the blogs that I will write here) into three parts:

Responsive web design and UI
Also known as the front of the frontend, this is reflected in job titles that include the word UI.
Data fetching and state management
This will be react-specific (sorry?). Job titles here include the word engineering.
Rendering strategies and deployment
I need this for my own sanity. Now you too can know about the wonders of SSG vs SSR vs ISR!!! And this disconnect between the perfectly set up local environment and where it will all be deployed, is a world away from live editing the files on your bluehost "server", so we'll talk about that as well.

Other than the above limitations, narrowing down both the business and tech sides, you should benefit from reading these three articles no matter which part of frontend development you end up working in. For example, knowing the above will be helpful whether you get to work as a solo freelancer, with an agency, or get a full-time job maintaining a single web product for the long term.

Also, these blog posts will just be scratching the surface of what the corresponding subfields entail. If you plan on getting a job with "engineering" in the title, don't think that you're wasting your time reading the first blog. It will not make you a UI expert by any means. It will just give you a better understanding of the field, which translates, among other things, into being a better teammate.

A last note on the format of these articles. I will be writing them as I'm actually reviewing all these concepts myself. It's me documenting my process of learning, kind of like a livestream. But since an actual livestream of that would be unendurably boring, I'm hoping this written format will be a nice middle ground: informative, (hopefully) not too much rambling, while still staying true to the non-linear process that is learning to become a self-taught web developer.