Typed Subatomic Styling: Part 1 — Benefits of TypeScript and CSS

16 March 2019

The benefits of components have been realized with systems such as React and VueJS. Styling these components has a number of approaches, from CSS classes written in SCSS, inline styles, and dynamically generated stylesheets via something like emotion.

Each styling approach has trade-offs in regards to reusability, performance, and developer experience. Also, special considerations often have to be made when doing server-side rendering.

In this post, we’ll explore TypeScript combined with functional CSS. I believe it offers big benefits over the other choices — it’s extremely reusable, fast, and offers a very pleasant developer experience.

Read more…

Smart Reducers with React & Hooks

13 January 2019

Hooks are on their way soon to React, which offer ways to manage component state and lifecycles in function components.

Also coming is the reducer, a pattern from the popular library Redux. While I think Redux can make apps more complicated than they need to be, I think reducers as a primitive offer some interesting approaches, and being built into React, perhaps new patterns too.

A counter

So let’s take a simple example of a counter. A counter is backed by an integer value, which gets stored in the component’s state. This state is managed by a reducer: a pure function taking the previous state and an action of some sort, and based on the action will return a new state.

Convention has actions holding a type property, which for our counter will be one of: “increment”, “decrement”, “reset”. We handle each action type in the switch statement of countReducer().

Three buttons are rendered: +1, -1, and reset. Each button has an onClick handler, which will call dispatch() with the particular action type: increment, decrement, or reset.

import React, { useReducer, useCallback } from "react";
import ReactDOM from "react-dom";

const initialState = { count: 0 };

function countReducer(state, action) {
  switch (action.type) {
    case "reset":
      return initialState;
    case "increment":
      return { count: state.count + 1 };
    case "decrement":
      return { count: state.count - 1 };
    default:
      return state;
  }
}

function App() {
  const [state, dispatch] = useReducer(countReducer, initialState);

  return (
    <div className="App">
      <h1>{state.count}</h1>
      <button onClick={ () => dispatch("decrement") }>-1</button>
      <button onClick={ () => dispatch("increment") }>+1</button>
      <button onClick={ () => dispatch("reset") }>Reset</button>
    </div>
  );
}

By themselves creating these three onClick handler functions has little overhead. However, because every time our component renders we are creating them from scratch and passing new functions to each button’s onClick, React has to remove the old handlers and add the new ones.

It would be better if we didn’t create these handler functions from scratch each time our component renders. If we create them once, and then reuse them, then React wouldn’t have to perform the work of changing the handlers for the buttons.

Can we avoid the creation of three onClick handlers? Yes, we can with custom data attributes. These attributes must be prefixed with data- but everything that follows can be named as we like. We can access these attributes in JavaScript via the DOM’s dataset property.

So, for each button we could set a data-action-type data attribute, and then read that in the click handler. We could also use the useCallback hook to memoize this click handler.

import React, { useReducer, useCallback } from "react";
import ReactDOM from "react-dom";

const initialState = { count: 0 };

function countReducer(state, action) {
  switch (action.type) {
    case "reset":
      return initialState;
    case "increment":
      return { count: state.count + 1 };
    case "decrement":
      return { count: state.count - 1 };
    default:
      return state;
  }
}

function App() {
  const [state, dispatch] = useReducer(countReducer, initialState);
  const onClick = useCallback(
    event => {
      // Find our <button>’s DOM element.
      const buttonEl = event.target;
      // Read the button’s data-action-type attribute.
      // Note the kebab-case becomes camelCase.
      const type = buttonEl.dataset.actionType;
      // Dispatch an action of this button’s type to the reducer.
      dispatch({ type });
    },
    [dispatch]
  );

  // Note each button gets its own `data-action-type`,
  // but shares the same `onClick` prop.
  return (
    <div className="App">
      <h1>{state.count}</h1>
      <button data-action-type="decrement" onClick={onClick}>
        -1
      </button>
      <button data-action-type="increment" onClick={onClick}>
        +1
      </button>
      <button data-action-type="reset" onClick={onClick}>
        Reset
      </button>
    </div>
  );
}

