
The chart above is from
[a famous tweet](https://twitter.com/dan_abramov/status/981712092611989509) by
Dan Abramov in 2018. Dan, as usual, does an amazing job of communicating his
deep technical knowledge in a way that is easy to comprehend.

Since the release of
[Stately's Visual Editor](https://stately.ai/registry/new?source=erikras), I've
been using it more and more at my dayjob at
[Centered](https://centered.app/erik) to construct new, and comprehend existing,
state machines in our codebase. The visual editor is just so _fun_ to use!

The other day, I thought to myself,

> "I wonder if I could test my knowledge of React and state charts, and model
> the React lifecycle methods in a state chart?" 🤔

So I gave it a try!

## React Lifecycle State Chart

<p>
<img
  src="/images/react-lifecycle-state-chart.png"
  alt="React Lifecycle State Chart"
  width={2590}
  height={2084}
/>

<caption>
  Elegant, ain't it?
</caption>
</p>

One thing that immediately jumped out at me was how all the lifecycle methods –
and `render()` itself! – ended up being side effects, or "actions" in XState
parlance. This makes total sense, as they really are _where you put side
effects_!

> Rendering is a side effect!

### The Code

This is the XState machine that the visual editor generated:

```js
import { createMachine } from "xstate";

export default /** @xstate-layout N4IgpgJg5mDOIC5QCUwEMDGAXABAYQHsBbABwIDsxysA6AWQIFdrIBiAVXKKesVDNgBLLIIp8QAD0QBaAIwAGAGw0ALAE4AHPICsigMxrFi+RqMAaEAE8ZAJhsaaAdm0qVsmyb12bamwF8-C1RMXEJSCipaBmYsNgA5MAB3HAAFACcCEngkEAFhUXJxKQRpNxsaeVk9FUc1Xz09DTttC2sS-WUG9wbtbUdXWUcAoPRsfGIySmp6HliIVgBlMFwFrDRY8TyRMRzi2SqaRTVHE3t+tS7HVplFDxofBUUVDQ1ZC5tZYZBgsbDJyJmMTYADECGkMGAcOwSBB1mBNgQhNtCrsZAp5DRZC4zvI9I4DPtriVtC8aGoVDZtLImoZHI4ngFAiByAQIHBxD9QhMItNoiwIDRUOQ2WlIAikQUijJapj8U19iSVLpZCoidI9L0KvJ5EqdQTNEovpzxuEplFZmKcltJaiSio9MpKtVavVGs01S8MV07I4fJoLiojaMuaaAZxuECIOL8jtQHs8WT5fI7KY3eYrLYsU4XColIZFNofP4mca-jysNHkVK7cYKlUanUbA0mpS1XUvXp3DZatVc7JFIy-EA */
createMachine({
  description: "made by @erikras",
  initial: "Mounted",
  states: {
    Mounted: {
      entry: [
        "constructor",
        "getDerivedStateFromProps",
        "render",
        "componentDidMount",
      ],
      initial: "Rendered",
      states: {
        Rendered: {},
      },
      on: {
        Unmount: {
          actions: "componentWillUnmount",
          target: "Unmounted",
        },
        "New Props": {
          actions: ["getDerivedStateFromProps", "render", "componentDidUpdate"],
          cond: "shouldComponentUpdate",
          target: ".Rendered",
        },
        "Set State": {
          actions: ["render", "componentDidUpdate"],
          cond: "shouldComponentUpdate",
          target: ".Rendered",
        },
        "Force Update": {
          actions: ["render", "componentDidUpdate"],
          target: ".Rendered",
        },
      },
    },
    Unmounted: {
      type: "final",
    },
  },
  id: "React Component",
});
```

The crazy comment at the top is how the visual editor encodes the location of
all the boxes and arrows and whatnot, so if you open this exact file in the
editor, the layout will be the same. Clever, huh?

Of course, because
[I tweeted it](https://twitter.com/erikras/status/1539984775523475457), I got
[a clever response/challenge](https://twitter.com/donavon/status/1540112177515970567),
from my friend, Donovan:

> Nice. Now do this one.

with a link to [this chart](https://github.com/donavon/hook-flow) he, his son,
and Dan put together three years ago:

<p>
<img
  src="/images/react-hooks-lifecycle.png"
  alt="React Hooks Lifecycle"
  width={761}
  height={969}
/>

<caption>
  React Hooks Lifecycle
</caption>
</p>

I couldn't turn down such a challenge, now could I?

## React Hooks State Chart

It actually didn't take me long at all to whip up this one. Although React
hooks, as an API, is full of footguns with which to shoot yourself, the actual
mental model of what is happening is simpler than the lifecycle methods.

<p>
<img
  src="/images/react-hooks-lifecycle-state-chart.png"
  alt="React Hooks State Chart"
  width={2226}
  height={1700}
/>

<caption>
  React Hooks State Chart
</caption>
</p>

With this one, I took the additional step of imagining we were actually
implementing it as an XState state machine, where we could have to save the
props, state, and context into the machine's context (that's the XState term for
the internal storage of the machine).

### The Code

```js
import { assign, createMachine } from "xstate";

export default /** @xstate-layout N4IgpgJg5mDOIC5QCUwEMDGAXABAYQHsBbABwIDsxzdBkAhwAkCCBrWHAMQBsCB3AOgCyBAK7VIfVOQhgATpADEABRkESbPAAs05GIlBlYASyyGKekAA9EAWgAsAdgAMfewGYAnK9e3XARgBs7v6OrgA0IACeNvYATPZ8tgAcMX7BjgH+9r4AvtnhqJi4hKQUVLQMTKwc3PxColjiktJyEPIAylhoDfhaOmDmBsam5OZWCHb+iXzuvgCsvr6J7rY+7u724VHj-r7u0zGJib5uwa7+B7n56Nj4xGSU1Dh0jCxsXLyCImIQElTNCoQxBYir1dEgQIMTGZwWM7PYpnEVolzjFbLNXEdNjZ5lMfPYso5-LZHGtZjFLiACjdivcyk8Kq9qh86t95ABVchEL5YAYEIxQkYwxD2WZ8SaxWKuRwxYJJXxY7Zk6azFU7HZJFX2XJ5EDkAjSeDgqlFO6lR7PSpvGqfeqNP6ySC8-nDUY2A6uaZHEW+Ry+1zo1wbSLRGIxBIHI7pUNrGUU423EoPcovKrvWrcx3gyEuoXjWbSviIpIotEY+XB8aJeYJZKpX0ZLJx64mxN0i2MtN8Dlc20QJ1DaGgMa2fx8ZFSvy+Ym+QOzWwK6yzI58RxkxyJJKuGJT3ZNwoJ2nmhmpmr9gWuvMywv2JEl9GYivWIK+GspUMi-xz-za7JAA */
createMachine(
  {
    description: "made by @erikras",
    initial: "Mounted",
    context: {
      props: {},
      state: {},
      context: {},
    },
    states: {
      Mounted: {
        entry: "Run Lazy Initializers",
        initial: "Rendered",
        states: {
          Rendered: {
            entry: [
              "Render",
              "Cleanup Layout Effects",
              "Run Layout Effects",
              "Browser Paints Screen",
              "Cleanup Effects",
              "Run Effects",
            ],
            on: {
              "Props Change": {
                actions: "setProps",
              },
              "State Change": {
                actions: "setState",
              },
              "Context Change": {
                actions: "setContext",
              },
            },
          },
        },
        on: {
          Unmount: {
            target: "Unmounted",
          },
        },
      },
      Unmounted: {
        type: "final",
      },
    },
    id: "React Component – Hooks Flow",
  },
  {
    actions: {
      setContext: assign({ props: (_context, event) => event.props }),
      setProps: assign({ props: (_context, event) => event.props }),
      setState: assign({ props: (_context, event) => event.props }),
    },
  }
);
```

## Conclusion

Am I trying to reimplement React using state machines? Hell no!

But this exercise _has_ served to benefit my understanding – and maybe yours
too? – of how React works, how to model flows in state charts using Stately's
visual editor, and how to read and understand state charts.


Modeling React in XState

Render Props are Not Dead

Modern Forms in React

Next Generation Forms with React Final Form


Validation is probably the most complicated part of maintaining form state:
deciding _when_ to validate values, and _when_ and _where_ to display error
messages are important design decisions for making your forms as useable as
possible by the widest range of users.

Over a decade ago, the W3C set out some guidelines for what they thought the
next version of HTML should look like, and they called it HTML5. Part of that
standard included a system for validating form fields, both with native browser
rules, and also the ability to set a custom validation error on a field. These
days, the HTML5 validation standard is
[more-or-less supported by all web browsers](https://caniuse.com/#search=setCustomValidity).

## Why use HTML5 Validation?

I see three primary reasons why HTML5 form validation is a good thing to
incorporate into your application:

### Consistency of Design

By using the browser’s built-in mechanism for displaying form errors, your users
will be given a consistent UI for form errors across the entire internet (or at
least those very few sites that are advanced as yours will be when you start
using HTML5 form validation).

### Accessibility

This is the big one. Screen readers and other accessibility tools need a lot of
help understanding what exactly went wrong when a form submission fails. Some
screen readers will also let the user know a field is required when they enter
the field for the first time.

### Built-In Focus On Errors

As of last week, 🏁 Final Form supports [a plugin](/blog/focus-on-errors) to
focus on the first form field with an error. But with HTML5 Form Validation, it
comes for free from the browser! The browser stops the form submission and
focuses on the first error even before React is given the `onSubmit` event.

---

Introducing...

## [🏁 React Final Form HTML5 Validation](https://github.com/final-form/react-final-form-html5-validation)

I’ve written a drop-in replacement for the `Field` component in 🏁 React Final
Form that wraps the official `Field` component and adds the additional HTML5
validation onto it by doing three things:

- Deducing which DOM input corresponds to the field
- Injecting a special field-level validation function that reads from the
  `input.validity` DOM structure.
- Setting the HTML5 validation error with `input.setCustomValidity()` if there
  is an error from a specified field-level validation function.

The result is a two-way binding between the browser native HTML5 Validation, and
any field-level validation function specified to the component. The bindings are
two-way because any
[HTML5 contraint validation errors](https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#the-constraint-validation-api)
will be added to the 🏁 Final Form state, and any _field-level_ validation
errors from 🏁 Final Form will be set into the HTML5 `validity.customError`
state. Unfortunately, this functionality is not compatible with 🏁 React Final
Form _record-level_ validation, so the two should not be mixed.

> “Why not add this functionality directly into the officially bundled `Field`
> component?”

Good question. The reason is that not everyone needs this functionality, and not
everyone is using 🏁 React Final Form with the DOM (e.g. some people use it with
React Native). Therefore it makes sense to make this a separate package. This
version of `Field` is a thin wrapper over the official `Field` component, and
the only `Field` API that this library uses/overrides is the field-level
validate prop, so even if you are using this library’s `Field` component, you
will still get improvements as features are added to the 🏁 React Final Form
library in the future.

> "How to use it?"

Well, first you change this:

```js
import { Field } from "react-final-form";
```

to this:

```js
import { Field } from "react-final-form-html5-validation";
```

All the regular API of `Field` stays the same, except that now you can pass in
props like `maxLength={25}` or `required` and, optionally, messages to display
when those rules are broken, e.g. `tooLong="Be more concise!"` or
`valueMissing="You need to answer this"` respectively. All of these prop names
are taken from the
[HTML5 Specification](https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#the-constraint-validation-api),
so if you have staff already trained to the standards, they should pick it up
right away.

## What does it look like?

Well, the error UI look slightly different in every browser. No doubt the users
of each of these browsers will recognize this format of displaying error
messages.

<div style={{ textAlign: "center" }}>
  <img
    src="/images/html5-validation-safari.gif"
    alt="HTML5 Validation in Safari"
    width={500}
    height={368}
  />
</div>

<caption>Safari</caption>

<div style={{ textAlign: "center" }}>
  <img
    src="/images/html5-validation-chrome.gif"
    alt="HTML5 Validation in Chrome"
    width={500}
    height={355}
  />
</div>

<caption>Chrome</caption>

<div style={{ textAlign: "center" }}>
  <img
    src="/images/html5-validation-firefox.gif"
    alt="HTML5 Validation in Firefox"
    width={500}
    height={357}
  />
</div>

<caption>Firefox</caption>

And here’s the obligatory sandbox embed for you to play with…

<iframe
  src="https://codesandbox.io/embed/14r018yjp4?fontsize=14&hidenavigation=1&theme=dark"
  style={{
    width: "100%",
    height: 500,
    border: 0,
    borderRadius: 4,
    overflow: "hidden",
  }}
  title="🏁 React Final Form - HTML5 Validation Example"
  allow="accelerometer; ambient-light-sensor; camera; encrypted-media; geolocation; gyroscope; hid; microphone; midi; payment; usb; vr; xr-spatial-tracking"
  sandbox="allow-forms allow-modals allow-popups allow-presentation allow-same-origin allow-scripts"
></iframe>

<caption>Go ahead! Play around with it!</caption>

## Conclusion

HTML5 Form Validation is yet another step towards making 🏁 Final Form the most
versatile, extensible form state management framework for React and beyond. Just
think how pleased your boss will be when you inform her that you’ve made all
your forms much more accessible! 😜

❤️ Thanks for reading. ❤️


🏁 React Final Form HTML5 Validation

A practical guide to Redux Form


With the rise of Higher Order Component composition in the React community,
there are a plethora of libraries, such as my own
[`redux-form`](https://redux-form.com), that will add functionality to your
application by decorating your component and wrapping it in a HOC.

What you end up with is a component structure like this, where you control the
yellow components, `MyContainer` and `MyWrappedComponent`, but you have no
control over the red code, LibraryHOC.

<img
  src="/images/wrapped-hoc.png"
  alt="Wrapped Components Diagram"
  width={1000}
  height={496}
/>

Most such libraries are polite enough to pass through any props that they do not
use as parameters down to your wrapped component, but sometimes they will not
provide a way, e.g. getWrappedInstance, to access instance methods on your
wrapped component.

What can you do? How can you get through this barrier?

## Concrete Example

Let’s lay out a concrete example. Your MyWrappedComponent has instance methods
of load(), save(), and clear(), and you need buttons in your MyContainer to be
able to call these.

```jsx
// MyContainer.js
import React, { Component } from "react";
import MyWrappedComponent from "./MyWrappedComponent";

export default class MyContainer extends Component {
  constructor() {
    // bind handlers
    this.handleLoad = this.handleLoad.bind(this);
    this.handleSave = this.handleSave.bind(this);
    this.handleClear = this.handleClear.bind(this);
  }

  handleLoad() {
    // somehow call load() on MyWrappedComponent
  }

  handleSave() {
    // somehow call save() on MyWrappedComponent
  }

  handleClear() {
    // somehow call clear() on MyWrappedComponent
  }

  render() {
    return (
      <div>
        <button onClick={this.handleLoad}>Load</button>
        <button onClick={this.handleSave}>Save</button>
        <button onClick={this.handleClear}>Clear</button>
        <MyWrappedComponent />
      </div>
    );
  }
}
```

```jsx
// MyWrappedComponent.js
import React, { Component } from "react";
import { hocLibrary } from "some-hoc-library";

@hocLibrary({ config: "parameters" })
export default class MyWrappedComponent extends Component {
  load() {
    // load something
  }

  save() {
    // save something
  }

  clear() {
    // clear something
  }

  render() {
    return <div>Gorgeous UI</div>;
  }
}
```

How can MyContainer drill through the HOC to call methods on
`MyWrappedComponent`?

<div style={{ textAlign: "center" }}>
  <img
    src="/images/drill.gif"
    alt="Wrapped Components Diagram"
    width={362}
    height={360}
  />
</div>

<caption>This HOC is tough!</caption>

## Callback Drill

Because our HOC allows us to pass props down through it, we can pass a callback
that will give our container component references to the wrapped component’s
instance methods.

Let’s see that in action. When the inner `MyWrappedComponent` is going to be
mounted, it sends up the API that it wants to expose to `MyContainer`.

```jsx
// MyContainer.js
import React, { Component } from "react";
import MyWrappedComponent from "./MyWrappedComponent";

export default class MyContainer extends Component {
  constructor() {
    // bind handlers
    this.handleCallback = this.handleCallback.bind(this);
  }

  handleCallback(load, save, clear) {
    // save instance methods from MyWrappedComponent to this
    this.handleLoad = load;
    this.handleSave = save;
    this.handleClear = clear;
  }

  render() {
    return (
      <div>
        <button onClick={this.handleLoad}>Load</button>
        <button onClick={this.handleSave}>Save</button>
        <button onClick={this.handleClear}>Clear</button>
        <MyWrappedComponent methodCallback={this.handleCallback} />
      </div>
    );
  }
}
```

```jsx
// MyWrappedComponent.js
import React, { Component } from "react";
import { hocLibrary } from "some-hoc-library";

@hocLibrary({ config: "parameters" })
export default class MyWrappedComponent extends Component {
  componentWillMount() {
    this.props.methodCallback(
      this.load.bind(this),
      this.save.bind(this),
      this.clear.bind(this)
    );
  }

  load() {
    // load something
  }

  save() {
    // save something
  }

  clear() {
    // clear something
  }

  render() {
    return <div>Gorgeous UI</div>;
  }
}
```

## Conclusion

It is a little messy, but breaking through barriers often is. I have used this
pattern on several occasions, and it works well. One important side note: If
your wrapped component might be unmounted while your container remains, to
prevent a memory leak, you should “unregister” the instance methods via another
callback in `componentWillUnmount()`.

Happy coding!


React

Posted in React