This release is about clearing that friction out. It’s a tightening pass on Bedrock Layout: fewer legacy props, clearer semantics, and a stronger alignment with native CSS.

The shape of the change

We’re not trying to be clever here. The breaking changes are intentionally boring—in the best way. They make the system easier to reason about and easier to teach.

Gap means gap

The old gutter prop is gone. We now use gap everywhere. That’s the vocabulary CSS already gives us, and it’s the one everyone already understands.

Migration:

• Replace gutter with gap anywhere you’re using layout primitives.

Columns now say what they mean

columns was ambiguous. colCount isn’t. It reads like a config value, not a layout command. That clarity matters.

Migration:

• Replace columns={...} with colCount={...}.

Custom spacing without a theme provider

The docs now emphasize the simplest, most portable path: if you want to plug in your own spacing tokens, use CSS custom properties directly.

Example:

<Stack gap="var(--space-3)">{...}</Stack>

No magic. No wrapper. Just your tokens.

Column offsets now match the CSS API

We aligned offset variables to the CSS-side naming (--offset-start / --offset-end). It’s a consistency fix—no behavioral change—but it eliminates a mismatch that was easy to trip over.

Components removed to reduce surface area

Some components have been removed rather than kept as thin wrappers. The goal is to keep the core primitives focused and avoid maintaining redundant APIs. This means AppBoundary and PadBox Components are gone. MasonryGrid has also been removed, as the new native Masonry layout spec is being developed.

Migration:

• Replace removed components with the recommended primitives (e.g., layout primitives plus style or small wrapper components).

Utility hooks moved to a separate repo

Legacy utility hooks have been migrated from this repo to a dedicated package. They’re still available, just no longer part of the core Bedrock Layout surface.

Migration:

• Install and import the hooks from the new utilities package rather than from the main Bedrock Layout repo.

Why we’re doing this

The core goal is to make Bedrock Layout boringly predictable. That means:

• fewer aliases,

• fewer “legacy” escape hatches,

• and fewer places where the docs disagree with the code.

If you’re upgrading, the migration is straightforward and mechanical. But the payoff is bigger than a clean diff: it’s a layout system that’s easier to explain, easier to onboard to, and easier to keep stable long-term.

In this post, we'll take a closer look at the ResizeObserver API and how it can be improved to make it easier to use in your projects.

The ResizeObserver API

The ResizeObserver API provides a way to observe changes in the size of a DOM element. It creates a new ResizeObserver object, which can then be used to observe a specific element. The observer will be notified whenever the size of the observed element changes and can take appropriate action in response.

To use the ResizeObserver API, you'll first need to create a new ResizeObserver object. You can do this by calling the ResizeObserver constructor, passing in a callback function that will be called whenever the size of an observed element changes.

const observer = new ResizeObserver(entries => {
  for (let entry of entries) {
    console.log(`Element: ${entry.target}`);
    console.log(`Width: ${entry.contentRect.width}`);
    console.log(`Height: ${entry.contentRect.height}`);
  }
});

Once you have created your observer, you can use the observe() method to start observing a specific element. This method takes a single argument, which is the element you want to observe.

const myElement = document.querySelector('.my-element');
observer.observe(myElement);

It's also possible to observe multiple elements at once by calling the observe() method.

const elements = document.querySelectorAll('.my-element');
observer.observe(elements);

The ResizeObserver API also provides a way to stop observing an element using the unobserve() method. This method takes a single argument, which is the element that you no longer want to observe.

observer.unobserve(myElement);

You can also stop observing all elements by calling the disconnect() method on the observer.

observer.disconnect();

What's the Problem, then?

The ResizeObserver API provides a powerful and efficient way to detect changes in the size of an element on a web page. Still, it is designed to be a one Observer fits all scenario. The callback we provide will be given all the observed elements resizing, and then, depending on the element, you can make various choices.

In practice, you are either creating too many resize observers because you want to run a unique callback for each element, like this:

const mainObserver = new ResizeObserver(()=>{})
mainObserver.observe(mainElement)

const sideBarObserver = new ResizeObserver(()=>{})
sideBarObserver.observe(asideElement)

// ect.

Or you stuff a whole bunch of logic into this huge monolithic observer function like this:

const monolithicObserver = new Resize Observer(entries=>{
    const entries.forEach(entry=>{
        /**
        * check each entry and run a unique set of code for 
        * Matching entries
        */
    })
})

Neither option is ideal. So I created an abstraction that lets me have the best of both worlds. It's called @bedrock-layout/register-resize-callback, and it's part of my Bedrock Layout Primitives library, found over at bedrock-layout.dev.

What is unique about this package is that it lets me register a special callback for each element I want to observe without having to instantiate multiple Resize Observers. In a future blog post, we can go into how it works, but for now, let's look at how you use it:

import { init, registerCallback } from '@bedrock-layout/register-resize-callback';

// initialize in a safe way when you know you are in the browser
init()

const header = document.querySelector('header');
const article = document.querySelector('article');

// register a callback for each node
// This will return a cleanup function
const cleanupHeader = registerCallback(header, (entry) => {
  console.log(entry);
})

const cleanupArticle = registerCallback(article, (entry) => {
  console.log(entry);
})

//unregister the callback
cleanupHeader()
cleanupArticle()

In the above code, we call the init function as soon as possible to initialize the ResizeObserver that our register callback depends on. This gives you the control you need to ensure that the initialization only happens in the browser. The init function only needs to be called once, but it can be called multiple times without consequences.

Once we are confident that everything is initialized properly. Then we use the registerCallback function to register a callback for each node we want to observe. If that element is resized, our callback will be called with the associated entry for that element. This allows your callback to focus on just that element you want to observe without worrying about anything else.

Finally, when we no longer want to observe those elements anymore, we can call the cleanup function that is returned from `registerCallback` which will both unregister our function and unobserve the element if no other callbacks have been registered on that same element.

Let's say you wanted to observe an element in a React application. Your component might look something like this:

import React, {useRef, useEffect} from 'react'
import { init, registerCallback } from '@bedrock-layout/register-resize-callback';

export function MyComponent(){
  const ref = useRef(null);
  const currentDiv = ref.current
  useEffect(() => {
    init();
    if(currentDiv){
     return registerCallback(currentDiv, () => {
        // do stuff
      })
    }
  },[currentDiv]);

  return <div ref={ref}>{/* stuff goes here*/}</div>
}

The ResizeObserver is powerful and allows you to do fantastic and dynamic things. Using the @bedrock-layout/register-resize-callback package makes it even more intuitive and practical in your apps.

In the meantime, Bedrock has continued to grow and evolve as a library. More primitives have been added, the doc site was moved to Storybook, and visual regression testing was added through chromatic. But the most significant addition out of all of the additions has to be the @bedrock-layout/css framework. Pretty much the same developer experience as the React library, using only CSS and no JavaScript.

Things have changed

At the same time that Bedrock Layout has been evolving, so has everything else. CSS and the three major browsers have hit some fantastic strides regarding CSS. They have been releasing new features on a much more consistent basis.

Another thing that has changed is that styled-components and CSS-in-JS tools, in general, have started to fall out as popular tools. There are many reasons why this is so. Nonetheless, building a library on top of styled-components means that Bedrock's adoption has been limited to only those projects that are willing to use styled-components.

In addition to this problem, maintaining both a CSS library and a React library built on styled-components means that I have to duplicate my effort every time I need to make a change. This increases the chance of divergences as well as just simple copy-paste errors.

Finally, to avoid breaking changes, we have maintained deprecated APIs even though they were no longer encouraged nor documented. All of these things have brought me to the conclusion that Bedrock needed to do a significant overhaul, or in other words, a breaking change.

Announcing The New and Improved Bedrock Layout Primitives

There are two significant changes that Bedrock Layout Primitives has made. The first is that Bedrock Layout no longer uses styled-components. It instead depends on its internal Bedrock Layout CSS, which you can install at @bedrock-layout/css. This now means you need to import the appropriate CSS files for the primitives you are using or simply import them all:

import "@bedrock-layout/css";
import "@bedrock-layout/css/lib/reset.css";

With this change, each package size has been cut in half and no longer has any runtime implications other than React itself. This makes Bedrock Layout great for any of your apps, no matter the React framework your team has chosen to adopt.

The other significant change has been that Bedrock Layout will no longer support its own spacing and sizes scheme. In the past, Bedrock's default spacing scheme was built on T-shirt sizes representing multiples of 1rem. It worked fine, but it doesn't make sense for Bedrock to maintain another spacing scheme when there are so many better ones.

With this new change, Bedrock has adopted a spacing and sizes theme based on open-props. Bedrock Layout now uses the following values:

{
  space:{
    size000: "-.5rem",
    size00: "-.25rem",
    size1: ".25rem",
    size2: ".5rem",
    size3: "1rem",
    size4: "1.25rem",
    size5: "1.5rem",
    size6: "1.75rem",
    size7: "2rem",
    size8: "3rem",
    size9: "4rem",
    size10: "5rem",
    size11: "7.5rem",
    size12: "10rem",
    size13: "15rem",
    size14: "20rem",
    size15: "30rem",
  },
  sizes: {
    sizeContent1: "20ch",
    sizeContent2: "45ch",
    sizeContent3: "60ch",
    sizeHeader1: "20ch",
    sizeHeader2: "25ch",
    sizeHeader3: "35ch",
    sizeXxs: "240px",
    sizeXs: "360px",
    sizeSm: "480px",
    sizeMd: "768px",
    sizeLg: "1024px",
    sizeXl: "1440px",
    sizeXxl: "1920px",
  }
}

In addition, some other breaking but insignificant changes have been that Bedrock has dropped the use of prop-types and uses only named exports for all the packages. Once again, not substantial, but breaking nonetheless.

What has really changed?

Not as much as it seems. Bedrock still works the same. It still helps you compose complex layouts from simple layout primitives.

export function Hero() {
  return (
    <Stack>
      <Inline>{/* */}</Inline>
      <Split>
        <Cover>
          <Stack>
            <h1>{/* */}</h1>
            <p>{/* */}</p>
            <Inline>
              <button>{/* */}</button>
              <button>{/* */}</button>
            </Inline>
          </Stack>
        </Cover>
        <Frame>
          <img />
        </Frame>
      </Split>
    </Stack>
  );
}

You can still bring your own spacing and sizing scheme via ThemeProvider and declaration merging:

import { ThemeProvider } from '@bedrock-layout/spacing-constants';

declare module "@bedrock-layout/spacing-constants" {
  export interface DefaultTheme {
    space: {
      "0x": number;
      "1x": CSSLength;
      "3x": CSSLength;
    };
  }
}

const space = {
    "0x": 0,
    "1x":'45px',
    "3x":'100ch'
}

<ThemeProvider theme={{ space }}>
    <Stack gutter="1x">
     {...}
    </Stack>
</ThemeProvider>;

You can also still provide values directly into the size and spacing values as usual:

<Stack gutter="var(--size-3)">
    <Split gutter='2rem' minItemWidth="30ch" switchAt="var(--size-content-1)">
        {/* ... */}
   </Split>
</Stack>

It just does all this better under the hood than it used to.

Check out this code pen and play around with it yourself: https://codesandbox.io/s/bedrock-layout-ts-template-64xwz?file=/src/index.tsx

What is on the horizon?

A significant initiative we have going forward is translating all the docs into as many languages as possible. With the help of a contributor, Carlos Cabrera, the landing page has been translated into Spanish. I want to put in the work and make it easier for future contributors to solve or fix the translation of any of the pages on the doc site.

I also would like to do more to bring the CSS Framework front and center and less as a second-class citizen.

I also feel that there needs to be more examples and recipes for using Bedrock Layout. If you would like to help out with any of these initiatives, please look at contributing.

