Skip to content

Commit c5a72b1

Browse files
DovydasNavickasDovydasNavickas
authored
Create 2017-04-08.md (#1)
* Create 2017-04-08.md * Update 2017-04-08.md * Update 2017-04-08.md
1 parent 242f1b1 commit c5a72b1

File tree

1 file changed

+157
-0
lines changed

1 file changed

+157
-0
lines changed

‎docs/2017-04/2017-04-08.md

Lines changed: 157 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,157 @@
1+
## April 8 ([discuss](https://github.com/SimplrJS/simplr-forms/pull/1))
2+
3+
### Attendees
4+
5+
* [Dovydas](https://twitter.com/dovydasnav) (QuatroDev)
6+
* [Martynas](https://twitter.com/MartiogalaLT) (QuatroDev)
7+
8+
### Why do we need yet another forms library?
9+
10+
Over the past few years we worked with React, we tried **MANY** form libraries that are out there.
11+
12+
#### Problems with existing libraries
13+
14+
* There is no de-facto standard library for forms in React, like there is for routing ([react-router](https://github.com/ReactTraining/react-router))
15+
* They all have their limitations and usually big ones
16+
* Performance is usually bottlenecking as the project grows
17+
* No really flux friendly
18+
* Not friendly with TypeScript
19+
* There are not a single library that is build **in the React way**
20+
21+
Ok, so the big one is the libraries can never be consumed in a **React** way, which raises a whole bunch of other problems:
22+
* You have to learn everything from the ground up to use the library
23+
* When you write your app in a declarative react way, you have to fallback to imperative or semi-imperative way for forms
24+
* Library has to reinvent the wheel to *do things*
25+
* Lifecycle management becomes hell on earth
26+
* Race conditions appear out of the blue
27+
28+
I could go on here, but [Michael Jackson](https://github.com/mjackson) said it better [here](https://www.youtube.com/watch?v=Vur2dAFZ4GE)
29+
and the problems are more than apparent.
30+
31+
## So why do we start now?
32+
33+
Well, technically, we started almost a year ago (Jan 12, 2016) by building a `simplr-forms` v0.0.4 and used it internally.
34+
v1.0.0 was also released internally on May 30, 2016.
35+
v2.0.0 as well, released internally on September 7th, 2016.
36+
We introduced v3.0.0-beta in Dec 7, 2016. And we made all possible mistakes during these 3 versions (hopefully).
37+
We had 113 different alphas, betas, RCs and stable ones in between.
38+
39+
And more than a year later, we still don't see a proper library for forms out there. This is why we are putting the efforts into
40+
spec'ing, architecting and building the library out there in public.
41+
42+
### What's the plan?
43+
44+
For a few days already we were talking and ploting the architecture, raising and solving problems on the whiteboard.
45+
At the moment we are ready to to start coding, but first - we'll try to write out ideas.
46+
47+
### Integrity with flux
48+
49+
During 3 versions, we tried different approaches, to have forms:
50+
- Live on their own
51+
- Live in the flux lifecycle
52+
- Something in between the first two
53+
54+
At the moment, we think the best way to have responsive forms (as of fast response time), we have to make the library live on its own.
55+
56+
And for architectural integration (flux/redux/mobx/etc), we hope to make initial flux and redux versions ourselves and then get some help from community as the library becomes **the best forms library out there**.
57+
58+
## Let's get to the point
59+
60+
### Lifecycle
61+
62+
For forms lifecycle, we will be using somewhat flux-ish architecture of actions and at first and it's gonna be quick-and-dirty switches and immutable objects. Later on, we will incorporate simplr-flux package, as we will open-source it soon.
63+
64+
### Principles
65+
66+
1. The source code is written in TypeScript.
67+
2. Architecture is compile-time checked as much as possible.
68+
3. Declarative API first. An imperative API is not going to be first-class citizen.
69+
4. Simplicity in developer-facing API, performance in the backend.
70+
5. Have React Fiber in mind.
71+
6. Validation is first-class citizen.
72+
73+
### Code samples
74+
75+
To get the idea how JSX looks:
76+
77+
```tsx
78+
<Form onSubmit={this.onFormSubmit}>
79+
<Text name="FirstName">
80+
<Validators.MinLength value={3} errorMessage="First name has to be at least ${value} long."/>
81+
<Validators.MaxLength value={10} errorMessage="First name has to be at most ${value} long."/>
82+
</Text>
83+
<Submit>Submit</Submit>
84+
</Form>
85+
```
86+
87+
And the rendered DOM:
88+
```html
89+
<form>
90+
<input type="text" name="FirstName" />
91+
<button type="submit">Submit</button>
92+
</form>
93+
```
94+
95+
As you can see, no wrappers, no custom elements, divs, spans or anything, just a clean form with inputs and buttons.
96+
97+
Having clean output really helps with styling, because you see the same structure in JSX, except for `simplr-forms` specific validators inside text element.
98+
99+
For now, we have to render validators in the virtual DOM, because `input` elements cannot have childrens (at least some of them).
100+
101+
That will change with React Fiber coming in as it will have the ability to return array of elements in the `render` function. With that change, we will be able to render validators alongside, but, of course, that is yet to come.
102+
103+
### Validators
104+
105+
A really important functionality while using forms is data validation.
106+
107+
And the main pains behind validation are:
108+
* Reusability of validators code
109+
* An easy way of defining the requirements of your data
110+
111+
Imperative API is probably the worst solution for this, which leaves a nice spot for declarative one. Unfortunately, there is no way of doing that today, but...
112+
113+
We have another package `simplr-validation`, which was released internally on Feb 15, 2016 and did not change much since. We had 19 versions of the package and most of them were adding functionality, not changing the core principles. Which means the package is done right from the start.
114+
115+
#### More interesting use case
116+
117+
Want to have your mind blown?
118+
119+
Suppose you need to validate your username to be:
120+
* 4 to 128 symbols of length
121+
* Unique in your system, which is a call to your server
122+
123+
Take a second to think how you would approach it today. Then look at this:
124+
125+
```tsx
126+
import { MinLength, MaxLength, DebouncerValidator } from "simplr-forms-core/validators";
127+
128+
<Text name="username">
129+
<MinLength value={4} errorMessage="Min length is ${value}!" />
130+
<MaxLength value={128} errorMessage="Max length is ${value}!" />
131+
/*
132+
Waits for 3 seconds before executing to the next validator.
133+
If the value changes before debouncer expires,
134+
the validation will be stopped and rejected as an error.
135+
Also, form store will ignore validation changes until the value is the newest,
136+
therefore store will update validation result to Valid or Invalid
137+
only after ALL needed validators are executed.
138+
*/
139+
<DebouncerValidator value={3000} />
140+
<CostyValidatorToTheServer />
141+
</Text>
142+
```
143+
144+
What you see here is a declarative way to check all of the requirements *AND* do it in an optimal manner, which is debouncing for some time until the user stops typing the username.
145+
146+
Mind blown? :tada: I hoped so. :clap:
147+
148+
### Coding time!
149+
150+
There are more things to cover here, but we are already hyped-up to get our hands dirty and start coding.
151+
152+
The feedback and questions are more than welcome!
153+
154+
------------
155+
156+
Please feel free to discuss these notes in the [corresponding pull request](https://github.com/SimplrJS/simplr-forms/pull/1).
157+

0 commit comments

Comments
 (0)