simplify docs + other suggestions

[tnrich]

Hey @garth , it's taken me a long time to realize just how cool the UI driver you've built is. I think it is a huge step in the right direction!

That said, the documentation for it took me a while to wrap my head around. I think if you lead with a barebones example, it might be easier to understand than diving into an explanation of "why" and the internationalization stuff.

Also, I know that it is built to integrate without hassel into your material-component library, but I see no reason why it couldn't be marketed as a component-agnostic solution to fields+forms using cerebral (which it indeed is!).

I still have a few questions about the overall set-up as well.. First off, it looks as if validation is only run for the form on submit. Is it possible to run the validation after each component is "touched+blurred"?

Finally, do you think it would be possible to simplify some of the setup? I think with some work, the number of steps a new user has to take to set it up could be greatly reduced..

Overall awesome job. As I continue to try to understand all of it, I can hopefully start making some more informed suggestions :)

[garth]

@tnrich Thanks for the feedback. I agree about the docs. i18n is entirely optional and I should really put that stuff at the end.

Validations should run when ever a field is modified or form submitted.

With regards to making it more generic, I was thinking that it might be possible to add an "adaptor" layer that could be customized for different frameworks. But then you do start to complicate things to the point where you might as well write a specific ui-driver. Maybe it could take some attribute mapping data on setup? Have to thing about that some more....

By setup steps, I assume you mean lines of code for each form? This is mostly dictated by the different stages in the form's lifecycle: declaration => cerebral bindings => render props => form fields => form submission => form validation (action). Other than simplifying the syntax for each step I think that they're all necessary. Still I'm open to suggestions if you have ideas?

I will work on an adaptation of this lib for snabbdom, so perhaps I can address some of these issues then.

[garth]

@tnrich I tried to simplify the docs quite a bit this time around. Let me know if it's any better than before?