Putting it all together
- How would you break a mock into a component heirarchy?
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.
- What is the single responsibility principle and how does it apply to components?
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?
it’s 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?
interactivity.
-
What are the three questions you can ask to determine if something is state?
- Is it passed in from a parent via props? If so, it probably isn’t state.
- Does it remain unchanged over time? If so, it probably isn’t state.
- 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?
- Identify every component that renders something based on that state.
- Find a common owner component (a single component above all the components that need the state in the hierarchy).
- Either the common owner or another component higher up in the hierarchy should own the state.
- 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.
301 | Home |
---|---|
read01 | Introduction to React and Components |
read02 | State and Props |
read03 | Passing Functions as Props |
read04 | React and Forms |
read05 | Putting it all together |
read06 | NODE.JS |
read07 | REST |
read08 | APIs |
read09 | FUNCTIONAL PROGRAMMING |
read10 | In memory storage |
read11 | Authentication |
read12 | Mongo and Mongoose |
read13 | CRUD |
read14 | Project Ideas |
read15 | Project Kickoff |