Thereβs more than one way to build something in React βοΈ
Hereβs a guide thoughπ
1. Break the UI into a component hierarchy
2. Build a static version
3. Identify the complete representation of the UI state
4. Identify where your state should live
5. Add inverse data flow
Hereβs a guide thoughπ
1. Break the UI into a component hierarchy
2. Build a static version
3. Identify the complete representation of the UI state
4. Identify where your state should live
5. Add inverse data flow
1a) How do you know what should be its own component? π€
The same way you should decide whether to create a new function or object.
The single responsibility principle - SRP π‘
A component should only do one thing β
If it grows, it should be decomposed into subcomponents.
The same way you should decide whether to create a new function or object.
The single responsibility principle - SRP π‘
A component should only do one thing β
If it grows, it should be decomposed into subcomponents.
2) π Build a static version π
You can build bottom-up or top-down β²βΌ
In small apps itβs easier to use the top-down approach, ie; start at the top of the hierarchy.
In large projects itβs easier to build bottom-up and write tests as you build π§ͺ
You can build bottom-up or top-down β²βΌ
In small apps itβs easier to use the top-down approach, ie; start at the top of the hierarchy.
In large projects itβs easier to build bottom-up and write tests as you build π§ͺ
2a) To build a static version of an app that renders a data model;
You should build components that reuse other components, & pass data via props. β
State should not be used to build a static version β
State is reserved only for interactivity - data that changes over time.
You should build components that reuse other components, & pass data via props. β
State should not be used to build a static version β
State is reserved only for interactivity - data that changes over time.
2b) React docs suggest this decoupling approach to building (separating static & interactive).
They say it's a more efficient approach.
IMO, I use both approaches depending on what Iβm building.
I suggest learning both techniques & apply what works best for the situation π‘
They say it's a more efficient approach.
IMO, I use both approaches depending on what Iβm building.
I suggest learning both techniques & apply what works best for the situation π‘
3) Identify the minimal (but complete) representation of the UI state
To make UI interactive, you need to be able to trigger changes to the underlying data model.
React achieves this with state ππ‘
To make UI interactive, you need to be able to trigger changes to the underlying data model.
React achieves this with state ππ‘
4) π‘ Identify where your state should live π‘
After identifying the minimal set of an applicationβs state, you need to identify which component(s) mutates, or owns state π€
After identifying the minimal set of an applicationβs state, you need to identify which component(s) mutates, or owns state π€
4a) React is all about one-way data flow down the component hierarchy π‘
Identify every component that renders something based on a set of state.
Find a common owner component - a single component above all the components that need the state in the hierarchy.
Identify every component that renders something based on a set of state.
Find a common owner component - a single component above all the components that need the state in the hierarchy.
4b) Either the common owner or another component higher up should own the state β
You can then pass it down via props to all the components that also rely on the state.
If you canβt find a component where it makes sense to hold state, create a new component for holding state.
You can then pass it down via props to all the components that also rely on the state.
If you canβt find a component where it makes sense to hold state, create a new component for holding state.
5) π Add inverse data flow π
Step 4 allows apps to render correctly as a function of props and state flowing down the component hierarchy.
Data often also needs to flow the other way; components deep in the hierarchy need to update state in components higher up π
Step 4 allows apps to render correctly as a function of props and state flowing down the component hierarchy.
Data often also needs to flow the other way; components deep in the hierarchy need to update state in components higher up π
5a) To do this we pass setState() from the higher-up components down the hierarchy π‘
That way, components deeper in the tree can call setState() when required (like a form input event) to update the state living in the common owner component (a form for example) β
That way, components deeper in the tree can call setState() when required (like a form input event) to update the state living in the common owner component (a form for example) β
That's a wrap!
If you enjoyed this thread, don't forget to like, comment, and retweet the first tweet!
I create threads, and hand-drawn illustrations to level up your software development game π§΅ π¨ π
Follow @NikkiSiapno
for more free tips and free resources.
If you enjoyed this thread, don't forget to like, comment, and retweet the first tweet!
I create threads, and hand-drawn illustrations to level up your software development game π§΅ π¨ π
Follow @NikkiSiapno
for more free tips and free resources.
Loading suggestions...