So this should avoid in re-renders the need to remove and add click handlers. Not only are we using a single onClick handler for each button, by using the useCallback hook we ensure the component will creating it only once on the initial render and then reuse it in future renders.

Out of interest, could we go further? Could we reduce what we need to pass to each button and make it nicer to removing the data- from view?

import React, { useReducer, useCallback } from "react";
import ReactDOM from "react-dom";

const initialState = { count: 0 };

function countReducer(state, action) {
  switch (action.type) {
    case "reset":
      return initialState;
    case "increment":
      return { count: state.count + 1 };
    case "decrement":
      return { count: state.count - 1 };
    default:
      return state;
  }
}

function App() {
  const [state, dispatch] = useReducer(countReducer, initialState);
  const onClick = useCallback(
    event => {
      // Find our <button>’s DOM element.
      const buttonEl = event.target;
      // Read the button’s data-action-type attribute.
      // Note the kebab-case becomes camelCase.
      const type = buttonEl.dataset.actionType;
      // Dispatch an action of this button’s type to the reducer.
      dispatch({ type });
    },
    [dispatch]
  );
  // Define a memoized component that dispatches actions to our reducer
  const ActionButton = useCallback(
    ({ actionType, ...rest }) => {
      // Map from the nice `actionType` prop into the
      // data attribute `data-action-type`.
      // Also pass the `onClick` which every button will share.
      return (
        <button {...rest} data-action-type={actionType} onClick={onClick} />
      );
    },
    [onClick]
  );

  return (
    <div className="App">
      <h1>{state.count}</h1>
      <ActionButton actionType="decrement">-1</ActionButton>
      <ActionButton actionType="increment">+1</ActionButton>
      <ActionButton actionType="reset">Reset</ActionButton>
    </div>
  );
}

Now, you might be thinking: this is just a simple counter demo. What about passing a payload when we dispatch our actions?

One approach could be to add another prop to our ActionButton component, something like actionPayload. However, if we were to also pass this as a data attribute, we would have to serialise the value, which would add extra overhead and make our component slower.

So, instead let’s rely on the fact that our component are meant to be pure: given a set of props taken as input, then the same output should be rendered every time.

Another way to say this is everything in our component, from the elements rendered to the code inside the event handlers, is derived from our props.

This mean the desired custom action is also derived from our props: given a set of props, the same payload will be calculated every time. Therefore, we can calculate the payload needed on-demand when we dispatch.

Here I have added two new action creators: “increment.by10” and “decrement.by10”. I am using a dot to denote these custom actions, and to show which actual action type will be dispatched.

import React, { useReducer, useCallback } from "react";
import ReactDOM from "react-dom";

const initialState = { count: 0 };

function countReducer(state, action) {
  const payload = action.payload || {};
  switch (action.type) {
    case "reset":
      return initialState;
    case "increment":
      return { count: state.count + (payload.amount || 1) };
    case "decrement":
      return { count: state.count - (payload.amount || 1) };
    default:
      return state;
  }
}

function App() {
  const [state, dispatch] = useReducer(countReducer, initialState);
  const onClick = useCallback(
    event => {
      const buttonEl = event.target;
      const type = buttonEl.dataset.actionType;
      switch (type) {
        // Our custom action creators
        case "increment.by10":
          dispatch({ type: "increment", payload: { amount: 10 } });
          break;
        case "decrement.by10":
          dispatch({ type: "decrement", payload: { amount: 10 } });
          break;
        // Normal reducer action
        default:
          dispatch({ type });
      }
    },
    [dispatch]
  );
  const ActionButton = useCallback(
    ({ actionType, ...rest }) => {
      return (
        <button {...rest} data-action-type={actionType} onClick={onClick} />
      );
    },
    [onClick]
  );

  return (
    <div className="App">
      <h1>{state.count}</h1>
      <ActionButton actionType="decrement">-1</ActionButton>
      <ActionButton actionType="increment">+1</ActionButton>
      <ActionButton actionType="decrement.by10">-10</ActionButton>
      <ActionButton actionType="increment.by10">+10</ActionButton>
      <ActionButton actionType="reset">Reset</ActionButton>
    </div>
  );
}

