DEV Community: Hans Hoffman

Exhaustive pattern matching in TypeScript

Hans Hoffman — Fri, 04 Jun 2021 18:32:48 +0000

The switch statements does not enforce exhaustive pattern matching (objective), the syntax is incredibly ugly (subjective) and is a poorly designed language feature (arguably objective). Thankfully, we can eliminate the shortcomings of the switch statement and improve the quality of our code using pattern matching instead.

There is a TC39 Stage 1 pattern matching proposal for the curious types here.

Example 1 (simple):

Say you have a string literal union type:

type Icon = "chart" | "file-check" | "paper-plane" | "users";

and you want to conditionally render the appropriate icon so your first approach is the old trusted switch statement:

const renderIcon = (icon: Icon): JSX.Element => {
  switch (icon) {
    case "chart":
      return <ChartIcon />;
    case "file-check":
      return <FileCheckIcon />;
    case "paper-plane":
      return <PaperPlaneIcon />;
    case "users":
      return <UsersIcon />;
  }
};

Here, the function's explicit return type is our only saving grace so to speak — not the switch statement itself. If we were to instead use the implicit return type of JSX.Element | undefined and then forget a case, the TypeScript compiler would not yell at us. I would therefore argue as a developer I have failed my current task as well as preventing those behind me from introducing bugs because I did communicate my intent clearly — this function needs to account for all possibilities, return a JSX.Element and have zero side effects.

We can refactor this using a library called ts-pattern to achieve that intent.

const renderIcon = (icon: Icon): JSX.Element => {
  return match(icon)
    .with("chart", () => <ChartIcon />)
    .with("file-check", () => <FileCheckIcon />)
    .with("paper-plane", () => <PaperPlaneIcon />)
    .with("users", () => <UsersIcon />)
    .exhaustive();
};

Example 2 (advanced):

Say you have a branded type / discriminate union type / tagged union type:

type V1Report = {
  id: string;
  results: { /* whatever */ },
  year: string;
}

type V2Report = {
  id: string;
  results: { /* whatever */ },
  year: string;
}

type Report = { tag: "v1", value: V1Report } | { tag: "v2", value: V2Report }

// later in some function
match(report)
  .with({ tag: "v1" }, (v1Report) => /* do something with report */)
  .with({ tag: "v2" }, (v2Report) => /* do something with report */)
  .exhaustive()

12 observations from conducting my first user interviews and survey

Hans Hoffman — Fri, 04 Jun 2021 14:18:53 +0000

Recently I conducted 15 user interviews and 1 large user survey on my entrepreneurial quest to start my own software company. Admittedly, I hired a freelancer to help since I felt overwhelmed and unprepared — there is both an art and science to research interviews. Yes, this sounds obvious, but it really hits home when you experience it first hand. Furthermore, my perspective is biased because this is my ugly baby after all, so I wanted to avoid confirmation bias as much as possible.

I am sharing below a few observations and lessons learned for others in a similar position because this is exactly the kind of wisdom I wish had been imparted on me before I spent 4 months conducting research. Again, I am no expert so I may be wrong on some/most/everything. I am open to learning if you would like to correct me.

Start interviews establishing a common vocabulary to remove the possibility of confusion and/or assumptions.
Terminate interviews that are not going well. E.g. the interviewee does not have the necessary language fluency to comprehend and/or articulate their opinions.
Discuss internally how the interview went immediately after to make small course corrections. E.g. Are some questions commonly tripping people up? Are you even interviewing the right people?
There is always at least 1 takeaway or golden nugget per interviewee. It is your job to find it; it does not always come easy.
Having an observer helps. This individual can see/hear things that the interviewer might miss.
Cultural differences will influence responses, therefore you need to understand these to better understand what you are being told.
Always dive into the why with interviewee responses. E.g. what does this person care so much or so little about X?
Be willing to abandon certain planned questions if you are presented with an opportunity too good to pass up to dive deep into something an interviewee says that "hits all the right notes" on one of your assumptions. This happens on rare occasions so take advantage!
There is a real struggle between "reeling" in interviewees and letting them go off the deep end because you never know what unexpected ideas you may uncover in your early stages of research.
Clear, simple, non-biased, open-ended questions are very hard to craft but critical to maximizing your research.
I am going to make a bold claim: user surveys are a waste of time and $$$ in the discovery phase of the UX design process. They are best suited for narrowing your research which is counter productive to your efforts early on.
Surface-only responses are not very helpful. A "cool cucumber" does not give very insightful answers. I discovered after re-watching all the recorded interviews that stoic individuals needed to be nudged somehow to break rank so to speak to give emotional responses. Only then were we able to really dive into our research.

