
The more I play with [Solid](https://www.solidjs.com/), the more I find its
abstraction incredibly fascinating. I think it might be as revolutionary as
React's "just render everything every time and diff the DOMs" approach was back
in 2013. In my own words as a total n00b:

> When you write your JSX with conditionals and props that are
> [signals](https://www.solidjs.com/docs/latest/api#createsignal), Solid is able
> to notice exactly which pieces of your UI depend on which signal value, and
> can rerender _only that dependent UI_ when the signal value changes.

When I wrote my [Proof of Concept](/blog/solid-final-form-poc) using an external
state management system with Solid, I realized that I had to communicate via
signals, i.e. I had to keep the state I wanted to use in the UI in a signal.
This is _vaguely_ analogous to how the way to force a React component to
rerender is to change some part of its state with `setState()`.

> One important difference in Solid, when coming from React, is realizing that
> your "render function" (the component body itself) is **ONLY CALLED ONCE** on
> first render. All UI updates are dependent on signal changes _from inside the
> JSX_.

So let's try and plug my favorite framework agnostic state management library
into Solid!

## XState

The way you use XState is that you create a machine definition of your finite
state machine, and then you "boot up an instance" of that machine using
`interpret()`, which gives you a "service". Once you `.start()` your service,
you can `.send()` events to it, and generally observe it via listeners or
grabbing a snapshot of the state of the service at any given time.

### `select`

The primary way that you can subscribe to one particular slice of the machine's
"context" (where it stores data) is via a "selector", very much
[like Redux](https://redux.js.org/usage/deriving-data-selectors).

### `matches`

The way you determine what state the machine is in is with a `.matches()`
function. From
[the XState docs](https://xstate.js.org/docs/guides/states.html#state-matches-parentstatevalue):

> The `state.matches(parentStateValue)` method determines whether the current
> state.value is a subset of the given `parentStateValue`. The method determines
> if the parent state value “matches” the state value. For example, assuming the
> current `state.value` is `{ red: 'stop' }`:
>
> ```ts
> state.matches("red"); // => true
> state.matches("red.stop"); // => true
> state.matches({ red: "stop" }); // => true
> state.matches("green"); // => false
> ```

### `can`

A predicate that tells you if you "can" send a given event – i.e. that the
machine is currently listening for that event.

Quoth
[the docs](https://xstate.js.org/docs/guides/states.html#state-methods-and-properties):

> The `state.can(event)` method determines whether an `event` will cause a state
> change if sent to the interpreted machine. The method will return `true` if
> the state will change due to the event being sent; otherwise the method will
> return `false`.

This is especially useful for visually disabling buttons that don't do anything
right now.

### `send`

A state machine isn't much good if you can't send events to it, so we're going
to need to expose the `.send()` function as well.

## `useMachine()`

I've written a ~~hook~~ function called `useMachine()` that takes a state
machine definition and then exposes the above API to be consumed in Solid.
`can`, and `matches` use signals internally, and `select` returns the actual
signal to the data selected. Remember that we must use signals if we want Solid
to rerender parts of our UI.

Oh, and it's all strongly typed AF.

This is what it looks like to consume:

```ts
import { Component, Match, Switch } from "solid-js";
import { useMachine } from "./useMachine";
import { trafficMachine } from "./trafficMachine";
import "./App.css";

export const App: Component = () => {
  const { can, matches, select, send } = useMachine(trafficMachine);
  const cycles = select((s) => s.context.cycles); // defines a signal on first render
  return (
    <div class="app">
      <div>
        <div>Cycles: {cycles()}</div>
        <button onClick={() => send("Reset")}>Reset</button>
      </div>
      <div>
        <Switch>
          <Match when={matches("Stopped")}>
            <div>Stopped</div>
            <button disabled={!can("Start")} onClick={() => send("Start")}>
              Start
            </button>
          </Match>
          <Match when={matches("Started")}>
            <div>Started</div>
            <button disabled={!can("Stop")} onClick={() => send("Stop")}>
              Stop
            </button>
          </Match>
        </Switch>
      </div>
      <div>
        <div class="traffic-light">
          <div class={`red ${matches("Started.Red") ? "on" : "off"}`} />
          <div class={`yellow ${matches("Started.Yellow") ? "on" : "off"}`} />
          <div class={`green ${matches("Started.Green") ? "on" : "off"}`} />
        </div>
      </div>
    </div>
  );
};
```

## State Chart

Just a humble traffic light that counts how many times it's gone through `Red`.

<img
  src="/images/xstate-in-solid-state-chart.png"
  alt="Traffic Light State Chart"
  width={2320}
  height={1592}
/>

## Demo

Click "Open Sandbox" to dig into the actual `useMachine()` code.

<iframe
  src="https://codesandbox.io/embed/xstate-solid-ztsy8t?fontsize=14&hidenavigation=1&theme=dark"
  style={{
    width: "100%",
    height: 500,
    border: 0,
    borderRadius: 4,
    overflow: "hidden",
  }}
  title="XState Solid"
  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>

If you inspect the DOM, you'll see that _only the nodes that need to change are
changing_.

<img
  src="/images/xstate-in-solid-dom.gif"
  alt="Traffic Light DOM GIF"
  width={642}
  height={228}
/>

## Conclusion

This was mostly a learning exercise for me. I'd be happy to contribute this code
to initiate an official `@xstate/solid` library. The Stately people, that
maintain XState, know how to contact me.

Thanks for reading, and I hope you learned something.


XState in Solid


[Five years ago](/blog/final-form-announcement), I challenged myself to create a
form state management library that was framework independent. In 2017, the idea
that maybe React wasn't the best place to manage application state was not
nearly as common as it has become. Formik had just been released and took all of
the form library NPM downloads for the following few years. Formik went _all-in_
on React for state management. The current King of Forms in React is
[React Hook Form](https://react-hook-form.com), again, betting all the marbles
on React's state management prowess.

From the very beginning of Final Form, it was designed to outlive existing
popular frontend frameworks. Form state is two things:

1. more complicated than you think
2. not inherently related to any frontend framework

When our great grandkids are filling out their applications for Space Academy,
they are going to be entering data, be it with a keyboard or a neural implant,
into a form field that is going to have some validation rules on it, and the UX
is gonna _SUCK_ because the engineers at Space Academy didn't spend enough
effort making the form entry experience good.

Just because the form is rendered in the then-popular `Neural4D-VR.js` UI
framework, the flow of the form data will be just like it is now.

> Form State is framework independent.

## Solid JS

I've been hearing rumors of this new React competitor getting more and more
popular. I'd glanced at it a few times, but at a recent conference, I got to
meet the creator, and generally sense the wind of interest headed in its
direction.

The "no virtual DOM" and "reactivity" claims are incredibly intriguing.

[insert React is not
[reactive](https://en.wikipedia.org/wiki/Reactive_programming) joke here]

What really put me over the edge to attempt what I'm about to present to you is
realizing that Solid lets you tack on "directives" to your JSX, which are little
functions that get to manipulate the DOM directly, a benefit of not having a
virtual DOM. This could make a very interesting way to connect inputs to a form
management library.

Especially if there were a form state management library that were framework
agnostic... 🤔

## Proof of Concept

What I'm about to show you is an example of what a Solid Final Form library
_might_ look like. It calls `useForm()` to create a form instance and expose its
API. Potentially all form state could be exposed via Solid's
[signals](https://www.solidjs.com/docs/latest/api#createsignal). From the docs:

> Signals are the most basic reactive primitive. They track a single value
> (which can be any JavaScript object) that changes over time.

In this proof of concept, I have only exposed `values` and `isSubmitting`, but
Final Form has a
[veritable plethora](https://final-form.org/docs/final-form/types/FormState) of
other form state it manages.

`useForm()` also gives us two
[directives](https://www.solidjs.com/docs/latest/api#use___), `field` and
`error`. To connect an input (i.e. attach blur, change, and focus listeners) to
Final Form, we:

1. Throw a `use:field` directly on the `<input/>`
2. There is no step 2, you're done already!
3. How fun are `<li>` gags?

The `field` directive reads the `name` prop on the `input` and knows what field
it is.

To show errors, we don't have a `name` prop, so we have to tell the `error`
directive with:

```jsx
<span use:error="firstName" />
```

Here's the full form component:

```tsx
export const App: Component = () => {
  // Create Form
  const { error, field, handleSubmit, isSubmitting, values } = useForm(
    onSubmit,
    initialValues,
    validate
  );
  // Calculated Signal
  const formattedValues = () => JSON.stringify(values(), undefined, 2);
  return (
    <form onSubmit={handleSubmit}>
      <h1>Solid Final Form 🏁</h1>
      <label>
        <input name="firstName" placeholder="First Name" use:field />
        <span use:error="firstName" />
      </label>
      <label>
        <input name="lastName" placeholder="Last Name" use:field />
        <span use:error="lastName" />
      </label>
      <label>
        <select name="favoriteColor" use:field>
          <option value="">Choose a color</option>
          <option value="#FF0000">Red</option>
          <option value="#00FF00">Green</option>
          <option value="#0000FF">Blue</option>
        </select>
        <span use:error="favoriteColor" />
      </label>
      <button type="submit" disabled={isSubmitting()}>
        Submit
      </button>
      <pre>{formattedValues()}</pre>
    </form>
  );
};
```

In this
[100-line proof of concept](https://codesandbox.io/s/agitated-maxwell-7jpnxw?file=/src/useForm.tsx),
what are the features we're getting?

- Realtime client side validation (as you fix errors, they go away)
- Tracking if a field is "touched" (focused and then blurred) to only show the
  error if a user has visited the field _or attempted to submit the form_
- Blocking submission when there are validation errors
- A signal to tell us if the form is being submitted
- None of that "Is the whole form rerendering? Waaahhh!! 😭🍼" nonsense that
  React gives us
- Render props? What are those??
- A robust battle-tested framework (300k weekly downloads) for managing our form
  state

## Sandbox

<iframe
  src="https://codesandbox.io/embed/solid-final-form-7jpnxw?fontsize=14&hidenavigation=1&theme=dark"
  style={{
    width: "100%",
    height: 500,
    border: 0,
    borderRadius: 4,
    overflow: "hidden",
  }}
  title="Solid Final Form"
  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>

## Future

At the time of writing, this is just a fun Saturday morning fun project. I don't
really feel like I have the bandwidth right now to pursue maintaining another
open source library, but I'd be happy to work closely with anyone who would like
to take this and run with it. You can find me
[on Twitter](https://twitter.com/erikras).


Solid JS

Posted in Solid JS