What is a Maybe? I was first introduced to a Maybe when exploring the Elm programming language. The docs at Elm describe a Maybe best. This is what their docs say: "This is a type with two variants. You either have Nothing or you have Just a value."

That sounds simple enough, right? It either is something, or it is nothing. Well, that is where the JavaScript world makes things even more complicated. JavaScript doesn't just have a single Nothing type like many languages. Instead, it has two ways to represent Nothing: null and undefined. To take advantage of the concept of a Maybe, we need to simplify our Nothing states as either null or undefined.

First, we need to decide between the two. Because of the complicated history of null and the typeof bug that was introduced in the early drafts of JavaScript, I recommend that you embrace undefined as your Nothing state of choice. (If you want to read more about the bug, there is a nice article by Sourav Debnath about the typeof null bug)

That's well and good for the code you write, but what about other people's code? Many browser APIs return null for their Nothing state and other 3rd party libraries. What do you do about them?

What we need to do is convert the output from these APIs into a Maybe. I've created a simple, yet powerful utility that does just that:

function convertToMaybe(value) {
  return value ?? undefined;
}

This one-line function is made very simple using the nullish coalescing operator. Let's break it down. First, if the value passed in is neither null nor undefined, it will return the value passed in. If the value is null or undefined, however, it will return the value on the right side of the ??, which in our case is undefined. This guarantees that no matter what value we pass in, it will never return a null.

That sounds great in JavaScript, but I rarely write in plain JavaScript anymore. Most of my projects use TypeScript. Luckily there isn't much more we need to do to make this work well in TypeScript.

First, let's create our TypeScript Utility type:

type Maybe<T> = NonNullable<T> | undefined;

Here we are creating a Generic Type called T. If you are unfamiliar with Generics, Generics act as a placeholder for a future type not yet decided. Generics let us pass in a type, much like how we pass arguments to a function. We are then using the Generic T to pass into the NonNullable type, which basically ensures that T can't be null or undefined. We are then using the union type operator, |, to also allow undefined as an allowed value.

Simply put, The Maybe of any type will either be that type or undefined but never null. A Maybe<number>, for example, will be either number or undefined. The Maybe<null>, however, can only be undefined because null is not allowed.

Now that we have defined our Maybe utility type, let's update our function:

function convertToMaybe<T extends unknown>(value: T): Maybe<T> {
  return value ?? undefined;
}

In the above function, we added another Generic. We are not just defining a generic type of T, but we are also requiring that it extend the unknown type. And then we are saying our value parameter must be of type T and that the return value from the function will be a Maybe<T>.

I know you are probably asking, "Why are we going through all that extra boilerplate?" This way, TypeScript can infer the types based on the type of the value passed into the arguments. Now we can be sure that any value we are given is a Maybe value. If you have TypeScript, it will make you write defensive coding to ensure you don't have an empty value. Even if you are using JavaScript, the function will help you remember that the value I am getting back from the function might be undefined and I need to write defensive coding to protect myself.

Using Maybe values in your code is very powerful. Your code will be stronger and more resilient to empty values and allow you to fail gracefully in a state you can control.

Solid feels very familiar to react developers

Let's look at this arbitrary counter app written in solid.js:

function Counter() {
  const [count, setCount] = createSignal(0);
  return (
    <div>
      <p>The current count is: {count()}</p>
      <button onClick={() => setCount((x) => x + 1)}>Plus</button>
    </div>
  );
}

I am confident that any React developer can understand everything in the above component, despite never seeing solid.js before. This familiarity is because solid.js has an API familiar to React Developers. For one thing, solid.js utilizes JSX, which means elements and components can be composed in many of the same familiar ways that React developers have built an intuition for. For example, we can make this arbitrary Welcome component using just our intuition from building React Apps:

function Welcome(props) {
  return <p>Welcome, {props.name}</p>;
}

Solid.js also utilizes primitives with an API that is very similar to how one would use React hooks. The API of many of solid's reactive primitives are almost identical to their React Hook counterparts.

It's important to point out that solid.js is not attempting to follow React's API one-to-one. You cannot take a React app and start using it in solid.js. It does, however, have an API that is familiar to your average React developer, which makes the learning curve much nicer.

It's all about the primitives

Despite its superficial similarities, what makes solid.js unique is the ways that it is not like React. One of those ways is that, unlike React, the component is not the foundation of solid.js apps. Solid.js proudly describes its components as "vanishing components." Components are helpful for code organization and cease to exist once the initial render occurs.

For solid.js, it's all about the primitives. Solid.js has a suite of "fine-grained reactive primitives." These primitives can feel very similar to React Hooks, but they are not hooks. In React, hooks are dependent upon the React component lifecycle and require you to have at least a rudimentary understanding of the Virtual DOM and the React render lifecycles. This dependency on the React lifecycle is why there are so many "rules of hooks" that you need to know to use them correctly. Let's take this React Component, for example:

function Counter() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    document.title = `The current count is: ${count}`;
  }, [count]);

  return (
    <div>
      <p>The current count is: {count}</p>
      <button onClick={() => setCount((x) => x + 1)}>Plus</button>
    </div>
  );
}

Despite how simple this component is, there are several rules you need to remember, and forgetting any of them can cause unwanted problems. Solid's reactive primitives, on the other hand, just work. They can be called conditionally, and they don't even need to be called in a component themselves. The above counter component can be rewritten in solid.js like this:

const [count, setCount] = createSignal(0);

createEffect(() => {
  document.title = `The current count is: ${count()}`;
});

function Counter() {
  return (
    <div>
      <p>The current count is: {count()}</p>
      <button onClick={() => setCount((x) => x + 1)}>Plus</button>
    </div>
  );
}

We have moved all the reactive primitives outside of the component itself in the above component. We can do this because Solid's reactive primitives themselves, not the components, are what solid.js is built on and where the "magic" happens.

Reactivity VS Virtual DOM

Like many popular frameworks, React is built on the concept of a "Virtual DOM." A virtual DOM is an in-memory representation of the actual DOM. The idea is that doing things in memory is less expensive than working with the actual DOM, so one can run and re-run components multiple times, making changes to this virtual DOM. Only if there are actual differences between the virtual DOM and the real DOM will React reconcile those changes from the virtual DOM to the actual DOM. You are literally hooking into the React Virtual DOM Lifecycle when you use hooks.

Solid.js, on the other hand, depends on "fine-grained" reactivity. When you write a JSX expression that relies on a reactive signal, for example, only the part of the JSX that depends on that signal's value is wrapped in a function that is re-run if that signal changes. The same goes for effects run in the createEffect primitive. If the effect has a dependency on one or more reactive values, it will be re-run only if the reactive value changes. There is no need for a dependency array since solid knows in advance if the value can be changed and will re-run only those effects that depend on the changed reactive values.

This is why solid components are "vanishing," and reactive primitives can be called outside of the component. After the initial render, only those fine-grained parts of the app will continue to exist.

Gotchas coming from React

This difference in how the two frameworks work under the hood can lead to two of the biggest "gotchas" that React developers fall into when starting with solid.js. The first gotcha is you need to re-teach yourself that components don't ever get re-run. Those things that we have taught ourselves that we should (and shouldn't) do in a React component no longer apply in Solid.js. We don't need hooks like useCallback and useRef, because the component never re-runs. Instead, we can just assign them to variables like any other JavaScript code we write:

function MyForm() {
  const handleSubmit = (e) => {
    /* handl submit */
  };

  let myInput;
  // use onMount or createEffect to read after connected to DOM
  onMount(() => myInput.focus());

  return (
    <form onSubmit={handleSubmit}>
      <input ref={myInput} />
    </form>
  );
}

The second is that you can break the fine-grained reactivity if you destructure the props. The props object may or may not have reactive values in them. By destructuring them, that reactivity can be lost. So instead of writing code like this:

function Greeting(props) {
  const { greeting, name } = props;
  return (
    <h3>
      {greeting} {name}
    </h3>
  );
}

It would be best if you wrote it like this:

function Greeting(props) {
  return (
    <h3>
      {props.greeting} {props.name}
    </h3>
  );
}

Or you can utilize solid's mergeProps or splitProps utility functions, which allow you to merge or split objects with reactive values without breaking reactivity.

When React was introduced, it challenged the best practices of the day. That challenge has had a lasting impact on how we write web applications. Solid is here to continue to push us in that same direction that React started.

The Original Code

Let's start by looking at the raw code examples from the book:

//  people.csv
//  Name,   Age, Hair
//  Merble, 35,  red
//  Bob,    64,  blonde

function lameCSV(str) {
  return _.reduce(
    str.split("\n"),
    function (table, row) {
      table.push(
        _.map(row.split(","), function (c) {
          return c.trim();
        })
      );
      return table;
    },
    []
  );
}

var peopleTable = lameCSV(peoplsCSV);
// [
//     ['Name','Age','Hair'],
//     ['Merble','35','red'],
//     ['Bob','64','blonde'],
// ]

function selectNames(arr) {
  return _.rest(_.map(arr, _.first));
}

function selectAges(arr) {
  return _.rest(_.map(arr, second));
}

var zipped = _.zip(selectNames(peopleTable), selectAges(peopleTable));

console.log(zipped);
// [["Merble","35"], ["Bob","64"]]

In the above code, we have a function called lameCSV that parses a CSV file into an array of string arrays. We then have two helper functions, selectNames and selectAges that both do similar things. They both map over the array to retrieve either the first or second item in each array (we talked about the second function in a previous post). After that, they both use the _.rest utility from underscore.js to remove the first item in the array and return the rest.

Finally, we use both of those select functions with the _.zip utility to merge the results back together.

Modernizing

To modernize, let's start off with some low-hanging fruit. First, we can remove the var variable declarations and use either let or const. It is also good practice to use arrow functions as callbacks, so let's use those when appropriate. We no longer need the _.map and _.reduce functions so we can move those over to native array functions. In addition, I prefer to avoid mutating arrays, so let's change our table.push to table.concat.

function lameCSV(str) {
  return str
    .split("\n")
    .reduce(
      (table, row) => table.concat(row.split(",").map((c) => c.trim())),
      []
    );
}

function selectNames(arr) {
  return _.rest(arr.map(first));
}

function selectAges(arr) {
  return _.rest(arr.map(second));
}

The next thing we can do to modernize is move away from using the _.rest function from underscore. In modern JavaScript we can use the rest parameter to do the exact same thing:

function selectNames(arr) {
  const [, ...rest] = arr.map(first);
  return rest;
}

function selectAges(arr) {
  const [, ...rest] = arr.map(second);
  return rest;
}

While we are talking about removing underscore functions, lets make our own zip functions:

function zip(...args) {
  const longestLength = Math.max(...args.map((arg) => arg.length));

  const arrayOfIndexes = Array.from(Array(longestLength).keys());

  return arrayOfIndexes.map((i) => args.map((array) => nth(array, i)));
}

In our zip function, first, we are collecting all the arrays passed in under a single array called args using the rest parameter. From there we use the args to find the length of the longest array in the args. After that, we create an array of indexes with this code: Array.from(Array(longestLength).keys()). What this does is create an array with the same length as the longestLength. By calling the keys method on that array we then get an iterable of all the indexes of that array. Since it is an iterable and not an array itself, we wrap the whole thing in Array.from to convert it back to an array.

Finally, the last thing we do is map over the arrayOfIndexes and use that index to create an array of all the values at that index in each array.

So here is the final version of the modernized code:

//  people.csv
//  Name,   Age, Hair
//  Merble, 35,  red
//  Bob,    64,  blonde

function lameCSV(str) {
  return str
    .split("\n")
    .reduce(
      (table, row) => table.concat(row.split(",").map((c) => c.trim())),
      []
    );
}