Horizon (Dark) iTerm2 theme

Hans Hoffman — Sat, 17 Apr 2021 00:58:15 +0000

If you've been searching for a Horizon (Dark) theme for iTerm2, look no further! Inspiration taken from the Visual Studio Code theme plugin.

iTerm2:

And as an added bonus, here's what your VIM could look like:

Download here

Formik === Final Form ??

Hans Hoffman — Sat, 17 Oct 2020 23:33:05 +0000

This post is not a battle royal or a straw man debate where one library stands victorious at the end. No, both Formik and Final Form do forms quite well and evidently with incredibly similar APIs. Their differences do not become apparent until you dive into the philosophies behind the development of each.

Checkout the source code and play with the app if you are curious.

rhoskal / formik-final-form

A little comparison between the two

Philosophy

Formik

The primary guiding principle behind Formik was to keep it simple. Consequently, this constraint resulted in no external state management, no subscriptions or observables and no re-inventing the wheel - it simply uses React. Therefore, if you have a problem understanding Formik then you probably have a problem understanding React.

Final Form

The creator of Final Form, Erik Rasmussen, also wrote Redux Form. Certain issues encountered in the aforementioned evidently influenced the two-part structure of Final Form: 1) a core written in Javascript to make it framework agnostic and 2) separate wrappers around Final Form’s subscription-based state management in your framework of choice such as react-final-form or vue-final-form.

Performance

Formik

Since Formik is built with React, it naturally takes advantage of builtin performance optimizations. Should you really need it (e.g. gigantic forms with > 70 fields), React’s shouldComponentUpdate lifecycle method can be indirectly used through the special <FastField /> component.

Final Form

Final Form is based on the Observer pattern, so observers can subscribe to receive updates for either form or field state changes. By default, like Formik, it subscribes to all form updates. It keeps state out of React, and then uses React context to hook in to the tree with react-final-form as previously mentioned.

It is not clear to me how subscription based performance enhancements compare with React’s reconciliation algorithm since I could not find any thoroughly detailed assessments. Therefore, I remain skeptical until proven otherwise.

Validation

Formik

Formik capitalizes on the powerful, and popular validation library Yup. Yup’s builder pattern makes building validation schemas a breeze and less error prone. You can also bring your own validation (BYOV) if Yup is not sufficient for your particular use case.

Final Form

Sadly, unlike Formik, Final Form subscribes to the BYOV philosophy. This is where I feel that the library missed an opportunity to save developers from themselves. Form libraries (in my opinion) are supposed to help with validation not skimp on it.

License

Formik → Apache 2.0
React Final Form → MIT

Bundle Size

Minified + gzipped:

Formik → ~15 kB
Final Form + React Final Form → ~9 kB
Redux Form → ~27 kB (for comparison)

Conclusion

As previously stated, the two libraries are quite similar so it really comes down to a simple question: which one does your your team prefer?

Write your own type-safe reducer to normalize your data

Hans Hoffman — Wed, 07 Oct 2020 17:28:31 +0000

Background

Given the following JSON data with nested objects, what is the best data structure to use in our Redux store?

[
  {
    "id": "xlkxhemkuiam",
    "title": "voluptates sequi et praesentium eos consequatur cumque omnis",
    "body": "Beatae distinctio libero voluptates nobis voluptatem...",
    "createdAt": "Tue, 22 Sep 2020 16:28:53 GMT",
    "user": {
      "id": "lswamlcggqlw",
      "handle": "Payton_Carter",
      "imgUrl": "https://s3.amazonaws.com/uifaces/faces/twitter/dawidwu/128.jpg"
    },
    "comments": [
      {
        "id": "jsyrjkxwtpmu",
        "body": "Sint deserunt assumenda voluptas doloremque repudiandae...",
        "createdAt": "Fri, 25 Sep 2020 18:03:26 GMT",
        "user": {
          "id": "hqhhywrxpprz",
          "handle": "Orlo97",
          "imgUrl": "https://s3.amazonaws.com/uifaces/faces/twitter/ponchomendivil/128.jpg"
        }
      }
    ]
  },
...
]

The easiest and most common approach would be to store the array of blog posts exactly as they were received. If we wanted to display data for a particular post given its id then we'd have to iterate over the array until we found our matching post. Moreover, we again would have to rely on iteration if we wanted to perform an upsert action in our Redux store. Obviously both tasks suffer from a time complexity of O(n) so we can instead normalize our data and consequently reduce our complexity down to O(1).