The reducer has been changed to accept payloads for the “increment” and “decrement” action. However it still remains a pure function, like reducers should be. It’s also lean: we could add “increment.by50” or “increment.by1000” without needing to change our reducer.

You can see or fork an online demo of the above counter here: https://codesandbox.io/s/jlz8pk6yow

Thanks for reading, and if you have any thoughts reach out on Twitter.

The CSS Spectrum from Semantic Components to Pragmatic Utilities

2 January 2019

A decade or two ago, we usually wrote HTML by hand, whether in templates or as entire pages. Either way, these templates contained raw HTML that formed a structure. They said what was on the page: the semantic meaning behind what presented to the user.

We used ordered or unordered lists, anchors for links, buttons for actions, headings of various priority, and two types of emphasis instead of the predetermined bold and italic elements.

We did this because it made a better experience for our users. They were more accessible, as these semantics could carry over to an audible presentation of the page, or to search engines, or to RSS or read-it-later readers.

But it also made it easier for authors. We had a common language that we could understand and build with. There were various patterns that could be universally understood. You could look at the source code and gleem the intent.

This extended to the styling layer of CSS. Cascading style sheets were separate documents to the pages themselves. Elements on pages would be classed, and in CSS visual rules would be defined for each class. Use the same class on multiple pages, and bam, they would look the same everywhere after having the same rules applied.

Class names could be anything authors desired. They could be single words. They could be multiple words separated by hyphens-like-a-kebab, or allJoinedTogetherWithCapitals. They could have their own little mini hierarchy and system. But, whatever you chose, it didn’t matter. As long as the class names in the HTML and in the CSS matched, they would be applied.

They mattered to authors though. They had to look at them as they made new pages, and evolved the CSS rules. The semantics mattered, and so names that reflected the meaning of the content more than it’s eventual look were desired. A redesign with a new color scheme or rearranged layout could mean throwing all the CSS away if you had names like ‘button-red’ or ‘left-sidebar’. Far better to call them ‘button-danger’ and ‘main-sidebar’, as between redesigns the meaning would stay much the same.

And so we made a rule that CSS class names should not reflect its appearance but its underlying meaning. We broke this rule when we just had to (clearfix anyone?), but doing so was generally regarded as not planning for the future, and, well, just cheating really.

I think in a time of components, we can make some changes. I think we can get rid of many of these semantic CSS classes. Why? Because our components are our semantic layer now.

Remember the structuring of HTML was important for accessibility, but the naming of CSS was really just to make the authors lives easier. Whether a button that looked red to a user had the word ‘red’ in its name or a more considered, meaningful name made no difference to the user. It looked the same, acted the same, and tasted the same (back when UIs looked so good you could lick them).

Components let us organise the building blocks of our pages and UIs into reusables. We can define a DangerButton component, and encapsulated all the styling knowledge inside (whether CSS partials or CSS-in-JS). We can then use this DangerButton in all its glorious meaning again and again, on page after page. When we decide they should no longer be red but bright purple, we have one place to make changes, just like the semantic CSS days.

Our components names and props can convey the full set of meaning, and even better encapsulate not only the styling choices but the amount of HTML too. We don’t need to know the raw elements needed to make a functional link in a navigation bar, we can just use the NavLink component.

So is reusable CSS like we had before encapsulated components dead? I don’t think so.

