by

Travis Waith-Mair

@travisWaithMair

non-traditional.dev

Stop Writing Reusable React Components

MySudo

We're hiring!!

bedrock-layout.dev

https://www.newline.co/courses/composing-layouts-in-react/

Components have changed everything

Benefits of Components

Breakdown and isolate UI into easier to reason parts
Components are testable
Code Re-use

Benefits of Components

Breakdown and isolate UI into easier to reason parts
Components are testable

Code Re-use

Thinking in React

A Real Life Example

My First Non-Trivial React App

Landing Page Hero

export function Hero(){
	
  return (
    
      <header className='hero'>
      	<h1>Assimilation Point</h1>
     	<p>The point of assimilation</p>
      </header>
    );
    
}

V2

export function Hero({title, subtitle, bkgUrl}){
	
  return (
    
      <header className='hero' style={{background: `url("${bkgUrl}")`}}>
      	<h1>{title}</h1>
     	<p>{subtitle}</p>
      </header>
    );
    
}

V3

export function Hero({title, subtitle, bkgUrl}){

  let style = bkgUrl
    	? {background: `url("${bkgUrl}")`}
    	: undefined
    
  return (
    
      <header className='hero' style={style}>
    
	{title && <h1>{title}</h1>}
        {subtitle && <p>{subtitle}</p>}
         
      </header>
    );
    
}

V4

export function Hero({title, subtitle, bkgUrl, className}){

  const style = bkgUrl
    	? {background: `url("${bkgUrl}")`}
    	: undefined
  
  const finalClassNames = ['hero', className].join(' ')
  
  return (
    
      <header className={finalClassNames} style={style}>
    
	{title && <h1>{title}</h1>}
        {subtitle && <p>{subtitle}</p>}
         
      </header>
    );
    
}

Rinse and Repeat

Tile Component
Tile Group
NavBar
List
ListGroup

Then I Wired It Up

function LandingPage(){
  
  return(
  	<div>
    	{/*...*/}
    	<Hero
    	  title='Assimilation Point'
    	  subtitle="The Point of Assimilation"
    	/>
    	{/*...*/}
    </div>
  );
}

My "Reusable Components" never got reused

The Hypothetical "user" never happened
Almost everything on the landing page were unique to the landing page only
To quote Chantastic, "My code was so DRY, it chaffed"

Why Didn't I just do this?

function LandingPage(){
  
  return(
  	<div>
    	{/*...*/}
    	 <Hero/>
    	{/*...*/}
    </div>
  );
}

Or just this?

function LandingPage(){
  
  return(
  	<div>
    	{/*...*/}
    	 <header className='hero'>
      	  <h1>Assimilation Point</h1>
     	  <p>The point of assimilation</p>
        </header>
    	{/*...*/}
    </div>
  );
}

What's the harm?

Minimal API Surface Area

by Sebastian Markbage

https://youtu.be/4anAwXYqLG8

No Abstraction > Wrong Abstraction

No abstraction is easier to recover from than the wrong abstraction

Abstractions often lead to more abstractions

Why do we do this?

"It solved our problem in the last app"

(And it still will solve our problem if we just make this one little tweak)

Making Abstractions are Fun

react-clean-form is a package I wrote to abstract away wiring up state and change handlers to form inputs

<Form initialState={{userName: '',password: ''}}>
    <input name='userName'/>
    <input name='password'/>
 </Form>

Under the hood, I recursively found every input and injected the change handler into the jsx

You could do it that way, but....

It provided no value over just using uncontrolled components

<form>
    <input name='userName'/>
    <input name='password'/>
</form>

Anything more complicated would most likely need a more powerful form abstraction than just simple state management

Abstraction === Procrastination

It's easy to fool ourselves into thinking we are working hard and being productive.

What we are really doing is delaying solving the hard problems we have now, by trying to solve the hypothetical problems of the future

Self Confidence

[We tend to attach our self worth] to something that can be measured. A set of strict lint rules, a naming schema, a file structure, a lack of duplication.

Dan Abramov, overreated.io

It's easy to compensate for our own self-doubt by attributing our worth to how “clever” we can write our code.

How do we stop ourselves?

Only solve the real problems we have now and not hypothetical ones of the future

Only generalize if it is fixing a bug

Make your abstractions worth it

i.e. Can we reuse this abstraction in multiple places in my app? If not, maybe it's not worth solving the problem generally (yet).

The Rule of Three

Be okay with unwinding abstractions

Thank You

@travisWaithMair
non-traditional.dev