You don't always have to deal with data the same format the server gives you.

Yes, this idea has been around for years and there are popular tools like normalizr to help with this. But what if you have deeply nested data that is not easily parsable by such tools? Here I present one possible approach using a few popular React Typescript fp libraries fp-ts, io-ts, monocle-ts to build a custom, type-safe reducer function.

This is more of a quick run through rather than a step-by-step guide. If you are interested, I encourage you to dive into the source code. You can also see a live demo here.

rhoskal / fp-data-normalization

Type-safe data normalization using fp-ts

Let's normalize

Before we start, let's specify the shape of our normalized data in a way that would allow us O(1) lookups:

export type AppState = {
  entities: {
    comments: NormalizedComments;
    posts: NormalizedPosts;
    users: NormalizedUsers;
  };
};

Step 1

We can get both compile time and runtime type safety by using io-ts to declare our domain types. For example, our Post:

/**
 * Composite types
 */

export const Post = t.type({
  id: IdString,
  title: NonEmptyString,
  body: NonEmptyString,
  createdAt: UtcDateString,
  user: User,
  comments: Comments,
});

/**
 * Static types
 */

export type Post = t.TypeOf<typeof Post>;

We can add a few constraints instead of just using basic strings by specifying custom types. For example, IdString ensures the given string is exactly 12 characters in length and contains no digits e.g. "jsyrjkxwtpmu".

/**
 * Type guards
 */

const isIdString = (input: unknown): input is string => {
  return typeof input === "string" && /[A-Za-z]{12}/g.test(input);
};

/**
 * Custom codecs
 */

const IdString = new t.Type<string, string, unknown>(
  "idString",
  isIdString,
  (input, context) => (isIdString(input) ? t.success(input) : t.failure(input, context)),
  t.identity,
);

Step 2

Now we can protect our React app from crashing due to an unexpected API response by using our domain static types. We've also elevated all the superfluous error checking in our domain logic into one simple check. Thank you decoders! 🎉

const fetchPosts = (): Posts => {
  const result = Posts.decode(data);

  return pipe(
    result,
    E.fold(
      () => {
        console.warn(PathReporter.report(result));

        return [];
      },
      (posts) => posts,
    ),
  );
};

This is the really cool part! If the API response contains an id in the wrong format or is missing entirely, we can catch this before we enter our reducer function. Let that sink if for a bit... Even an internal API can change right under our feet or have corrupt data make its way in. We can protect our app from this. Manipulate data.json yourself and see it in action.

The ability to declare types once and get both compile and runtime safety is a joy worth experiencing.

The Either type returned from the io-ts Decoder produces one interesting side effect worth pointing out — we pass an empty array on failure which would eventually result in no blog posts rendered in our React app. Does this provide a nice UX? Sure our app not crashing is better than the alternative, but maybe we can find a happy medium and render some data?

I'm still working through this myself. A few co-workers suggested looking into fp-ts These and one even submitted a PR! Check it out for yourself.

Step 3

Finally, instead of doing nasty and error prone JS object spreading when trying to add or update entities in our state, we can use monocle-ts to define lenses will make our life easier. Below, our upsert function first checks to see if we already have the given user stored so we can ensure that certain user properties cannot be updated once inserted — such as a user's id. Moreover, a user can change their handle and profile image in my example so we want to allow those properties to be updated.

/**
 * Optics
 */

const usersLens = Lens.fromPath<AppState>()(["entities", "users"]);
const atUser = (id: IdString) => Lens.fromProp<NormalizedUsers>()(id);

/**
 * Upserts
 */

const upsertUser = (user: User) => (state: AppState): AppState => {
  return pipe(
    state,
    R.lookup(user.id),
    O.fold(
      () => {
        return pipe(
          state,
          usersLens.compose(atUser(user.id)).set({
            id: user.id,
            handle: user.handle,
            imgUrl: user.imgUrl,
          }),
        );
      },
      (_user) => {
        return pipe(
          state,
          usersLens.compose(atUser(user.id)).modify(
            (prevUser): UserEntity => ({
              ...prevUser,
              handle: user.handle,
              imgUrl: user.imgUrl,
            }),
          ),
        );
      },
    ),
  );
};

Conclusion

Normalizing data using lenses and decoders does require some effort, but I hope I have demonstrated the reward for doing so. Doesn't type-safe code like this puts a smile on you face? 😎

P.S. — Please let me know if you have a more elegant or idiomatic way of doing this! I'm all ears.