Utility classes are ultra reusable thin slices of CSS that we assemble to form a complete picture. A DangerButton might have white text on a dark red background, and so we’d use the text-white and bg-red-dark utility classes. We might also sprinkle in text-lg and padding-4 and rounded.

These class names are decidedly not semantic. And they seem to replicate the granularity of CSS rules themselves. Aren’t they just the same as that other villain, inline styles where our CSS is written inside our HTML?

No, because they provide a system. Dark red is defined to one particular shade of crimson and then shared everywhere. The large font size class, text-lg, also can have the exact unit size changed in one exact spot. They might not be semantic, but they don’t spill all their beans.

Plus, they are just plain handy. CSS is fast, caches well, easily made responsive, and works with React or Vue or Elm or Rails. You don’t have to decide which CSS-in-JS library is most in vogue. You don’t even (dare I say) need JS.

Components to utility classes. A spectrum from semantic meaning through to pragmatic efficacy. While it’s not perfect, I think it’s a nice mix of both worlds.

Understanding state

17 December 2018

State is what is known by your app.

In a web app, state refers to local state. It only knows a subset of all information. And that information is from a certain point in time: it might have changed since.

In a JavaScript web app, your user’s web browser talks to an API. The API has its own state, usually stored permanently in a database.

(In a server-side web app like one built with Rails, your application usually talks to the database directly.)

So local state. It’s your web app’s state of the world at a certain time. That world depends on factors, such as which account is signed in, or perhaps whether the user is not signed in, which page they are looking at, and what capabilities their account has.

Loading state

For your web app to display information, it has to first load it.

So your web app loads this initial information, and this becomes its state of the world. If five minutes later, the latest information is desired, it must load it again.

Making things more complicated is the fact that there is not just one set of information.

Take Instagram as an example. There is the feed of photos. As you scroll through the feed, more photos are loaded. For a good user experience, photos are loaded before you reach them. But still, only a subset of photos are loaded. It would make little sense to load your feed from the top to the very bottom, as it would likely be hundreds of megabytes of information in total, and be a huge strain on Instagram’s servers to collate all that information.

Instagram offers more than just a feed. Your can explore and search for photos. You can take or upload a photo. You can see a list of activity aimed at you, such as recent comments or likes on your posts. You can also look at your own profile, with the photos you have posted.

Depending on which section you look at, and how you interact within that section (scroll, tap to see details, tap to go to someone’s profile), new information will have to be loaded. The app’s state of the world expands. It goes from a small subset of data, to a larger subset of data.

Managing this state, and coordinating the loading of additional or fresher state, is one of the key skills in building web apps.

A step back. A command line app.

Any app that has an interactive user interface has state. Think of PowerPoint and the file that is being viewed, the currently active slide, whether that slide is being edited, viewed with slides listed to the side, or is being presented. All of those variables are state.

A command line app also has state. The less command efficiently reads from a file, only presenting a slice of it that fits in the terminal window. As the user scrolls and down, the app’s state is updated with the offset slice into the file.

A command line app is a useful starting point, because many operate in the same manner as web apps based on React. In React, the application is built by deriving the entire user interface from state. The application developer declares their intent for what should be displayed on screen given a certain state. If the state changes, then that codified intent is used again, but with the updated state. And so on, every user interaction usually affects the state in some way, and the user interface is updated quickly to respond. This pipeline approach is popular with games, where the displayed image is rebuilt again and again many times a second, fast enough to produce fluid motion.

The alternative is to intertwine the state with what is being presented. As new information comes in, it is not a simple change to state. It is a manual change to what’s on screen too.

A pipeline is like to correct a typo in a printed document, making the change in software, throwing the old copy away, and printing a new fresh copy. Fortunately, in an app built totally with software means that nothing is wasted.

An intertwined approach is more akin to correcting a typo by using whiteout and a fine pen. It’s much less wasteful, but takes much more effort and skill than just printing a new copy would be. The same is true for apps.