
I'd never been to Florida. Not counting one time when I flew into Fort
Lauderdale to hop on a cruise ship. So when my friends at
[Infobip Shift](https://shift.infobip.com/), my Croatian peeps who have invited
me twice already to their lovely homeland, announced that they were introducing
a [conference in Miami](https://shift.infobip.com/us/), I jumped at their
generous offer.
[Everything I know about Miami, I learned from Burn Notice and Dexter](https://twitter.com/erikras/status/1635620326330576901),
so I assumed there would be plenty of bikinis, cocktails, explosions, and
pristine vigilante murder. TL;DR: let's just say they named their NBA team
correctly. 🔥

<p>
<img
  src="/images/infobip-shift-miami-stadium.jpg"
  alt="The Kaseya Center"
  width={4032}
  height={3024}
/>

<caption>
  The speakers' hotel was right across the street from where the Miami Heat
  play. On the second day of the conference, they hosted, and were beaten
  by, the Boston Celtics.
</caption>
</p>

The day before the conference, I spent the entire day with a soon-to-be good
friend, [Alexandra Spalato](https://alexandraspalato.com), a French woman who
lives on the Spanish island of Mallorca. Both being expats in Spain, we had a
ton to talk about. She had the brilliant idea of visiting Little Havana, a
gorgeous little _barrio_ of Miami full of Cuban culture. We then felt obligated
to check out the famed Miami Beach, but both living near good beaches, we were
very underwhelmed. The pelicans were cool, though.

<p>
<img
  src="/images/infobip-shift-miami-alexandra.jpg"
  alt="Me and Alexandra at lunch"
  width={4032}
  height={3024}
/>

<caption>
  Lunch with Alexandra.
</caption>
</p>

<p>
<img
  src="/images/infobip-shift-miami-cuban-fajitas.jpg"
  alt="Cuban Fajitas"
  width={3024}
  height={2859}
/>

<caption>
  Cuban fajitas for lunch. Just like Mexican fajitas, but instead of
  tortillas, it's crispy banana cakes.
</caption>
</p>

## Infobip Shift Miami – 2023

<p>
<img
  src="/images/infobip-shift-miami-venue.jpg"
  alt="The venue"
  width={8316}
  height={3870}
/>

<caption>
  Look at this disgusting venue! 🌴🌴🌴🌴🌴
</caption>
</p>

The conference itself was great! Much like how it's nice to transition back and
forth between sandals and sweaters as the seasons change, it's refreshing to
alternate between single-track and multi-track conferences. So it was nice to
know that there was only ever one talk going on at this one. I tried to attend
most of them, both for knowledge, but also for emotional support for my fellow
speakers. It's so nice to have someone in the front row nodding when you're
behind the podium. There were three talks that really stood out to me.

The first was from [John Romero](https://twitter.com/romero), the creator of
[DOOM](<https://en.wikipedia.org/wiki/Doom_(franchise)>), on the timeline of how
they created a genre-defining masterpiece in a fury of development effort that
can only be mustered in one's twenties. I especially appreciated how, despite
being in Texas at the time, they modeled all the weapons after toys they found
in Toys Я Us. My favorite part of seeing him was getting to talk to him
afterwards, and telling him how, as a school project in high school, a friend
and I modeled our school in a DOOM level editor, somehow got teachers into the
racquetball court (white background) to pose in all 32 (64?) poses to generate
sprites for them, and then we ended up with a DOOM level that allowed the player
to walk around the school shotgunning teachers in the face. This was before
Columbine. Everyone took it in good fun. Nowadays, you'd be #canceled for life
for such abhorrent ideas.

<p>
<img
  src="/images/infobip-shift-miami-john-romero.jpg"
  alt="Me and John Romero"
  width={4032}
  height={3024}
/>

<caption>
  The creator of DOOM with the harbinger of it.
</caption>
</p>

The second was from [Joyce Lin](https://twitter.com/PetuniaGray). I met her two
years earlier at my first conference in Croatia, and we clicked immediately. Our
senses of humor align disturbingly well.
[Her talk](https://www.youtube.com/watch?v=8aHzQEgM1gg) was about the history of
APIs, and, having been a web developer for 20+ years, I knew every single part
of it. She did a gimmick where she gave the audience quizzes and awarded Postman
swag as prizes. About halfway through, she had to tell me to STFU because I knew
all the answers.

<p>
<img
  src="/images/infobip-shift-miami-joyce-lin.jpg"
  alt="Me and Joyce Lin"
  width={4032}
  height={3024}
/>

<caption>
  Joyce Lin and I, just getting started with the tequila.
</caption>
</p>

The one that probably most blew me away was from a guy I've known on Twitter for
years, named [Jhey Tompkins](https://twitter.com/jh3yy). Turns out he really
does wear that hat all the time! Gotta respect his personal branding.
[His talk](https://www.youtube.com/watch?v=88D6jLHFw3Q) included some crazy
ambitious things, like interacting with his slides in realtime via voice and
hand gestures with his phone. He concluded by showing a QR code where we, the
audience, could all connect and pop up emojis and comments over his slides.
Credit to the audience for being completely tasteful when we had full control to
be jerks.

## My Talk

My talk was one I've been thinking about giving for 6 months, ever since seeing
a talk about Solid JS and meeting its creator, Ryan Carniato, at
[[a disaster of a conference](https://blog.tomayac.com/2022/11/23/modern-frontends-live/)]
in London last November. I find Solid extremly interesting. Hence my blog posts
about
[Solid Final Form – Proof of Concept](https://erikras.com/blog/solid-final-form-poc)
and [XState in Solid](https://erikras.com/blog/xstate-in-solid). As a React
developer by profession, I figured I had a unique perspective to explain Solid
to other React devs.

<video>vxTbDKaSnkk</video>

The day after the conference, as a result of a "what to do in Miami" search, I
took a boat tour of celebrity houses. I saw the mansions of Antonio Banderas,
Jackie Chan (which is available on Airbnb for $7k/night for 10 people), Floyd
Mayweather, Celia Cruz, Ricky Martin, DJ Kali, Puff Daddy, JLo, Will Smith,
Rihanna, David Beckham, Gloria and Emilio Estefan, and Fisher Island, with no
bridges, where property is owned by Tom Cruise, Julia Roberts, and Oprah.

<p>
<img
  src="/images/infobip-shift-miami-skyline.jpg"
  alt="Miami skyline selfie"
  width={3924}
  height={2943}
/>

<caption>
  Miami skyline selfie.
</caption>
</p>

<p>
<img
  src="/images/infobip-shift-miami-rainy-plane.jpg"
  alt="Rainy sunset plane"
  width={3336}
  height={3024}
/>

<caption>
  There was a fantastic Florida lightning storm in the distance as I waited
  to board my plane back to the Olde Worlde.
</caption>
</p>

Thank you so much to the Infobip Shift team for knocking another conference out
of the park. It was an amazing experience. 💙


Solid for React Developers


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/intent/follow?screen_name=erikras).


Solid JS

Posted in Solid JS