var peopleTable = lameCSV(peoplsCSV);
// [
//     ['Name','Age','Hair'],
//     ['Merble','35','red'],
//     ['Bob','64','blonde'],
// ]

function selectNames(arr) {
  const [, ...rest] = arr.map(first);
  return rest;
}

function selectAges(arr) {
  const [, ...rest] = arr.map(second);
  return rest;
}

function zip(...args) {
  const longestLength = Math.max(...args.map((arg) => arg.length));

  const arrayOfIndexes = Array.from(Array(longestLength).keys());

  return arrayOfIndexes.map((i) => args.map((array) => nth(array, i)));
}

var zipped = zip(selectNames(peopleTable), selectAges(peopleTable));

console.log(zipped);
// [["Merble","35"], ["Bob","64"]]

Now with TypeScript

First let's type our lameCSV function:

type Table = string[][];

function lameCSV(str: string): Table {
  return str
    .split("\n")
    .reduce<Table>(
      (table, row) => table.concat(row.split(",").map((c) => c.trim())),
      []
    );
}

It takes a string, so that is easy to type. It technically returns an array of string arrays, which is string[][], but often it is nice to give a type like that a name that has more meaning. In our case, we have created a type Table that is technically a string[][] under the hood. This not only gives the return value of this function more meaning, it gives our other functions meaning as well. We can type our select functions like this:

function selectNames(arr: Table) {
  const [, ...rest] = arr.map(first);
  return rest;
}

function selectAges(arr: Table) {
  const [, ...rest] = arr.map(second);
  return rest;
}

This makes it more clear that these functions are intended to be paired with the lameCSV function since their input is the output of the lameCSV function is their input. Unlike some type systems, TypeScript is a structural type system. This means that you can still pass in anything that happens to have the same type as string[][] to these functions and it will work. That said, by giving it the type Table you are using your types to do a form of domain modeling, which simply put is documenting the relationship between the parts of your code.

The final thing we need to do is type our zip function. Let's start with the finished version and then let's explain it:

function zip<T extends Array<unknown[]>>(...args: T): T[number][] {
  const longestLength = Math.max(...args.map((arg) => arg.length));

  const arrayOfIndexes = Array.from(Array(longestLength).keys());

  return arrayOfIndexes.map((i) => args.map((array) => nth(array, i)));
}

In the above code, we are declaring that the args are of type T and that T extends Array<unknown[]>. This allows TypeScript to do two things. First, it will enforce that all the arguments passed in are arrays. The other thing that it will do is infer the type from the arrays passed. This brings us to the return type. We are declaring that the return value is T[number][], which means that the return will be an array of whatever type is at any index of T. So now our final typescript version looks like this:

//  people.csv
//  Name,   Age, Hair
//  Merble, 35,  red
//  Bob,    64,  blonde

type Table = string[][];

function lameCSV(str: string): Table {
  return str
    .split("\n")
    .reduce<Table>(
      (table, row) => table.concat(row.split(",").map((c) => c.trim())),
      []
    );
}

var peopleTable = lameCSV(peoplsCSV);
// [
//     ['Name','Age','Hair'],
//     ['Merble','35','red'],
//     ['Bob','64','blonde'],
// ]

function selectNames(arr: Table) {
  const [, ...rest] = arr.map(first);
  return rest;
}

function selectAges(arr: Table) {
  const [, ...rest] = arr.map(second);
  return rest;
}

function zip<T extends Array<unknown[]>>(...args: T): T[number][] {
  const longestLength = Math.max(...args.map((arg) => arg.length));

  const arrayOfIndexes = Array.from(Array(longestLength).keys());

  return arrayOfIndexes.map((i) => args.map((array) => nth(array, i)));
}

var zipped = zip(selectNames(peopleTable), selectAges(peopleTable));

console.log(zipped);
// [["Merble","35"], ["Bob","64"]]

With that, we have officially modernized all the examples from chapter 1. I hope you enjoyed this series so far and that you will keep looking out for future posts on this.

const myArr = [1, 2, 3];

myArr.push(4);
// myArr = [1, 2, 3, 4]

const popped = myArr.pop();
/**
 * popped = 4
 * myArr = [1, 2, 3]
 */

const spliced = myArr.splice(1, 1);
/**
 * spliced = 2
 * myArr = [1, 3]
 */

On the other hand, methods like map, filter, and slice are non-mutating because they do not change the array they are called on. Instead, they create a new array from them, like this:

const myArr = [1, 2, 3];

const myArrPlusOne = myArr.map((x) => x + 1);
// myArrPlusOne = [2, 3, 4]

const onlyOdd = myArr.filter((x) => x % 2 === 1);
// onlyOdd = [1, 3]

const sliced = myArr.slice(1, 1);
// sliced = [2]

console.log(myArr);
// [1, 2, 3]

However, there is one method that is often mistaken as a non-mutating method but is mutating. This method is the sort method. The sort method takes a comparator function and sorts the array called on. What makes it "feel" like a non-mutating array is that it also returns the now sorted array:

const unsortedArr = [5, 1, 2, 4, 3];

const sortedArr = unsortedArr.sort((a, b) => a - b);

console.log(unsortedArr);
// [1, 2, 3, 4, 5]

console.log(Object.is(sortedArr, unsortedArr));
// true

By returning itself, it allows us to chain the sort method among other array methods. Unfortunately, this means that we can accidentally mutate an array we never intended to:

const clientIds = [5, 1, 2, 4, 3];

const sortedClients = clientIds
  .sort((a, b) => a - b) //oops just mutated the clientIds array
  .map(idToClientObject);

"Fixing" the sort method

Wouldn't it be great if we could "fix" the sort method so that it would return a sorted array without sorting the array it was called on? Well, we can, by using Proxy objects. Proxy objects let you pass in a target object and object of handlers that define the behavior of the proxy object. It will then return a new object that has this new behavior. Let's start by creating a function that will take an array and return a new proxy wrapped array:

function createSafeSorter(arr) {
  return new Proxy(arr, {});
}

We can trap many behaviors, but the handler we want to define is the get handler. The get handler is called whenever a property is retrieved from the target object. This includes when we call methods on the target. Knowing that, let's create our handler:

function createSafeSorter(arr) {
  return new Proxy(arr, {
    get: (target, prop, receiver) => {
      if (prop === "sort") {
        return (comparator) => [...target].sort(comparator);
      }

      return Reflect.get(target, prop, receiver);
    },
  });
}

In the above code, we assign a function to the get property of our handler object. This function accepts a target, which is the object passed into the proxy, a prop which is the name of the property that the code is trying to get, and the receiver, which is either the proxy or an object that inherits from the proxy (not necessary for what we are doing).

The handler checks if the prop is the sort method. If it is, it will return a new function that takes a comparator and uses that function to sort a copy of the original array. Otherwise, we pass the target, prop, and receiver to the get method of the Reflect object. The Reflect object is super simple. It complements the Proxy objects in that it has static methods that you can create handlers for. Passing the arguments received in our handler function into the same method on the Reflect object will return the original value. That was a long way of saying everything else will work the same.

Now we can pass in an array and get back an array wrapped in a proxy that will use our safe sort method instead of the native sort method. Everything is excellent, right? We have one last thing we need to fix. We are copying the array and then sorting it in the above handler, but that new array is not wrapped in a proxy. This means that if we need to call sort again, we will end up mutating our new array, for example:

const unsorted = createSafeSorter([5, 2, 4, 1, 3]);

// Works great
const lowToHigh = unsorted.sort((a, b) => a - b);

// Oops, we did it again
const highToLow = lowToHigh.sort((a, b) => b - a);

Luckily the solution is easy. We just need to do a little recursiveness and wrap our new sorted array in our createSafeSorter function:

function createSafeSorter(arr) {
  return new Proxy(arr, {
    get: (target, prop, receiver) => {
      if (prop === "sort") {
        return (comparator) => createSafeSorter([...target].sort(comparator));
      }

      return Reflect.get(target, prop, receiver);
    },
  });
}

Now we can do this lot of code safely:

const unsorted = createSafeSorter([5, 2, 4, 1, 3]);

// Works great
const lowToHigh = unsorted.sort((a, b) => a - b);

// Also safe!!!
const highToLow = lowToHigh.sort((a, b) => b - a);

Why you shouldn't do this

Now that I have spent a whole blog post on how to make your sort method safe and non-mutating, I am going to recommend that you don't do this in your codebase ever. If you do this, you and your team may know that the array being passed around uses a safe sort, but not everyone else does. Other people and third-party packages have written code based on the fact that sort is mutating. If you change that behavior, you can create so many unintended consequences. It is this exact reason why browsers will never fix the typeof null === 'object' bug. So much defensive code has been written around this fact that you would break the web if you "fixed" it. If you like, create a safeSort utility for your project and use that any time you sort:

function safeSort(arr, comparator) {
  return [...arr].sort(comparator);
}

Anyway, I hope you enjoyed this journey into using Proxy objects and why you shouldn't use them to "fix" the platform.

There is one problem set in particular that has tested my knowledge. In one of the problem sets, intended to help learn about looping, I wrote a solution using a trie data structure (pronounced "try"). Even though a regular student wouldn't know about this structure, I decided to use it to help me learn and understand it better. In the rest of this post, I will go over the trie data structure and its usefulness.

What is a trie?

A trie data structure is a data structure that is best used to optimize retrieving data. In fact, the name trie comes from the four letters in the middle of the word retrieval (reTRIEval). Simply put, a trie is a bunch of nested objects that efficiently store data.

The trie data structure is best understood with a use case. Let's say we want to have a list of current users on a website to search through. We want to show all valid users that start with what our user has typed so far as our user types. We could put it all in an array and search for it like this:

function getNames(namePart, validNames){
    return validNames.filter(name=>\^rob\.test(name))
}

This is simple and easy to understand, but it can be rather inefficient to keep checking the entire array every time the user types a letter. This is especially true if the list of users becomes huge.

A trie takes advantage of the fact that we have overlapping string parts, and we can store them in a nested object that takes advantage of that. Let's say we have the following names: Sandy, Rex, Robert, Sara, Rob, and Sarah. We can put them in a trie that would look something like this diagram:

Each node represents a letter, with special markers on those nodes representing the end of a name. You can already see how efficient this is. As soon as you type one letter, you throw away 25 possible paths. We continue to narrow down the possibilities rapidly for each letter, drastically reducing the number of options as we go.

To implement a trie in JavaScript with just the name rex, it would look like this:

const trie = {
  end: false,
  children: {
    r: {
      end: false,
      children: {
        e: {
          end: false,
          children: {
            x: {
              end: true,
              children: {},
            },
          },
        },
      },
    },
  },
};

This may not be very readable for a human, but it is beneficial to write code around. To add a word, we can traverse the tree, adding new nodes as needed along the way. The same is true for finding words. One needs to traverse the tree, finding all the children nodes that the end property is true

The specific problem

I needed to check if a user's input was a valid word in an array of words in the problem set. Normally I would do something like wordlist.includes(validWords). The problem is that once per word, a user can replace a vowel with the * wildcard character that could represent any vowel. In other words, c*t would match to cat, cot, or cut.

To do this with an array would be possible, but it would not be straightforward to read or write. Let's say we have converted the word list to a trie. We could easily write a lookup like this:

function checkIsValidWord(word, trieNode) {
  if (word === "") return trieNode.end;

  const nextLetters = word[0] === "*" ? "aeiou" : word[0];
  const remainingWord = word.substring(1);

  const defaultNode = { end: false, children: {} };

  return nextLetters.split("").reduce((validWordFound, char) => {
    const nextNode = trieNode.children[char] ?? defaultNode;
    return validWordFound || checkIsValidWord(remainingWord, nextNode);
  }, false);
}

