Skip to content

Instantly share code, notes, and snippets.

@ryanmr
Last active July 6, 2020 03:31
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save ryanmr/7361d2057d28fc159f30f2a9a7effd18 to your computer and use it in GitHub Desktop.
Save ryanmr/7361d2057d28fc159f30f2a9a7effd18 to your computer and use it in GitHub Desktop.

Meta

For the last few days, I have been thinking about how much I hate forms and meanwhile, how there are other aspects of the ecosystem that aren't great either.

Forms

What's the deal with forms? Forms, ever since webforms back in the day, seem to be at the unsolvable core of modern frontend development. In today's React take on forms, there have been numerous libraries to help solve them.

Some early work was to integrate them with redux-form. I skipped that one, so I know nothing about it at this point.

A couple years later, I was working on a team using Vue, and there was a great reactive forms library in the Vue ecosystem. It handled validations and touching inputs when they needed to and to not show specific errors. I am fuzzy on the extended validation workflows with that library though. At the same time, while on that team, I remember having a technical discussion with the architect at the time, on some underlying concepts with validation and the model in which I thuought-believed React aligned with.

Imagine this:

  1. state and props are a light (data) source
  2. components are a structure
  3. put your component into the way of a light (data) source... and you get
  4. a projection of a shadow, the user interface

It's a weird stretch, and maybe an excalidrawing is useful here to further convery the point here.

Form validation works like that too though. You have your inputs, your internal state (could props or state, representing settings or prior data - who knows), and you have some business logic to perform that validation and finally, some UI that shows the errors (or not, if it all checks out).

I still think about that discussion from time to time. I had made a weird convoluted abomination extension to React to demo some of my ideas about validation. The time was different, back before hooks. Because everything needed to be a component and render props, causing syntax soup and ineffiecienes.

Shortly after that, I left that project and a couple weeks later I discovered someone was working on a proper variant for React: Formik. At that time, it was render prop based and that was the cutting edge back then, and it would later receive its hooks-rewrite.

Recently, I tried what I consider the next generation of form management packages: react-hook-form. It's a hooks-first, React web/native/you-name-it solution. It has a nice variety of "pieces" to make your journey from minor management to advanced needs. I think. My usage time was a single form for only a couple hours on a Thursday night before a nice holiday break.


After form management though, or maybe before it -- there's the much more insidous problem: data (form) validation. Whether it's coming from a form or being absorbed via POST API routes, you need to validate your data. Form validation is unusually tricky though, because of the natures of JavaScript and HTML themselves. Sort of. If you wrote some text entry prompts in C and you were writing cin among your cout prompts, nobody would find it odd that you can't immiediately add 32 to the hypothetical desiredTemp variable the user's input was stored in. Why then does this seem so much stranger in a (web) form environment? Why, when having a user enter a number in a free text field, it comes in as a string, feel so clumsy?

Maybe because it is.

So you have "123.45", but parsing this thing isn't that bad? Regardless of if you're using React or jQuery or HTML and JavaScript directly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment