With the current requirements of rapidly changing requirements, the design of suitable architecture architecture for the project is extremely careful consideration. Form design is an integral part of the frontend, and some of the following technical decisions will help you get unforgettable experiences.
Early abstraction (early design is usually design failure)
The fastest thing we can do to refactor that form is to gather the same UI components into a component to reuse and feel proud of ourselves.
For example:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 | Form đăng ký: gồm thông tin các nhân mà người mua hàng cần điền vào và thông tin về đơn hàng của họ \\\\\\\\\\\\ \\ CUSTOMER CONTACT \ \\\\\\\\\\\\ \\\\\\\\\\\\ \\ RECIPE DETAIL \\ \\\\\\\\\\\\ \\\\\\\\\\\\ \\ BLA BLA \\\\\ \\\\\\\\\\\\ From cập nhật: gồm thông tin cá nhân của người mua hàng lấy ra từ api và thông tin về đơn hàng của họ \\\\\\\\\\\\ \\ CUSTOMERCONTACT \\ \\\\\\\\\\\\ \\\\\\\\\\\\ \\ RECIPE DETAIL \\ \\\\\\\\\\\\ Với cặp mắt tinh tường, ta có thể - nhanh chóng cắt ra thành 2 component: <CustomerContact /> và <RecipeDetail /> - rồi vứt nó một xó - rồi import vào 2 form như sau: const RegisterForm = () => ( <Container> <CustomerContact ...{truyền các thể loại vào đêy} /> <RecipeDetail ...{truyền ti tỉ thứ vào đêy} /> // ... các component linh tinh khác </Container> ); const UpdateForm = () => ( <Container> <CustomerContact ...{truyền các thể loại vào đêy} /> <RecipeDetail ...{truyền ti tỉ thứ vào đêy} /> </Container> ); Tại thời điểm này, bạn bắt đầu cảm thấy feel good! |
Until the new spec comes, with all sorts of things, such as:
- The input for the customer name in RegisterForm is manual input, but in UpdateForm, it is to fill from API => simple, add conditions to check whether the data from props is available, if not, then display it empty.
1 2 3 4 5 | <CustomerContact customer={dataFromAPI} /> ... inside CustomerContact <input name="customerName" value={dataFromAPI.custName || ''}} |
- Input the products purchased in the RegisterForm form is allowed to enter, while in UpdateForm it is not => in it is still simple, pass the form type into the CustomerContact props, to know where it is rendered from: v
1 2 3 4 5 | <CustomerContact type="register" /> ... inside CustomerContact <input name="shopItem" disabled={ nã if else check type vào đây } /> |
- RegisterForm calls api abc, xyz, and UpdateForm does not => ez !, n if if condition
- RegisterForm will redirect to a confirmation page, but UpdateForm will not => ez! Na if else condition
- RegisterForm displays the modal for the authentication code, while UpdateForm only displays the form asking Yes / No, are u sure, etc. => ez! Na if else condition
- ….
Gradually, we realized, more and more the components that we wrote “to reuse” bulged with the conditions at the top. And adding features to the form becomes immersed in conditional statements.
So what is the problem here? Is to write a component to reuse the UI, regardless of whether its state is really related to each other.
Monolithic state (state clumping)
In addition to the devil’s behavior of inserting the state of the form into Redux, we can also dance in a similar magic way, such as: letting the state of the global form focus on it, and then using the Context API to access it. For not to chisel props.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 | // day 1 name: ..., email: ..., // day 2 name: ..., email: ..., agreeCondition: ..., address: ..., registerDate: ..., // day 3 name: ..., email: ..., agreeCondition: ..., address: ..., registerDate: ..., ...cơ số dòng code flag_gi_do: ..., flag_gi_do2: ..., cai_abc_xyz: ..., cai_ma_me_gi_do: ..., cai_dau_xanh_rau_ma: ..., ...cơ số dòng code khác |
Increasingly, the editing of the form became more and more confusing, and we gradually felt that the propagation of props from father to son / grandchild / great-grandchild / chit, it was much more relaxed.
Versalite input (universal input)
I wish I could copy and paste the source code here … but anyway, imagine, a versatile input is:
- it can call api to get data for itself => loose, and we connect redux and dispatch actions like a real container.
- it can format the data itself according to the 69 way the component uses it, it only needs to pass flags or a specific data type => yeah, with a condition of 69 or less conditions, you will see hook types that weird useEffect.
- It is directly connected to the global state, and the display changes according to the state changes, everything we do is update the state and all related inputs will change to => sure yeah and the same input, same state, in somewhere else, another display, we have to update the state and when we leave, we have to return the state to the way it was.
- …
In general, the universal input always chokes inside, initially it will be convenient until it becomes a lump of debt that we have to maintain.
Conclusion
In the form, the state is the source of all suffering, and the above are some basic paths to experience it. It’s not difficult to dodge, it’s hard because I want to avoid it! Anyway … here are a few things to keep in mind:
- Duplicate code is acceptable, so use it because code duplication is easy to add / remove / edit / delete.
- Wrong abstraction is to keep seeing that it is the same as gathering it into reuse, note that we only consider it “the same” when its state / operation flow is the same.
- Storing the state of a form in any global form is never as delicious as a clean, clean genealogy tree.
- Components that have reuse (such as TextInput, PhoneInput inputs) must not have it related to the state of the form at all, it should only care about its local state only.