Part 4.X: simplr-forms — declarative forms for React . Status report

This is series of posts documenting the development of simplr-forms library.

Originally posted on April 27th.

What’s up? How things are going?

Well, there was a pause in writing because many things came up and I had first few days-off in 4 years after establishing QuatroDev. But more on this in a separate post. Now… Forms.

We’re moving fast. Not super visible and appealing (we’ll need CSS for that), but really fast. Most of initial mechanisms are done and work well, which is super amazing! (I really wanna scream this one out)

More specifically those are:

  • Value initialization and update cycle.
  • Modifiers and Normalizers.
  • Reset and Clear buttons (and corresponding methods in store).
  • FormStore statuses cascade from fields: Pristine, Touched, Validating, HasError.
  • Form statuses update as needed: Submitting, SuccessfullySubmitted, ActiveFieldId, Error.
  • Field statuses update as needed: Pristine, Touched, Validating, Error.

What’s still missing:

  • A bunch of premade Validators(#39), Modifiers(#48) and Normalizers (#49).
    Validators are easier, but ideas for Modifiers and Normalizers would really help.
  • Premade DOM fields (#38).
  • FieldsGroup implementation (#37).
  • Form Dehydration / Rehydration mechanism.
  • Making sure everything works as expected.

And… Emitting a whole bunch of actions on FormStore changes.
At the moment things like resetting does not emit anything and it should emit one FormReset action and ValueChanged action for every changed field. And a whole bunch of other actions are missing.
All in all, it’s not a big task, but a meticulous one for sure, requiring many decisions to be made at once.

What kind of decisions you ask? Naming actions. And it ain’t easy, as you know:

There are only two hard problems in Computer Science:
cache invalidation and naming things.
― Phil Karlton

And there’s a theory about a limited amount of decisions a person can make during a single the day, therefore actions will come last.

So… Naming things is stopping you?

Only actions, I’d say. We renamed and streamlined most of the functions already, which means, big portion of the work is done.

Also, we take our time to get naming right from the beginning, because updating it later will break things. And nobody wants breaking changes.

And instead of running to a stable version, we change things in the mechanisms and principles as they come up, because of the same reason:
we can make significant changes to the API now painlessly.

What kind of changes?

One of the changes that came up last week was introduction of FormValidator. A different kind of validator that is used for the whole formobject validation. And it required quite a few changes.

Before, there were only FieldValidators, which means we had to introduce BaseValidator and make (as we call it) the holy trinity:

  • BaseValidator
  • FieldValidator
  • FormValidator

But all is done now. We have both FormValidators and FieldValidators. Kudos to Martynas for the whole validation part.

Soo… What’s the plan?

In short:

  • Make sure everything works as expected.
  • Premade DOM fields
  • Validators, modifiers and normalizers
  • Some cash for the development time…
    We want to contribute as much time as we can, so every contribution of yours is going to help us do just that.

We’re coming to an end of development and will have an amazing library released soon. If you only donate once a month, please think of us next time.

Next in series

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.