Hello Folks 👋
Farzad YZ
Software Engineer
- Javascript: React, State Managements, Node.js
- Open Source (🙏 Github)
- FP: Elm, Reason
Where to find me
- Twitter: @Farzad_YZ
- Medium : @Farzad_YZ
- Github : @farskid
- Website: farzadyz.com
Headless React
It's all about render
class MyComponent extends React.Component {
render() {
// Render here
}
}
render: the only required method
It's all about rendering
- Delrataive renderings
- Not a framework but a rendering library
It's all about rendering
- Thinking in React === Thinking about different rendering sections
It's all about rendering
- Render based on props vs Render based on props and state
- Statefull vs Stateless, Container vs Component, Dumb vs Smart
What if I told you, React is
NOT ONLY FOR RENDERING
?
What the heck does HEADLESS mean?
Headless ~ Renderless
No Rendering === No GUI
Headless in React
- Render nothing!
return null - Delegate rendering (Render Props)
this.props.children(...args) - Decorating (HOC)
withRouterconnect
Story Time
© Merrick Christensen
Basic CoinFlip
Support images
Re-use in Blog
Bring back Tails and Heads text for SEO
- Support 2 usecases with different implementations
Add reflip button ONLY in the app
- Add a button to flip again on click
The co-worker disaster Happens!
Your coworker comes by and wants to re-use your CoinFlip component for new usecase <DiceRoll />
- Totally different interface
- Also be used in both app and blog
- Totally different odd! (diceroll in 1/6 but coinflip is 1/2)
Now What?
- Sorry, go dice yourself.
- Add DiceRoll to CoinFlip too!
(🔉 Crushing barebones sound in the background)
Headless Component enters
Let's decouple the logic from rendering.
Sum up the Story
- Probability, 1st abstraction, Headless (different odds)
- CoinFlip and DiceRolle, 2nd abstraction, Still Headless (different implementations)
- BlogCoinFlip, AppCoinFlip, BlogDiceRoll, AppDiceRoll
Advantages
- Separation of concerns
- Easier to reason about
- Easier to test
- Decoupling === (maintainable, small learning curve)
- Reusable, Composable
- Scalable for change of requirements
Disadvantages
- Same as other abstractions
- Implementation cost (time, code size)
- Cost of indirection
- Codebase learning curve
When to use?
Like any other abstractions, when the benefits weigh more than the costs.
What to cover with this pattern?
- Declarative Side effects (fetch, logging, timers, Web Speech, Geolocation, WebRTC handlers, ...)
- Separating Logics (Abstract logics, State moderation)
- Declatarive data structures (Map, set, WeakMap, List)
What to cover with this pattern?
- Declarative feedbacks (Hover, Focus, Active)
- Declarative Form Data (!!)
- Declarative State reducers, state selectors (Redux in React 😱)