Skip to content

Latest commit

 

History

History
90 lines (32 loc) · 3.41 KB

File metadata and controls

90 lines (32 loc) · 3.41 KB

Thinking in React

1. Break The UI Into A Component Hierarchy

  • The first thing you’ll want to do is to draw boxes around every component (and subcomponent) in the mock and give them all names.

  • But how do you know what should be its own component? Use the same techniques for deciding if you should create a new function or object.

2. Build A Static Version in React

  • To build a static version of your app that renders your data model, you’ll want to build components that reuse other components and pass data using props.

  • props are a way of passing data from parent to child.

  • don’t use state at all to build this static version.

  • State is reserved only for interactivity, that is, data that changes over time.

  • You can build top-down or bottom-up : you can either start with building the components higher up in the hierarchy, or with the ones lower in it.

  • At the end of this step, you’ll have a library of reusable components that render your data model. The components will only have render() methods since this is a static version of your app. The component at the top of the hierarchy will take your data model as a prop. If you make a change to your underlying data model and call ReactDOM.render() again, the UI will be updated. You can see how your UI is updated and where to make changes. React’s one-way data flow (also called one-way binding) keeps everything modular and fast.

3. Identify The Minimal (but complete) Representation Of UI State

  • To make your UI interactive, you need to be able to trigger changes to your underlying data model. React achieves this with state.

  • think of the minimal set of mutable state that your app needs. dont repeat yourself

How would you break a mock into a component heirarchy?

  • draw boxes around every component (and subcomponent) in the mock and give them all names.

What is the single responsibility principle and how does it apply to components?

  • single responsibility principle, that is, a component should ideally only do one thing. If it ends up growing, it should be decomposed into smaller subcomponents.

What does it mean to build a ‘static’ version of your application?

  • to build a version that takes your data model and renders the UI but has no interactivity.

Once you have a static application, what do you need to add?

  1. you’ll want to build components that reuse other components and pass data using props.

  2. You can build top-down or bottom-up

What are the three questions you can ask to determine if something is state?

  1. Is it passed in from a parent via props? If so, it probably isn’t state.
  2. Does it remain unchanged over time? If so, it probably isn’t state.
  3. Can you compute it based on any other state or props in your component? If so, it isn’t state.

How can you identify where state needs to live?

  1. dentify every component that renders something based on that state.

  2. Find a common owner component (a single component above all the components that need the state in the hierarchy).

  3. Either the common owner or another component higher up in the hierarchy should own the state.

  4. If you can’t find a component where it makes sense to own the state, create a new component solely for holding the state and add it somewhere in the hierarchy above the common owner component.