NOTES.md

Compound Components

• Give quick overview of current Navigation usage

• Pose question "Why are we defining our own API?"

  • Why not just use React's component API?

• Go over Navigation implementation

• Point out that the reason we're using our own object API is because there is "implicit state"

  • We want the Navigation component to handle the "active route" state without the user having to know about it/handle it

• Go back to Navigation use, pose question "What happens when we want to to render something that isnt a Nav Item"?

• Explain how using our own API, instead of React's component API,

  limits how dynamic (and useful) our component can be

• This is where compound components come in!

• Component components are a pattern where you can pass in implicit state between two components.

• Compound components let you share implicit state without having to break out of React's component model

• Implement a NavigationItem component, export as Navigation.Item

  • Explain how using static properties can be a good way to couple compound components so it's obvious that they must be used together.

• First implementation will display the navigation items correctly, but the active state will not work.

• Implement Navigation.Split, another cool example of compound components

• Render the Logo and SearchBar too, to show off how you can render any components now. Shuffle them around, show how easy it is

• Circle back to implicit state. Compound component API is cool and readable, but the point is to share implicit state. How do we do that?

• Start with React.Children.map and React.cloneElement implementation

• Explain how cloneElement can let you pass in additional props to a child components, which is a good solution for implicit state.

• Show it working with React.cloneElement

• Put the active Navigation.Item inside a div, show how it breaks the implicit state

• Explain why this is, how React.cloneElement is now passing in the implicit state to the wrong component

• Move on to React Context solution

Controlled Components

• Go over RadioGroup component and implementation

• Point out how currently, the input state is uncontrolled

• Discuss how we're probably all familiar with controlled and uncontrolled inputs.

• The idea with controlled inputs is that we can manage the state of the input in React, instead of the DOM. We have full control over it

• Make RadioGroup a controlled component. Use React context.

  • Show off memoize-one for getContext! Cool strategy

• Talk about the advantages of controlled inputs.

  • RadioGroup is in total control of the value being rendered, meaning it can implement any restrictions, side-effects, or behavior that it wants based on the current value

• You could also store the state somewhere else (like Redux) if you wanted

• These same advantages extend to other components that manage some kind of state

• Refactor RadioGroup to accept a value and onChange prop

• Show how, with a controlled compound component, we get the advantage of controlling the state we care about (the value) but also the advantage of not having to be explicit about the state we dont care about.

  • i.e, passing the checked state to each option.

Higher Order Components

• Go over Network Status application

• Show how Online and Offline are duplicating a lot of logic

• Suggest that we could use the compound component pattern we learned

  • Point out that compound components require a single shared parent to manage and provide that implicit state

• We want to use Offline and Online separately

• One option for shared logic between independant components is higher-order components

• Make sure class is clear on the terminology of "higher order component"

  • show a higher order function if necessary

• Explain that HOC is a weird term because it's not "really" a higher- oreder function. It's a factory function that returns a new component

• Implement a withOnlineStatus HOC

• Make sure it sets the correct display name

• Forward refs

• Hoist statics