The above function is a recursive function that takes a word and a trieNode. Since it is recursive, we start the function with a base case. If the string is empty, the trieNode passed in is the final node, and we can return the value at the end property.

If the word is not an empty string, then we do two things: grab the next character(s) to check and assign it to nextLetters. If the next character is *, we need to check the aeiou string. Otherwise, we check the next character. After that, we take the remaining part of the word as the next word to check. Otherwise, we will just check the next letter.

After that, we split the nextLetters string into an array of characters. We reduce that array of characters by checking if we have found a valid word yet, and if not, we call the checkIsValidWord function with the remaining characters and the node of the character we are checking.

By adopting a data structure design for what we want to do, we have made both an efficient and elegant solution for a potentially complicated problem.

That said, I've always been curious about what skills and knowledge one gains while getting a degree in Computer Science. I've asked several people if their degree helps them in their day-to-day job, and most say not that much. That said, It is hard to measure how much the things learned in a degree help you learn new skills. There is no doubt that the programing class I took my senior year helped me learn to code more than 20 years later. In that same vein, those who have gotten a degree in Computer Science have an interesting skill that others don't.

I'm getting a CS degree in 2022, kinda

Another exciting part of the modern web is that schools like MIT and Harvard provide many online courses for free. It is legit possible to "take" all the required classes for some of the degrees at MIT 100% online for free. I get it that you don't get credit for it, but all the skills and knowledge are there to be learned for free.

So that is what I am going to do in 2022. I will earn my CS degree using MIT Open Course Ware and the required course list found at MIT's Department of Electrical Engineering and Computer Science website.

Since I am the one giving myself this "degree," I will go ahead and accept my previous business degree in place of taking any general studies. This means the courses I am going to take are the following, in order:

