Skip to content

Instantly share code, notes, and snippets.

@aweary
Created May 15, 2018 07:22
Show Gist options
  • Save aweary/d5eb70f5dfdd0e8b7c84f4b83c70c4d1 to your computer and use it in GitHub Desktop.
Save aweary/d5eb70f5dfdd0e8b7c84f4b83c70c4d1 to your computer and use it in GitHub Desktop.

Revisions

  1. aweary created this gist May 15, 2018.
    114 changes: 114 additions & 0 deletions NOTES.md
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,114 @@
    # 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