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.
- Part 1: Why are we doing this?
- Part 2: Core, validation, testing.
- Part 3: First e2e flow, FormStore.ToObject()
- Part 4: Normalizers and Modifiers
- Part 4.X: Status report
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:
Valueinitialization and update cycle.
Clearbuttons (and corresponding methods in store).
FormStorestatuses cascade from fields:
Formstatuses update as needed:
Fieldstatuses update as needed:
What’s still missing:
- A bunch of premade
Validators are easier, but ideas for
Normalizerswould really help.
- Premade DOM fields (#38).
- Making sure everything works as expected.
And… Emitting a whole bunch of actions on
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:
But all is done now. We have both
FieldValidators. Kudos to Martynas for the whole validation part.
Soo… What’s the plan?
- 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.