1. 6.0001 - Introduction to Computer Science Programming in Python
2. 6.0002 - Introduction to Computational Thinking and Data Science (replacement for Fundamentals of Programing since it isn't available)
3. 6.004 - Computation Structures
4. 6.006 - Introduction to Algorithms
5. 6.02 - Introduction to EECS via Communication Networks
6. 6.031 - Elements of Software Construction
7. 6.033 - Computer Systems Engineering
8. 6.034 - Artificial Intelligence
9. 6.042J - Mathematics for Computer Science
10. 6.046J - Design and Analysis of Algorithms

In addition, I will need to pick two courses from the advanced undergraduate courses, but I will put that off until after I have finished the other courses. I intend to finish all of these courses in 2022 to end the year with my special CS degree.

One final note, I will use TypeScript for all the courses when at all possible, and I will push up all the code to GitHub.

That's, my goal for 2022 and I hope you follow me as I go through this journey this year.

Comparator Functions vs Predicate Functions

Before we go into the code, we need to go into some terminology. There are generally two ways to write functions that compare things. There is the intuitive way which is to take your inputs and return true or false, like this:

function checkIsLessThan(x, y) {
  return x < y;
}

These functions are called predicates. Another comparing function will take two values and return a number greater than 0 if the first value is greater than the second, less than 0 if it is less than the second, and return 0 if they are equal. These functions are called comparators. It is common to see it used in the Array.sort method:

[5, 1, 3, 8].sort((a, b) => a - b);
// [1, 3, 5, 8]

The difficulty is that comparators are not always intuitive to write, especially when what you are comparing are not numbers but instead are objects of users. They are also not generally useful outside of those contexts that need them.

In the book, Functional Javascript, we are given a function called comparator that takes a preditcate function and returns an comparator function that does the same logic. Here is that original code example:

function comparator(pred) {
  return function (x, y) {
    if (pred(x, y)) return -1;
    else if (pred(y, x)) return 1;
    else return 0;
  };
}

[5, 1, 2, 8].sort(comparator((a, b) => a < b));
// [1, 2, 5, 8]

[5, "1", "2", 8].sort(comparator(isString));
// ["2", "1", 5, 8]

(Technically, in the book, each of the pred calls are wrapped in a function called truthy, but that function is not really part of this discussion, so I am intentionally leaving that out. I think you can guess what the truthy function does on a high level.)

The above code takes a predicate function, and it will return a function that takes two arguments. It will first pass the arguments to the predicate function in the order it received them. If it returns a true, the function will return -1. Otherwise, it will check the value in the predicate function again, but this time with arguments switched. Once again, if the value is true, the function will return 1. If neither function calls return true, it will return 0.

So let's modernize it. In a previous post, I mention that I have two rules of function styles:

1. I prefer the traditional syntax for top-level, named functions.
2. I prefer the arrow syntax for anonymous functions, with implicit returns if the return is simple

The other thing that I prefer, is to avoid the else statement in my if-blocks. Given those two things, we can refactor our comparator function like this:

function comparator(pred) {
  return (x, y) => {
    if (pred(x, y)) return -1;
    if (pred(y, x)) return 1;
    return 0;
  };
}

[5, 1, 2, 8].sort(comparator((a, b) => a < b));
// [1, 2, 5, 8]

[5, "1", "2", 8].sort(comparator(isString));
// ["2", "1", 5, 8]

Now let's add types. First of all, I think it is worth our time to define a PredicateFunction type and a ComparatorFunction type:

type PredicateFunction = (x: unknown, y: unknown) => boolean;

type ComparatorFunction = (x: unknown, y: unknown) => 1 | -1 | 0;

In the above, we state that both functions take two unknown values and will either return a boolean if it is of a PredicateFunction type or 1 | -1 | 0 if it is of a ComparatorFunction type. One could argue that a ComparatorFunction type only needs to return a number, but I would prefer to be more specific if that is possible.

So now the only thing we need to do is to add that to our function signature, like this:

function comparator(pred: PredicateFunction): ComparatorFunction {
  return (x, y) => {
    if (pred(x, y)) return -1;
    if (pred(y, x)) return 1;
    return 0;
  };
}

[5, 1, 2, 8].sort(comparator((a, b) => a < b));
// [1, 2, 5, 8]

[5, "1", "2", 8].sort(comparator(isString));
// ["2", "1", 5, 8]

Luckily, nothing else is needed. All other types can be inferred from these two types added to the function signature. We have a nice type-safe utility function that takes in a predicate function and returns a comparator function.

Here are the original examples:

function isIndexed(data) {
  return _.isArray(data) || _.isString(data);
}

function nth(a, index) {
  if (!_.isNumber(index)) fail("Expected a number as the index");
  if (!isIndexed(a)) fail("Not supported on non-indexed type");
  if (index < 0 || index > a.length - 1) fail("Index value is out of bounds");

  return a[index];
}

function second(a) {
  return nth(a, 1);
}

second("abc"); // b
nth([1, 2, 3], 0); // 1
nth({}, 2); // Error: Not supported on non-indexed type

The nth function takes in an indexable value and an index. It does some guards to make sure you have actually passed in an indexable value and an index that is in bounds, and if everything is safe, it will return the value at the index. Since we already went over the fail function in the previous post, I have left that code out.

Let's start with the isIndexed function. This uses two utilities from underscore.js to confirm if the value is either an array or a string. There isn't an "array" type in JavaScript that you can check using the typeof operator. If you call typeof [], you will get "object." This is because arrays are just objects under the hood. In the past, we relied on utility functions, like _.isArray to reliably check if value actually is an array and not just an object.

Luckily, we have a static method on the Array object called isArray that does this without needing a utility library. You can learn more about Array.isArray over at MDN.. Also, in the last post, we created our own assertIsString function. We can steal that logic and replace both of these checks like this:

function isString(value) {
  return toString.call(value) === "[object String]";
}

function isIndexed(data) {
  return Array.isArray(data) || isString(data);
}

As for the nth function, the only thing we have in there that should be updated is the _.isNumber function from underscore. We can adapt our isString function to be an isNumber function with one tweak:

function isNumber(value) {
  return toString.call(value) === "[object Number]";
}

So we can update the example to look like this:

function isNumber(value) {
  return toString.call(value) === "[object Number]";
}

function isString(value) {
  return toString.call(value) === "[object String]";
}

function isIndexed(data) {
  return Array.isArray(data) || isString(data);
}

function nth(a, index) {
  if (!isNumber(index)) fail("Expected a number as the index");
  if (!isIndexed(a)) fail("Not supported on non-indexed type");
  if (index < 0 || index > a.length - 1) fail("Index value is out of bounds");

  return a[index];
}

function second(a) {
  return nth(a, 1);
}

second("abc"); // b
nth([1, 2, 3], 0); // 1
nth({}, 2); // Error: Not supported on non-indexed type

Now, let's add types. Our is functions are simple enough. Each one takes an unknown value and determines if it is something, so let's type them like this:

function isNumber(value: unknown) {
  return toString.call(value) === "[object Number]";
}

function isString(value: unknown) {
  return toString.call(value) === "[object String]";
}

function isIndexed(data: unknown) {
  return Array.isArray(data) || isString(data);
}

Now let's add the types to our nth function. In the previous post, I typed the function as unknown, partially because I wanted to keep the spirit of how the function was written but partially so we could learn more about assertion functions. In a real TypeScript code base, we would write the types much more explicitly.

Our nth function takes two arguments: a and index. index is simple enough to type because it needs to be of type number. a could either be a string or an array. So first, let's create a type called Indexed:

type Indexed = Array<unknown> | string;

This essentially says that Indexed could be an array of unknown values or a string. Now we could do something like this:

function nth(a: Indexed, index: number) {}

But this will force the value of a to be an array of unknown values if we pass in an array. Let TypeScript infer what type of array we are passing in would be much nicer. Luckily we can do that using generics. Let's look at the updated types:

function nth<T extends Indexed>(a: T, index: number): T[number] {}

Let's break that down. First, we are saying that nth takes a generic value of T that must extend the Indexed type we declared. Then we say that a is of type T and that we are returning T[number] or the value at the index of T.

By having T extend Indexed, we are now letting Typescript infer the array's values to know the return type accurately. For example, if we call nth([1,2,3], 0), Typescript will know that the return type is of a type number.

The second function below can be typed the same way, except it wont need an explicit return type since it can infer that from the nth function we are calling. So now let's update the entire example using TypesScript:

function isNumber(value: unknown) {
  return toString.call(value) === "[object Number]";
}

function isString(value: unknown) {
  return toString.call(value) === "[object String]";
}

function isIndexed(data: unknown) {
  return Array.isArray(data) || isString(data);
}

type Indexed = Array<unknown> | string;

function nth<T extends Indexed>(a: T, index: number): T[number] {
  if (!isNumber(index)) fail("Expected a number as the index");
  if (!isIndexed(a)) fail("Not supported on non-indexed type");
  if (index < 0 || index > a.length - 1) fail("Index value is out of bounds");

  return a[index];
}

function second<T extends Indexed>(a: T) {
  return nth(a, 1);
}

second("abc"); // b
nth([1, 2, 3], 0); // 1
nth({}, 2); // TypeError

There you have it, a fully modernized and typed example from the classic "Functional JavaScript." I highly recommend checking it out, and I'll see you next time.

Introducing the AVO method

Luckily, I was introduced to a different way of writing my CSS called the AVO method. The AVO method, which stands for Attribute Values-Objects, is a BEM dialect created by Michael Chan that uses data attributes instead of class names. This is unique in that I can point my selectors to the data attribute and use the value assigned to the data attribute.

A tradional class name approach would have yielded something like this:

<header class="split hero split-fraction-1/4 center-text" style="--gutter:1rem">
  <!-- Hero content here-->
</header>

The above example can be rewritten like this:

<header
  data-bedrock-split="fraction:1/4"
  style="--gutter:1rem"
  class="hero center-text"
>
  <!-- Hero content here-->
</header>

At first glance, not much has changed, but you will notice some fantastic benefits immediately after further inspection. First, using a data attribute forces you to keep the styling of the data attribute together, unlike the class-based methodologies that can’t stop you from putting your classes in any order you want. Even more important is that you get that prop-like API we love in our front-end frameworks.

There is no way I can do it justice in this short post, so I highly recommend you check out Michael's fantastic content on the subject:

https://chan.dev/posts/avo-a-bem-dialect-using-data-attributes/

For the rest of the post, I want to show some good patterns I found when converting my React-based components to CSS-based components.

How to translate boolean props and props with a fixed number of values

Boolean props are very easy to implement. Much like how you do boolean props in React, you can select based on the existence of the string.

For example, The Center component has two boolean props: centerText and centerChildren. To convert this to AVO, one needs to select based if that string exists, like this:

[data-bedrock-center~="center-children"] {
  display: flex;
  flex-direction: column;
  align-items: center;
}

[data-bedrock-center~="center-text"] {
  text-align: center;
}

Then we can apply it like this:

<div data-bedrock-center="center-text">
  <!-- text alignment will be centered -->
</div>

<div data-bedrock-center="center-children">
  <!-- children will be centered -->
</div>

<div data-bedrock-center="center-text center-children">
  <!-- text alignment and children will be centered -->
</div>

You will notice in the above example that we are using ~=. If we only use =, the string must be an exact match. However, ~= lets us look for any of the space-delimited words to find a match.

Note this will not match on partial words. If I used the string center-children-vertically, this would not match. There is a way to do this kind of math, but I only recommend it for a particular scenario, which I will review later.

This strategy also works well if your prop's values are enumerable; in other words, there is a fixed amount of acceptable values. Here I would use a naming pattern where you provide both the prop name and value delimited by a semi-colon: <prop-name>:<value>.

For example, the Split component has a fixed set of values for it's fraction prop: 1/4, 1/3, 1/2, 2/3, 3/4, auto-start, and auto-end. This would translate to fraction:1/4, fraction:1/3, and so on.

With this in mind, we can write our CSS like this:

[data-bedrock-split~="fraction:1/4"] {
  grid-template-columns: 1fr 3fr;
}

[data-bedrock-split~="fraction:1/3"] {
  grid-template-columns: 1fr 2fr;
}

[data-bedrock-split~="fraction:1/2"] {
  grid-template-columns: 1fr 1fr;
}

[data-bedrock-split~="fraction:2/3"] {
  grid-template-columns: 2fr 1fr;
}

/* ect */

and we can use that in our HTML, like this:

<div data-bedrock-split="fraction:1/4">
  <div />
  <div />
</div>

<div data-bedrock-split="fraction:1/3">
  <div />
  <div />
</div>

<div data-bedrock-split="fraction:1/2">
  <div />
  <div />
</div>

<div data-bedrock-split="fraction:2/3">
  <div />
  <div />
</div>

How to translate props with unknown values

Sometimes props rely on the user to provide a value, and there is no way to control those values ahead of time. In those scenarios, you may want to reach for a custom property. CSS custom properties, also known as CSS variables, let you define your own properties and values, which you can use in your CSS. Often we see these values being declared in the root, like this:

:root {
  --my-custom-size: 15px;
  --my-custom-color: dodgerblue;
}

The thing is that nothing says can't be declared inline like this:

<div style="--my-custom-size: 15px; --my-custom-color: dodgerblue;"></div>

This allows us to use them in a very "prop" like way. For example, The Center component has a prop called maxWidth that accepts any CSS length or percentage. We can translate that into a CSS custom property like this:

[data-bedrock-center] {
  max-inline-size: var(--maxWidth, 100%);
}

and we can then use that in our HTML like this:

<div data-bedrock-center style="--maxWidth: 75%">
  <div>
    Nulla luctus nisl nec dui auctor volutpat. Phasellus condimentum elementum
    enim in pharetra.
  </div>
</div>

Some of you might be saying, wait, inline styles are bad, aren’t they? And the answer to that is: no, they are not bad. CSS follows an exception-based styling where you start with the most general styles and then work down to the most specific styles. Inline styles are meant to be the most specific parts of your styles, the ultimate exception. If you used them for all your styling, it would be bad, but these are being used to make one specific change to a specific element on the page, so no, they are not bad to use in this case.

Styling based on the existence of a prop

Sometimes you only want to add styles if a prop exists and is not based on its value. For example, the user can use the Inline component to pass in a CSS length to a switchAt prop to define the threshold that the component will switch to a stacking layout. If the threshold isn't provided, I don't even want certain styles applied.

To achieve this in the AVO method, we need to change our selector slightly. Instead of using ~=, we will use *= instead. This will let us search for the existence of a string, no matter if it's part of a larger string. So we can write our AVO style of the switchAt prop like this:

[data-bedrock-inline][style*="--switchAt"] {
  flex-wrap: wrap;
}
[data-bedrock-inline][style*="--switchAt"] > * {
  min-inline-size: fit-content;
  flex-basis: calc((var(--switchAt) - (100% - var(--gutter))) * 999);
}

The above code is looking for the existence of the --switchAt custom property being passed inline to the style attribute. If it does, it will apply styles to both the parent and all the children. Otherwise, these styles will not be applied. So now we can write that in HTML like this:

<div data-bedrock-inline style="--switchAt: 45rem">
  <div />
  <div />
  <div />
  <div />
</div>

In conclusion, the AVO method is a powerful and flexible way to write CSS that can help you create CSS-only components with a prop-like API. By using data attributes instead of class names, you can keep your styling organized and easy to maintain. We've shown you some good patterns to follow when translating React-based components to CSS-based components, including how to handle boolean props, props with a fixed number of values, and props with unknown values. We hope this article has been helpful and that you'll consider using the AVO method in your next project. Don't forget to check out the Bedrock Layout CSS version on Github and Michael Chan's content on the subject for more information.

The React Docs are great and getting better, but I have always felt it lacked a basic explanation of how to fetch data. So much is devoted to state and props; we don’t get into where that state and props come from.

Some great libraries, like React-Query, help fetch data in a React app, but, unfortunately, we don’t at least have some basic concept of data fetching before we bring in a 3rd party library that we may or may not need.

For this reason, I thought I would quickly go over some basics regarding data fetching and some opinions that I like to follow.

The Basics

There are two essential parts to data fetching: We need to trigger an action to get the data, and we need to store that data somewhere. This means we need to use useEffect and useState to handle those two-part. This is what that looks like:

const UserCard = () =>{  
  const [user, setUser] = useState()  

  useEffect(()=>{   
    fetch('/api/user/travis')  
     .then(res=>res.ok ? res.json() : Promise.reject(res))  
     .then(setUser)  
  })  

  return (/* render card here */)   

}

In the above component, we have state that is updated when we get a user back from our API. That is the bare minimum we need when fetching data in a React app. Now chances are we want our Card to be a bit more dynamic, so lets, quickly update it to take any user:

const UserCard = ({ userName }) =>{  
  const [user, setUser] = useState()  

  useEffect(()=>{   
    fetch(`/api/user/${userName}`)  
     .then(res=>res.ok ? res.json() : Promise.reject(res))  
     .then(setUser)  
  },[userName])  

  return (/* render card here */)   

}

With this update, we will get the user data of whichever userName is passed in. If the userName prop changes, we will fetch new data and set it to state when it returns.

This might not seem like much, but this is all you need to know to start fetching data in a React Component. However, I think it would be helpful to share my opinions on some of my personal best practices.

Move the ‘fetching’ into its own function

The “how” we get our data is not crucial to our React Component. All it cares about is that it requests the data and what to do when it comes back. There is also much more you need to do with the returned data than what my examples show. One typically gets more data back than you need. Also, sometimes the data you need requires multiple API calls. API’s also change, and maintaining that across your app can get complicated if each React component knows too much about how the data is fetched.

For this reason, I prefer to move the implementation of the fetching into its own function, typically in an api folder for organization purposes:

function getUserData(userName){  
   return fetch(`/api/user/${userName}`)  
     .then(res=> res.ok ? res.json() : Promise.reject(res))  
     .then(({fullName, images, bio})=>({  
       name:fullName,  
       avatar:images.large,  
       bio,   
     }))  
}

Now our UserCard can be updated like this:

const UserCard = ({ userName }) =>{  
  const [user, setUser] = useState()  

  useEffect(()=>{   
    getUserData(userName)  
     .then(setUser)  
  },[userName])  

  return (/* render card here */)   

}

This is much easier to reason about in our Component and is more resilient if we change our back-end API.

Handle all the states

Fetching data is not as simple as getting data and showing it. When you are fetching data, you are always in one of three states. You are either loading data, have the data, or there was an error fetching the data.

So it would be best if you handled all those states in your component, for example:

const UserCard = ({ userName }) =>{  
  const [user, setUser] = useState()  
  const [loading, setLoading] = useState(true)  
  const [error, setError] = useState()  

  useEffect(()=>{   
    setLoading(true)  
    setError()  

    getUserData(userName)  
     .then(setUser)  
     .catch(setError)  
     .finally(()=>setLoading(false))  

  },[userName])

  if(error){  
   return (/* error state */)  
  }

  if(loading){  
   return (/* loading state */)  
  }

  return (/* render card here */)   

}

In our useEffect we start by initializing our loading and error states. We do this so that we will set our states back to their initial states and then fetch the data if the prop changes. On top of that, we added a catch and finally to our promise chain. If there is an error, we will catch that and set the error state. We use finally so that we will set the loading state to false no matter if we have an error.

There is also another state that we often forget about. This is what do we do if the component unmounts before our data gets back? We will have an error if we try to update any of our states after the component has unmounted. Also, what do we do if we change the prop multiple times and send off multiple requests? How do we know if we are updating the state with the correct user since we have no control over which data will return in which order? Luckily we can refactor our code to handle both of these circumstances.

const UserCard = ({ userName }) =>{  
  const [fetchState, setFetchState] = useState({ loading:true })

  const {user, error, loading} = fetchState  

  useEffect(()=>{   
    let shouldSet = true

    setFetchState({ loading: true })  

    getUserData(userName)  
     .then(user => ({ user }))  
     .catch(error => ({ error }))  
     .then(state=>{  
      if (shouldSet) setFetchState({...state, loading:false})  
     })

    return () => {  
      shouldSet = false  
    }  

  },[userName])

  if(error){  
   return (/* error state */)  
  }

  if(loading){  
   return (/* loading state */)  
  }

  return (/* render card here */)   

}

In this refactoring, we are merging all three states into a single state object. This doesn’t just make things more convenient for us later on, but it also makes sense. Any time we are calling multiple setState functions, chances are we should be grouping those together. These states don’t work in isolation but are part of one state and should be updated together.

Next in our useEffect, we are initializing a shouldSet variable to true. Then we instead of setting the state in our .then or .catch we are returning a partial state with either the user or the error. In our final .then we then verify if the shouldSet variable is still true. If it is, we update the state with our partial state and set loading to false.

This makes this work because we are now returning a cleanup function that will change the value of shouldUpdate to false. This will be set to false if the component unmounts or if the userName changes and the effect is rerun. Either way, we won't update the wrong data or update at all if we don’t want to.

You probably want to make a custom hook

Once again, all this logic is starting to make our card cluttered. Also, the UserCard component doesn’t care how we get the states we do, only with what the states are. So it makes sense to refactor this out into a custom hook:

function useCardState(userName){  
  const [fetchState, setFetchState] = useState({ loading:true })

  useEffect(()=>{   
    let shouldSet = true

    setFetchState({ loading: true })  

    getUserData(userName)  
     .then(user => ({ user }))  
     .catch(error => ({ error }))  
     .then(state=>{  
      if (shouldSet) setFetchState({...state, loading:false})  
     })

    return () => {  
      shouldSet = false  
    }   
  }, [userName])

 return fetchState  
}

We have moved all that logic state into a single hook that takes a userName and returns a the fetchState. Now we can use that in our component like this:

const UserCard = ({ userName }) => {

  const {user, error, loading} = useCardState(userName)

  if(error){  
    return (/* error state */)  
  }

  if(loading){  
    return (/* loading state */)  
  }

  return (/* render card here */)   

}

Now the UserCard is easier to reason about again, and we can compartmentalize how we fetch that data and what to do while we fetched our data. It’s important to point out that this hook doesn’t need to be in another file and or made “reusable” at this point. As you go, if you find a common pattern that solves a problem, then go ahead and abstract it generally.

These are the basics of how to do data fetching in React and some good strategies to solve common problems associated with it. Hopefully, this helps fill the gap in your React apps.

JavaScript is an interesting language. It doesn't fit nicely in any one Paradigm. JavaScript does have characteristics of Object-Oriented languages, but it also has attributes of Functional programming languages and doesn't strictly follow either style perfectly.

Recently I was looking at some primary computer science material and was reading about data structures, specifically, the "Stack" data structure. I noticed that all the examples tend to be object-oriented, and I wondered why other language paradigms were not shown.

That was when I decided to think about what a Stack would look like using other programming paradigms. So that is what we will try to do in this post.

(To keep the code universally readable to all readers here, I am only using JavaScript and not Typescript)

First, let's look at how I would implement a Stack using pure OO.

class Stack {
  #head;
  push(value) {
    const node = {
      value,
      next: this.#head,
    };
    this.#head = node;
  }
  peak() {
    return this.#head?.value;
  }
  pop() {
    const safeNode = this.#head ?? {};
    const poppedValue = safeNode.value;
    this.#head = safeNode.next;
    return poppedValue;
  }
  [Symbol.iterator] = function* () {
    let safeNode = this.#head ?? {};
    while (safeNode.value) {
      yield safeNode.value;
      safeNode = safeNode.next ?? {};
    }
  };
}

const stack = new Stack();
stack.push(1);
stack.push(2);
stack.peak(); // 2
stack.pop(); // 2
stack.peak(); // 1
stack.push(3);
stack.push(4);
stack.push(2);
stack.push(2);
console.log([...stack]); // [ 2, 2, 4, 3, 1 ]In the above code, we are defining a Stack class that has a private property called #head and three methods called push , pop , and peak that allows you to add an item to the stack, take an item off, and look at the top item on the stack.

Our Stack is implemented using a linked list. If you are unfamiliar with linked lists, I recommend checking out the basecs article on linked lists but summarizing: A linked list is a list of objects called nodes. Each node has two properties: a value and a reference to the next node. To traverse a linked list, you start at the first node, called the head, and keep going to the next node until you run out of nodes.

Our Stack keeps track of the head node in the private #head property. When we call peak it returns the value at the head node. When we call push, it will create a new node with the value provided, assign the node at the #head property to next and assign that new node to the#head property. Finally, when we call pop, we pull the value off the#head property, and then assign the value of next to the#head property.

We are also making our Stack iterable by assigning a generator function to the[Symbol.iterator] property. You can learn more about generator functions in my blog post on them, but simply put, this allows JavaScript to iterate over the items in the stack, and we can do things like spreading them into an array or using them in a for...of loop.

To use the stack, we call new Stack() and assign that to a variable. From there, we can do all the fun things to a stack you can. This is probably the most common way you will see a Stack implemented.

The first step to making this more functional is to stop mutating our Stack every time we call either the push or pop method. So let's make a new version called ImmutableStack:

class ImmutableStack {
  #head;

  constructor(node) {
    this.#head = node;
  }

  push(value) {
    const node = {
      value,
      next: this.#head,
    };

    return new ImmutableStack(node);
  }

  peak() {
    return this.#head?.value;
  }

  pop() {
    const safeNode = this.#head ?? {};

    return new ImmutableStack(safeNode.next);
  }

  [Symbol.iterator] = function* () {
    let safeNode = this.#head ?? {};
    while (safeNode.value) {
      yield safeNode.value;
      safeNode = safeNode.next ?? {};
    }
  };
}

let stack = new ImmutableStack();

stack = stack.push(1);
stack = stack.push(2);
stack.peak(); // 2
stack = stack.pop();
stack.peak(); // 1

stack = stack.push(3);
stack = stack.push(4);
stack = stack.push(2);
stack = stack.push(2);

console.log([...stack]); // [ 2, 2, 4, 3, 1 ]

Let's talk about what we changed. We still have a private #head property. Also, our peak and iterator or also still the same. What we changed was that we added a constructor to our class. The constructor allows us to initialize values in our Stack when we call new Stack() in our code. Our constructor lets us optionally pass in a node and assign it to the#head property. This will allow us to initialize our Stack with an existing linked list if we want.

In our push method, we still take in a value, assign it to a new node, and assign the value at the #head property to the next property of that new node. However, instead of changing the value of the #head property, we are returning a new Stack initialized with the new node. The same thing happens in our pop method. We are returning a new Stack initialized with the next node of our stack.

I think it is essential to stop and reiterate why this is helpful. If two parts of our code were looking at that same Stack and one part called push or pop on it. The other part of our code would not know that the value was changed on it. This can lead to unpredictable behavior. Making our Stack immutable ensures that we can write our code and be confident that some other part of our code won't change its values underneath us.

The next evolution into a more functional style is to move away from creating classes at all and instead define methods that take inputs and return values:

const stackUtils = {
  push(head, value) {
    const node = {
      value,
      next: head,
    };

    return node;
  },

  peak(head) {
    return head?.value;
  },

  pop(head) {
    const safeNode = head ?? {};

    return safeNode.next;
  },

  getIterator(head) {
    return (function* () {
      let safeNode = head ?? {};
      while (safeNode.value) {
        yield safeNode.value;
        safeNode = safeNode.next ?? {};
      }
    })();
  },
};

let stack;

stack = stackUtils.push(stack, 1);
stack = stackUtils.push(stack, 2);
stackUtils.peak(stack); // 2
stack = stackUtils.pop(stack);
stackUtils.peak(stack); // 1

stack = stackUtils.push(stack, 3);
stack = stackUtils.push(stack, 4);
stack = stackUtils.push(stack, 2);
stack = stackUtils.push(stack, 2);

console.log([...stackUtils.getIterator(stack)]); // [ 2,2,4,3,1 ]

In the above code, instead of creating a class, we define an object with utility methods that know how to peak, push, and pop values on a linked list. Since our methods no longer have access to a head property, that value must be passed in as an argument to our methods. For that same reason, we also have created a function getIterator that will generate an iterator for us to use in those circumstances.

Other than that, our code works pretty much the same way as our ImmutableStack. The only difference is that we must pass the stack variable into every method call.

The above example already follows a functional style, but we can go to one more level of inception. So let's show you that code first:

//stackUtils.js

export function peak(head) {
  return head?.value;
}

export function pop(head) {
  const safeNode = head ?? {};

  return safeNode.next;
}

export function push(head) {
  return (value) => {
    const node = {
      value,
      next: head,
    };
    return node;
  };
}

export function getIterator(head) {
  return (function* () {
    let safeNode = head ?? {};
    while (safeNode.value) {
      yield safeNode.value;
      safeNode = safeNode.next ?? {};
    }
  })();
}

// index.js

import { push, pop, peak, getIterator } from "./stackUtils.js";

let stack;

stack = push(stack)(1);
stack = push(stack)(2);
peak(stack); // 2
stack = pop(stack);
peak(stack); // 1

stack = push(stack)(3);
stack = push(stack)(4);
stack = push(stack)(2);
let stackPusher = push(stack);

stack = stackPusher(2);

console.log([...getIterator(stack)]); // [ 2, 2, 4, 3, 1 ]

First, it is more common in FP languages to group related functions in a module, so that was the first thing we did. We move all the methods into simple functions that we export from thestackUtils.js file.

Generally speaking, all the functions work the same way except for the push function. A common functional programming pattern is only one parameter per function. If you need more than one argument, you use a pattern called "currying." When you curry functions, your function will return a new function that requires the next argument. You keep doing this until you no longer need any arguments.

In our push function. We take an argument called head and return a new function that takes an argument called value. When we call that second function, it will still have access to that head value and can complete the code we need to run.

One of the things this gives us is the ability to do "partial application." On one of the lines near the end, we create a new function stackPusher, that will take a value and push it onto a new stack.

This gives us two things we can do. We may know which stack we want to push onto in one part of our code, but we don't yet know the value. Instead of trying to keep track of the stack in some global store, we can pass around a function that already knows which stack to use and needs to have a value passed in:

const stackPusher = push(stack)

/* later in our code */

const newStack = stackPusher(5)

This can be helpful if we want to create multiple stacks with the same tail but with different heads. We can create a function from the push function that we can use to generate multiple lists with the same tail using different values:

const stackPusher = push(stack)

const stack1 = stackPusher(5)  
const stack2 = stackPusher(2)  
const stack3 = stackPusher(3)  
const stack4 = stackPusher(8)  
const stack5 = stackPusher(12)

So there are four styles of code that you can use to do the same thing. One is a typical OO style, and the last is a distinctive FP style with all the variations in between. I recommend trying all these styles out and seeing which makes the most sense.

Abstracting code is a common thing we do in programming. It is also very common for those abstractions to evolve as the requirements change. Recently I had to opportunity to rapidly evolve a React hook from one form to another in the same day. Now that I have finished it, I thought I would share that evolution with you.

The first requirement was that I needed a generic way to poll data in a React component. If you are not familiar with the term, polling means checking data at a regular interval. This first version looked like this:

import { useRef, useEffect, useLayoutEffect } from "react";

export function usePolling(callBack, intervalTime = 10_000) {
  const callBackRef = useRef(callBack);

  useLayoutEffect(() => {
    callBackRef.current = callBack;
  });

  useEffect(() => {
    const interval = setInterval(() => callBackRef.current(), intervalTime);

    return () => {
      clearInterval(interval);
    };
  }, [callBackRef, intervalTime]);
}

In the above hook, we take a callback and an optional interval time. This callback will be called at a regular interval determined by the interval time provided in the second parameter, set to 10,000 by default.

The first thing that we are doing is using the useRef hook to create a callBackRef and then we are using the useLayoutEffect to keep the ref current with any changes to the callback. Kent C Dodds well documents this pattern, but to summarize, This pattern allows the callback to stay up to date without causing the useEffect to have to rerun or requiring the user of the hook to wrap the callback in a useCallback hook.

In the second part of the hook, we are using a useEffect hook to start our interval, and then we clean up the hook in the clean-up function returned from the useEffect.

This hook works great, but then I got a new requirement that it needs only to poll when the tab is visible; this would ensure that we are not wasting resources polling data when the user isn't actively using the tab.

Luckily there is an easy way to do this. First of all, the document object has a visibilityState that will let you know if it is visible or hidden. There is also an event listener that we can tap into called visibilitychange that we can use to react to the visibility state changing. Both of these are well documented at MDN.

So let's make a tweek to our hook:

import { useRef, useEffect, useLayoutEffect } from "react";

export function usePollWhenVisible(callBack, intervalTime = 10_000) {
  const callBackRef = useRef(callBack);

  useLayoutEffect(() => {
    callBackRef.current = callBack;
  });

  useEffect(() => {
    let interval;

    if (document.visibilityState === "visible") {
      interval = setInterval(() => callBackRef.current(), intervalTime);
    }

    const handleVisibilityChange = () => {
      clearInterval(interval);
      if (document.visibilityState === "visible") {
        interval = setInterval(() => callBackRef.current(), intervalTime);
      }
    };

    document.addEventListener("visibilitychange", handleVisibilityChange);

    return () => {
      clearInterval(interval);
      document.removeEventListener("visibilitychange", handleVisibilityChange);
    };
  }, [callBackRef, intervalTime]);
}

In the above code, we have changed the internals of our useEffect hook. First of all, we start by declaring the interval variable without defining it, and we declare it using a let. The reason we are doing this will be more apparent why we are doing as we go.

The next thing we are doing is checking if our current visibility state is visible and if it is, we start our interval just as before. This will ensure that we don't begin our interval if the page is no longer visible when the component mounts.

Next, we are defining our event listener function: handleVisibilityChange. This function will be called whenever the visibility state changes. In this function, the first thing we are doing is clearing the interval. This is safe because if the value passed in is not a valid interval, the function will ignore it. After we earn the interval we are doing the same visibility check as above and conditionally starting the interval if the visibility state is visible.

Finally, we add our event listener function to the visibilitychange event.

In our clean-up function, we do two things now. First, we clear the interval to ensure that we don't have a memory leak, but secondly, we also remove our event listener so it won't run.

Our hook is working fantastically now, but then a new requirement came down from the requirements gods. This hook will be used in multiple components, but we need them all to be on the same interval cycle. In other words, we need all our hooks to be synchronized.

To do this, I made this last final set of changes:

import { useEffect } from "react";

const INTERVAL_TIME = 10_000;

let callbacks = [];

let interval;

let handleVisibilityChange;

function init() {
  if (handleVisibilityChange) return;

  interval = setInterval(
    () => callbacks.forEach((fn) => void fn()),
    INTERVAL_TIME
  );

  handleVisibilityChange = () => {
    clearInterval(interval);
    if (document.visibilityState === "visible") {
      interval = setInterval(
        () => callbacks.forEach((fn) => void fn()),
        INTERVAL_TIME
      );
    }
  };

  document.addEventListener("visibilitychange", handleVisibilityChange);
}

function cleanUp() {
  if (callbacks.length > 0) return;

  if (handleVisibilityChange) {
    document.removeEventListener("visibilitychange", handleVisibilityChange);
  }

  handleVisibilityChange = undefined;
  clearInterval(interval);
}

export function usePollWhenVisible(callback) {
  useEffect(() => {
    init();

    callbacks = callbacks.concat(callback);

    return () => {
      callbacks = callbacks.filter((fn) => fn !== callback);

      cleanUp();
    };
  }, [callback]);
}

Let's break all this down, part by part.

const INTERVAL_TIME = 10_000;
let callbacks = [];
let interval;
let handleVisibilityChange;

First, we lifted the interval and handleVisibilityChange functions in the module and out of the hook itself. We have also declared two new variables: callbacks and INTERVAL_TIME.

The callbacks variable is initialized with an empty array. This is where we will maintain our list of callbacks to run each interval cycle. Since we now need all the callbacks to be on the same interval cycle, we are now declaring a constant INTERVAL_TIME that we can use universally in our module.

The next thing we do is declare a init function:

function init() {
  if (handleVisibilityChange) return;
  interval = setInterval(
    () => callbacks.forEach((fn) => void fn()),
    INTERVAL_TIME
  );

  handleVisibilityChange = () => {
    clearInterval(interval);
    if (document.visibilityState === "visible") {
      interval = setInterval(
        () => callbacks.forEach((fn) => void fn()),
        INTERVAL_TIME
      );
    }
  };

  document.addEventListener("visibilitychange", handleVisibilityChange);
}

This does a few things. First, it checks if the handleVisibilityChange function is truthy. If it is, we are returning early and not running the rest of the function. This ensures that we only initialize once. The rest of the function, we have already seen. We are starting the interval, declaring our event listener function, and registering it with the visibilitychange event listener.

There is one slight change to the interval function. Instead of calling a single function, we cycle through all the callbacks in the callback array and run those functions.

The next thing that we do is declare a cleanup function:

function cleanUp() {
  if (callbacks.length > 0) return;

  if (handleVisibilityChange) {
    document.removeEventListener("visibilitychange", handleVisibilityChange);
  }

  handleVisibilityChange = undefined;
  clearInterval(interval);
}

This is doing the opposite of our init function. First, it checks if there are callbacks. If there are, it will return early and not perform the cleanup if there are still registered callbacks. Then after that, it removes the event listener, sets the handleVisibilityChange back to undefined, and clears the interval. We set the handleVisibilityChange back to undefined so that if the component remounts, the init function will rerun.

Finally, we declare our hook:

export function usePollWhenVisible(callback) {
  useEffect(() => {
    init();
    callbacks = callbacks.concat(callback);

    return () => {
      callbacks = callbacks.filter((fn) => fn !== callback);
      cleanUp();
    };
  }, [callback]);
}

Now our hook takes a callback, runs init And adds our callback to the callback array. When it cleans up, it removes itself from the array and calls the cleanUp function.

We no longer need to use the callback ref since we no longer care if the effect is rerun when the callback changes. The init and cleanup already have the guards in place not to run needlessly, and the hook itself is simply adding and removing the callback from the callback array.

That's the final version, or at least final as of right now. It's fun to see how a function can change as the requirements do.

My last post on modernizing splat and unsplat were so much fun I thought I would do it again with the following code example in the book, Functional JavaScript, that I decided to do it again. This time we are going to go over the parseAge function example.

(Reminder, I still would highly encourage you to get the book, so I won't be going over content in the book, except to explain the example)

In the book, we are presented with this example:

function fail(thing) {
  throw new Error(thing);
}

function warn(thing) {
  console.log(["WARNING:", thing].join(" "));
}

function note(thing) {
  console.log(["NOTE:", thing].join(" "));
}

function parseAge(age) {
  if (!_.isString(age)) fail("Expecting a string");
  var a;

  note("Attempting to parse an age");
  a = parseInt(age, 10);

  if (_.isNaN(a)) {
    warn(["Could not parse age:", age].join(" "));
    a = 0;
  }

  return a;
}

In the above code, we have a few utility functions: fail, warn, and note. The functions are pretty self-explanatory. The fail function throws an Error of whatever string is passed in and the warn and notelogs a string prefixed with “WARNING:” or “NOTE:” respectively.

The parseAge function then uses those functions while it attempts to parse the age of a string passed in. If a value other than a string is passed in, it will fail, and if the string fails to parse a number it will warn that It couldn’t parse age and then return 0 otherwise, it returns the parsed age value.

The first low-hanging fruit we can update is that we are using console.log for everything. Instead, we can utilize console.warn and console.info to give a bit more meaning to our console logs:

function warn(thing) {
  console.warn(["WARNING:", thing].join(" "));
}

function note(thing) {
  console.info(["NOTE:", thing].join(" "));
}

The other quick update is that we can update our custom string to use template literals instead of joining arrays:

function warn(thing) {
  console.warn(`WARNING: ${thing}`);
}

function note(thing) {
  console.info(`NOTE: ${thing}`);
}

// from the parseAge function body
if (_.isNaN(a)) {
  warn(`Could not parse age: ${age}`);
  a = 0;
}

The next thing we have is a reliance on underscore.js utility functions. One of those is the _.isNaN function. This was important at the time of the book’s writing because the global isNaN function in JavaScript was unreliable and did not work as expected. Luckily, an alternative method was added in ES2015 to the Number object that does the same thing. So let’s update our code:

if (Number.isNaN(a)) {
  warn(`Could not parse age: ${age}`);
  a = 0;
}

The utility is the _.isString function. This function works well, but sometimes it doesn’t make sense to bring in a whole utility library just for a small part. Plus this is a great opportunity to understand what _.isString is doing under the hood. If you look at the code in github we can see that it is simply doing something like this:

if (toString.call(value) !== "[object String]") {
  fail("Expecting a string");
}

I’ll leave it to you to look into how that works and why this way is used. But if we combine all these things we now have a more modern version:

function fail(thing) {
  throw new Error(thing);
}

function warn(thing) {
  console.warn(`WARNING: ${thing}`);
}

function note(thing) {
  console.info(`NOTE: ${thing}`);
}

function assertIsString(value) {
  if (toString.call(value) !== "[object String]") fail("Expecting a string");
}

function parseAge(age) {
  assertIsString(age);

  note("Attempting to parse an age");
  const a = parseInt(age, 10);

  if (Number.isNaN(a)) {
    warn(`Could not parse age: ${age}`);
    return 0;
  }

  return a;
}

Besides what we have already gone over, there are two other changes in the above code. One is simply changing out var to const and pre-emptively returning 0 if the the parsed value is not a number.

The other change is more stylistic choice, but one I personally like. I refactored out the string check into it’s own function called assertIsString. This is primarily a stylistic choice, but it is also helpful when as we start converting it to TypesScript. Speaking of…

Most of the functions are simply typed:

function fail(thing: string) {
  throw new Error(thing);
}

function warn(thing: string) {
  console.warn(`WARNING: ${thing}`);
}

function note(thing: string) {
  console.info(`NOTE: ${thing}`);
}

function assertIsString(value: unknown) {
  if (toString.call(value) !== "[object String]") {
    fail("Expecting a string");
  }
}

fail, warn, and note all take a string, so we added that type to the parameters of each function. assertIsString takes an unknown value and checks if it is a string. So it makes sense for it’s parameter to be of type unknown.

As for the parseAge function, it would be safe to assume we should type the parameter as a string, and honestly that would probably be the right choice in most apps. That said, the spirit of how the function is written implies that the value is unknown so let’s use the unknown type.

The problem is that, despite the fact that we are verifying the type of the age parameter is a string in our assertIsString function. TypeScript still will see that the value is unknown and complain when we try to call parseInt with an unknown value.

We could wrap the remaining code in a if statement that check the type of age, but honestly why are we doing another type check just to satisfy TypeScript (plus TypeScript will still complain on not writing code for all potential branches, so we didn’t really solve the problem).

What we need is to somehow let TypeScript know that once we get past the assertIsString function that the age parameter can safely be assumed to be a string at that point. Luckily, TypeScript has a way to do just that. Let’s make one small change to the type of our assertIsString function:

function assertIsString(value:unknown):asserts value is string {
 if(toString.call(value) !== '[object String]'){
 fail("Expecting a string");
 }
}

In the above code, we added :asserts value is string where we would normally define our return type. What this does is instead of defining a return type from the function, we are telling TypeScript that what ever was passed into the function can be safely be used as a string.

We can do this, because if the value is not a string, we throw an error and the code doesn’t proceed on. If, however, the function runs without errors, we can be confident that it is in fact a string. It is important to note, that TypeScript is taking our word for it. TypeScript isn’t actually looking at our code to see if it works (it would be impossible for it to do so). So you do need to be confident that it is implemented correctly.

Let’s look at the full TypeScript version:

function fail(thing:string){
  throw new Error(thing);
}

function warn(thing:string){
  console.warn(`WARNING: ${thing}`);
}

function note(thing:string){
  console.info = console.log
  console.info(`NOTE: ${thing}`);
}

function assertIsString(value:unknown):asserts value is string{
  if(toString.call(value) !== '[object String]') fail("Expecting a string");
}

function parseAge(age:unknown){
  assertIsString(age)

  note("Attempting to parse an age");
  const a = parseInt(age, 10)

  if(Number.isNaN(a)){
    warn(`Could not parse age: ${age}`);
    return 0
  }

  return a
}

So there you have it. A fully modernized code example, complete with TypeScript. Let me know what you think and I look forward to sharing more examples with you soon.

One of my favorite books for JavaScript is “Functional JavaScript” by Michael Fogus. Even though it was written in JavaScript pre-ES2015 and leans heavily on underscore.js, a groundbreaking functional utility library that has since lost much of its market share, the core concepts taught in the book stand the test of time and show you how to think like a functional JavaScript Programmer.

That said, the examples are out of date. More and more new developers will have a more challenging time reading the code examples or even knowing how to apply the examples in a modern codebase, especially one written in TypeScript.

So I thought it would be a great exercise, to slowly update the examples here so that they show more modern styles of JavaScript while hopefully extending the life of this great resource that is available to the community.

(In this example, I will only be going over minimum amount of the content from the book as possible. I still highly recommend the book,, and I want to encourage you to buy it and use it as a resource.)

So the first example shown is splat and unsplat, two contrived utility functions:

function splat(fun) {
  return function (array) {
    return fun.apply(null, array);
  };
}

var addArrayElements = splat(function (x, y) {
  return x + y;
});

addArrayElements([1, 2]);
//=> 3

function unsplat(fun) {
  return function () {
    return fun.call(null, _.toArray(arguments));
  };
}

var joinElements = unsplat(function (array) {
  return array.join(" ");
});

joinElements("-", "$", "/", "!", ":");
//=> '- $ / ! :'

To summarize the above, we are creating two utility functions: splat and unsplat. Both take a function as an argument and return a new function, a pattern known as higher-order functions.

splat takes a function and returns a new function that accepts an array of values. Each value will be applied as an argument to the provided function.

unsplat, takes an inverse approach to its splat counterpart. It takes a function that accepts an array as its argument and returns a function that will convert all the arguments passed into an array and apply that array to the provided function.

(Once again, for more details, please refer to the book.)

The first thing we can do is update the implementation of how splat and unsplat work under the hood. splat takes advantage of the[apply](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/apply) method provided that is part of all functions in JavaScript. Simply put, apply takes a context (which isn’t essential in this use case, hence why nullis used) and an array of values. Each value in the array is applied as an argument to the function.

unsplat is similar, but it is implemented using the [call](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/call) method provided on all JavaScript functions. Like apply, it takes a context, but instead of an array of values, all the remaining arguments supplied to the call method will be passed as arguments to the function.

Using call and apply was great when that was the only thing you could do, but we now have access to the spread and rest operators in modern JavaScript. The spread operator will let you spread the values of an array out as arguments to any function. This means we can update our splat function to look like this:

function splat(fun) {
  return function (array) {
    return fun(...array);
  };
}

The unsplat function can also be updated similarly. In the old example we were using the [arguments](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/arguments) object, which is an object that looks like an array, but isn’t one. So it has to be converted to an array (the book’s example uses the underscore utility function to do that). Now that we have the rest operator we can bundle all the arguments into a single array, without needing to convert it, like this:

function unsplat(fun) {
  return function (...args) {
    return fun(args);
  };
}

This is more readable and easy to understand, but we also don’t have to worry about the context, which was not necessary for what we were doing.

This is great already, but we are still only using one form of writing our functions. With ES2015 we also have an arrow function syntax that gives us more flexibility on how we write our functions. I’ve given my opinions on JavaScript in an earlier post, but I never shared my opinions on function declarations.

I simply have two rules, named functions should prefer the traditional function declaration syntax and anonymous functions should prefer arrow function syntax. Also one should prefer the implicit return syntax if the return value is simple and easy to fit on one line. With that, we can update the entire file to look like this:

function splat(fun) {
  return (array) => fun(...array);
}

const addArrayElements = splat((x, y) => x + y);

addArrayElements([1, 2]);
//=> 3

function unsplat(fun) {
  return (...args) => fun(args);
}

const joinElements = unsplat((array) => array.join(" "));

joinElements("-", "$", "/", "!", ":");
//=> '- $ / ! :'

Finally, let’s add some type safety to our new functions. I’ve already written a post about Dynamic typing using Generics, which luckily translates very well to these two functions. So let’s update them now to use Typescript:

function splat<T extends Array<unknown>, R = unknown>(
  fun: (...arr: T) => R
): (arr: T) => R {
  return (array) => fun(...array);
}

const addArrayElements = splat((x: number, y: number) => x + y);

addArrayElements([1, 2]);
//=> 3

addArrayElements([1, 2, 3]); //TS Error
addArrayElements([1]); //TS Error
addArrayElements(["1", "2"]); //TS Error

function unsplat<T extends Array<unknown>, R = unknown>(
  fun: (arr: T) => R
): (...arr: T) => R {
  return (...args) => fun(args);
}

const joinElements = unsplat((array) => array.join(" "));

joinElements("-", "$", "/", "!", ":");
//=> '- $ / ! :'

There we have it. We have successfully updated the first code example to use a modern form of functional JavaScript. I will be sharing some more examples as I re-read the book from the beginning, but this should help you be able to look at code examples from older books and update them to modern JavaScript.

When trying to break in as a web developer, one of the things that helped me get started was the local meetup. Once a month, I could meet other like-minded individuals of various abilities, and we would all learn together.

Fast forward to 2021, and things have changed. More and more things have moved to online communities, and with the pandemic accelerating the adoption of virtual solutions to do that thing.

Juan Cruz Martinez has made a list of Developer communities that are worth checking out. But I thought I would go into what I feel are good things to look for in a developer community. And to help me, I plan on highlighting things from my favorite developer community: The Lunch.dev Discord Server.

Sincerely Welcoming

One of the great things about the Lunch.dev Discord Server is that everyone is sincerely welcoming. There isn’t an individual that joins that isn’t welcomed by name in the main general chat. Each welcome is sincere and brings with it an encouragement to start participating if so desired.

I have also seen Michael Chan, the creator of the server, personally reach out and take the time to get to know new individuals and try to understand their goals.

A good community will find a way to make you sincerely feel welcomed to be a part of it.

Resource of Knowledge and Growth

The Lunch.dev server was originally called the React Podcast Discord Server. Despite its name coming from the React Podcast, the community is not necessarily focused on React. It focuses more on creating an environment where people can safely ask for help from others without fear of toxic replies.

It also encourages others to share things they have learned about any subject, including frameworks other than React. The server regularly promotes events where community members can learn from each other. Events include book clubs, lightning talks, round tables, and lunch and learn.

A good community will provide and encourage you to grow as a developer and a person.

Encourages Healthy Self-Promotion

The previous section implied it, but I think it’s important enough to call out right now. Sharing information often includes sharing content that you have created yourself.

On the Lunch.dev server, people regularly share blog posts, twitch streams, Twitter threads, and podcasts that they participate in. Not only is this self-promotion not looked down on, it is also encouraged. There are dedicated channels to do just that, showcase what you have been working on.

A good community will acknowledge that not all self-promotion is spam and will encourage users to share, in a healthy way, what they are doing that makes them awesome.

One can look for many things in a community, but these three I feel are important when looking for and evaluating any community that you are looking to join or create yourself.

Looking back at how my career has shaped, I can point to one moment where I feel it took off. The moment I started writing blog posts. Not that my career had become stagnant, but it rocketed up quickly the moment I started putting thoughts on virtual paper and presented them for the world.

In hind sight, I feel there are a few reasons why that happened. And it’s why I think every developer should look at creating content, no matter if it is writing in a blog, streaming on twitch, making YouTube videos, or all of the above.

Content Becomes Your Portfolio

Trying to break into this career, I spent all my free time building hobby projects and such to prove I could start contributing right away. It was a great representation of my work during that snap shot in time. Once I started working “real” developer jobs, that portfolio was no longer representative of my skills and I needed to stop showing them to potential employers.

The problem was that, the code I was writing wasn’t able to be shown to new employers. It was all behind private repos. As you move up, it is just as important to show you understand higher level concepts and not just technical syntax.

That is where content creation can easily step in and become your new portfolio. Code examples and the explanations for them more accurately show your programming abilities than random projects on Github will. It shows that not only can you do something, you can communicate why.

Content Helps You Learn

Sometimes I wrote content, because I learned something cool and wanted to share it. Just as often, I wrote content because I wanted a reason to learn something.

For example, early on in my blog writing career, I decided I really wanted to understand generator functions and why they existed in the first place. I decided I wrote a blog post title called “How To Code The “Fizz Buzz” Challenge Using JavaScript Generators”. I hadn’t even figured out what the content would be at that point, but it gave me a reason to dive deeper and is still one of my favorite blog posts I have written.

I also learned a lot from people who commented on my blog posts. Yes there is a stupid Troll sometimes, and even others who have legit comments, but have zero ability to criticize nicely. Overall, comments have been a source of knowledge to me and helped refine my knowledge even further.

How To Get Started

Carla Urrea Stabile wrote a great post about it over at her blog. The biggest thing is just start. I was thinking about streaming on twitch for a while now, but it wasn’t until my friend, Ben Meyers who streams over at SomeAnticsDev, the biggest thing you need to do to get started is just start. And then when you are done, do it again. And then do it again. You get better as you go, the hardest part is get started.

Naming things in programming is very difficult. In a previous post, I talked about my opinions when writing JavaScript. I recently read about what not to do when naming variables by John Au-Yeung and I very much agreed with many of the points.

It made me realize that my previous post lacked some essential naming patterns that I like to adopt. Yes, naming things can be hard, but it can make it much easier to name things in our code if you have a naming scheme that you follow. So I thought I would share my personal rules here in this post.

Functions and Method Names Should be Verbs

Functions and methods are actions that are being performed. So it goes to reason that they should be names that describe that action. For example:

function checkOnlineStatus() {}

function getUserDetails(userId) {}

function removeDuplicates(array) {}

Naming functions this way clearly communicate what each of the functions does and even that they are functions in the first place. As things get passed around, it can get easy to lose track of what things are. Using an action verb helps communicate that this is something that needs to be called.

The one exception to this rule is old school JavaScript constructors, which were just functions called using the new operator, and React Components. In both cases, the functions are actually being used to create Objects, which leads me to my next rule.

Objects and Primitives Should be Nouns

Variables that are assigned objects or primitive values represent something that has substance. It makes sense that we should use nouns to name these items of substance. For example:

const userAge = 12;

const admin = {
  name: "Doe, John",
};

const hostCity = "Salt Lake City, Ut";

It also makes it clear when you return values from functions that they should be named nouns that correspond with the function:

const onlineStatus = checkOnlineStatus();

const currentUser = getUser(userId);

Arrays Should be Plural Nouns

Arrays are technically Objects in JavaScript, but they are unique in that they represent a list of things. So it makes sense that arrays should be a pluralized form of that noun.

const friends = [
  /*...*/
];

const names = [
  /*...*/
];

const indexes = [
  /*...*/
];

It also makes the parameter used in the callbacks of array methods easier to name as well. Simply use the singular form:

const friendNames = friends.map((friend) => friend.name);

Objects Used as Key/Value Pairs Should Use The Suffix Map

JavaScript objects are pretty versatile. Besides representing things like users, they are also often used to map pairs of keys and values. In those cases, the variable name should also make sure that it is clear:

const spacingMap = {
  xs: "0.125rem",
  sm: "0.25rem",
  md: "0.5rem",
  lg: "1rem",
  xl: "2rem",
  xxl: "4rem",
};

Now it’s clear that each key will be mapped to a spacing value that I will need.

Nullable Values Should be Prefixed With Maybe

If a value could be undefined or null, you want to communicate that in your variable name. This makes it clear that when using that variable, that you need to write defensive guards that handle what happens when the variable is nullish:

const maybeHostCity = findHostCityByState("ND");

It is clear that we are expecting a host city, but it might be null, so we can be sure to guard for that case in our code.

Setting up your own naming scheme will make it much easier to name things in the future, and naming things correctly can make your code easier to read and maintain.