Dynamic CSS themes with Elm

Hans Hoffman — Sun, 27 Sep 2020 17:32:41 +0000

Inspiration

I wanted to learn how to theme Single Page Applications (SPAs) apps using global CSS3 variables instead of CSS-in-JS since some design systems are built to be platform agnostic. I'm using Elm because it is my favorite hobby language until someone pays me use it professionally 😎

Spec

If you have never done CSS themes before, no worries — it is surprisingly simple. We will have one button centered in the screen and the text should inform the user what theme will be activated should they click. There is no limit to the number of times the user can toggle the theme. The default theme is "Solarized Light". Typically your app would remember the users selection by storing it in a database or in local cache, but not this demo. Speaking of which, you can play with a live demo here!

Note: be sure to turn off the Dark Reader Chrome extension if you have it.

Code

First, we need to setup our default theme colors in the :root CSS pseudo-class (learn more here) and a .dark class for the overrides for when the theme is changed to "Solarized Dark".

:root {
  --theme-background: #fdf6e3;
  --theme-selection-background: #ece7d5;
  --theme-foreground: #657a81;
  --theme-accent1: #2aa198;
  --theme-accent2: #b58900;
}

.dark {
  --theme-background: #002b36;
  --theme-selection-background: #073642;
  --theme-foreground: #b58900;
  --theme-accent1: #d33682;
  --theme-accent2: #268bd2;
}

Next, since Elm is responsible for rendering our HTML it needs to know what the current theme is. This state is used to change the text in the render logic of the change theme button. So let's model our simple domain and decide on our ubiquitous language.

Option 1:
Action → Toggle theme

type alias Model =
    Bool

type Msg
    = ToggleTheme Bool

Option 2:
Action → Change theme

type Theme
    = SolarizedLight
    | SolarizedDark

type alias Model =
    Theme

type Msg
    = ChangeTheme Theme

Either option would work, but I'd argue that that a sum type is more elegant and extensible should you want to add more themes such as high contrast mode for the visually impaired, etc. So let's go with option 2 and create our button render logic.

themeButton : Model -> Html Msg
themeButton model =
    case model of
        SolarizedDark ->
            button [ class "theme-btn", onClick (ChangeTheme SolarizedLight) ]
                [ text "Toggle Light" ]

        SolarizedLight ->
            button [ class "theme-btn", onClick (ChangeTheme SolarizedDark) ]
                [ text "Toggle Dark" ]

The last bit relies on good old Javascript to manipulate the CSS classes on the DOM to reflect the current theme. The .dark class we created earlier needs to be added as an attribute to the <body> element so the color overrides will take effect. Elm does not allow us to directly manipulate the DOM (if you did not already know) so how do we do this?

Enter Elm ports — the smart way to interact with JS (Javascript-as-a-service). Thankfully this is all the vanilla JS we need.

app.ports.changeTheme.subscribe(theme => {
    if (theme === "") {
        document.body.classList.remove("dark");
    } else {
        document.body.classList.add(theme);
    }
})

One more bit... Our update function needs to broadcast the changeTheme message we just said we would listen for ↑ with the respective theme.

update : Msg -> Model -> ( Model, Cmd Msg )
update msg _ =
    case msg of
        ChangeTheme theme ->
            case theme of
                SolarizedDark ->
                    ( SolarizedDark, changeTheme "dark" )

                SolarizedLight ->
                    ( SolarizedLight, changeTheme "" )

Conclusion

Other compile-to-Javascript languages such as ReasonReact have different philosophies about Javascript interopt. I'm not making an argument in favor of/against any right now, but hopefully this small example highlights how Elm pushes untrusted code to the edges.

DEV Community: Hans Hoffman

Exhaustive pattern matching in TypeScript

Example 1 (simple):

Example 2 (advanced):

12 observations from conducting my first user interviews and survey

Horizon (Dark) iTerm2 theme

Formik === Final Form ??

rhoskal / formik-final-form

A little comparison between the two

Philosophy

Formik

Final Form

Performance

Formik

Final Form

Validation

Formik

Final Form

License

Bundle Size

Conclusion

Write your own type-safe reducer to normalize your data

Background

rhoskal / fp-data-normalization

Type-safe data normalization using fp-ts

Let's normalize

Step 1

Step 2

Step 3

Conclusion

Dynamic CSS themes with Elm

Inspiration

Spec

Code

Conclusion

rhoskal / elm-dynamic-css-theme

Use CSS3 variables to dynamically change the theme.