DEV Community: Mike Wu

React: Senior devs write small components! 🚀

Mike Wu — Tue, 15 Feb 2022 06:19:20 +0000

Rather than have a few components that do many things, we should prefer to create many smaller components that we can put together (compose) to achieve the desired effect.

TL;DR: Whenever your component starts accepting too many props, it's usually a sign that the component could be broken up into separate parts, where each part is only concerned with one thing. By separating out the components they become easier to read, re-usable in other areas, and easily extended/overridden when required.

A large component

PageHeader.tsx

import React from 'react'
import styled from 'styled-components'
import {useMediaQuery} from '@material-ui/core'
import {breakpoints} from 'lib/ui/theme'
import Button from 'lib/ui/Button'
import {Title, Description} from 'lib/ui/typography'

export type PageHeaderProps = {
  disabled?: boolean
  title: string
  smTitle?: string
  buttonText: string
  smButtonText?: string
  description?: string
  'aria-label'?: string
  onClick?: () => void
}

export default function PageHeader(props: PageHeaderProps) {
  const type = props.onClick ? 'button' : 'submit'
  const matches = useMediaQuery(`(max-width: ${breakpoints.sm})`)
  const title = matches && props.smTitle ? props.smTitle : props.title
  const buttonText =
    matches && props.smButtonText ? props.smButtonText : props.buttonText

  const DescriptionBox = () => {
    if (props.description) {
      return (
        <StyledBox>
          <Description>{props.description}</Description>
        </StyledBox>
      )
    }

    return null
  }

  return (
    <Container>
      <MDFlexBox>
        <Title>{title}</Title>
        <Button
          type={type}
          variant="contained"
          color="success"
          aria-label={props['aria-label'] ? props['aria-label'] : 'submit'}
          disabled={props.disabled}
          onClick={props.onClick}
        >
          {buttonText}
        </Button>
      </MDFlexBox>
      <SMFlexBox>
        <Title>{props.smTitle ? props.smTitle : props.title}</Title>
        <Button
          type={type}
          variant="contained"
          color="success"
          aria-label={props['aria-label'] ? props['aria-label'] : 'submit'}
          disabled={props.disabled}
          onClick={props.onClick}
        >
          {props.smButtonText ? props.smButtonText : props.buttonText}
        </Button>
      </SMFlexBox>
      <DescriptionBox />
    </Container>
  )
}

Contains lots of behavior:

Header layout info
Title values for various widths
Button info
Conditionally rendering via a nested component
This approach has also had to duplicate the components to handle the different layouts. Duplication is generally bad, let's avoid it where we can.

We could say this component is very specific. It only renders a single layout, and pre-defined children. Any variations would either require:

Copy-pasting behavior
Adding new props, then using more ifs, or other logical operators to determine what to render/style.

Using PageHeader.tsx

<PageHeader
  onClick={save}
  disabled={processing}
  title="Add form"
  buttonText="Save Changes"
  smButtonText="Save"
  aria-label="save form"
/>

Not sure what is being clicked / disabled / label: button? title?
Results in many props with long names - buttonText, smButtonText
Need to go into , and scan a lot of code to find out when smButtonText is rendered.

Using smaller components

Let's start with how we'd like to use it.

<PageHeader>
  <Title text="Add form"/>
  <Button aria-label="save form" 
          onClick={save} 
          disabled={processing}
          text="Save Changes"
          textCollapsed="Save"
  />
</PageHeader>

<PageHeader> is only concerned with the layout
Clearer where each prop is applied.
If we're only interested in behavior, we'll only need to look at that component.
Smaller, clearer prop names.
We know the title will eventually need a textCollapsed too, so we'll just use a text prop to keep it consistent with the button

PageHeader/index.tsx

export default function PageHeader(props: {children: JSX.Element[]}) {
  return <Container>{props.children}</Container>
}

const Container = styled.div`
  display: flex;
  align-items: center;
  justify-content: space-between;
  margin-bottom: ${(props) => props.theme.spacing[21]} !important;

  @media (min-width: ${(props) => props.theme.breakpoints.sm}) {
    margin-bottom: ${(props) => props.theme.spacing[19]} !important;
  }
`

Only concerned with layout

PageHeader/Title.tsx

export default function Title(props: {text: string; textCollapsed?: string}) {
  const {text, textCollapsed} = props

  return (
    <>
      <DesktopTitle>{text}</DesktopTitle>
      <Include if={Boolean(textCollapsed)}>
        <MobileTitle>{textCollapsed}</MobileTitle>
      </Include>
    </>
  )
}

const DesktopTitle = DesktopOnly(TitleText)
const MobileTitle = MobileOnly(TitleText)

Only concerned with title related behavior
Not mixing style with rendering. Not using media query / breakpoints inside component body.

DesktopOnly/MobileOnly

Style utility component that wraps whatever component you pass in, so that it only shows at the given width.

export const DesktopOnly = (component: React.FC<any>) => styled(component)`
  display: none;

  @media screen and (min-width: ${(props) => props.theme.breakpoints.sm}) {
    display: block;
  }
`

Only concerned with showing/hiding at various breakpoints

PageHeader/Button.tsx

Similar to title, but we'll also extend the base <Button>, and set some default props.

export default function Button(
  props: Partial<ButtonProps> & {
    text: string
    textCollapsed?: string
  },
) {
  const {text, textCollapsed, ...buttonOverrides} = props

  const buttonProps: Partial<ButtonProps> = {
    variant: 'contained',
    color: 'success',
    ...buttonOverrides,
  }

  return (
    <>
      <DesktopButton {...buttonProps}>{text}</DesktopButton>
      <Include if={Boolean(textCollapsed)}>
        <MobileButton {...buttonProps}>{textCollapsed}</MobileButton>
      </Include>
    </>
  )
}

Props can still be overridden.
Clear what is rendered where, and when.

Setting up E2E Tests in Gitlab CI: Laravel + React + Cypress

Mike Wu — Wed, 09 Feb 2022 07:14:21 +0000

This is an overview of how we got our e2e cypress tests running for our Laravel backend, and React frontend. 🚀

Even if your stack is identical to ours, your environment may still slightly differ depending on versions, and providers. This post is only meant to serve as a guide, and not as a copy-paste solution.

Sections

.gitlab-ci.yml - Gitlab CI config
API Docker Image - Laravel app

TL;DR, Create a single Docker image for your Laravel App + webserver, and use it as a Gitlab service

Motivation

I've spent the last 2 days struggling to make this happen. Through a series of small undocumented wins, we finally reached that sweet ✅ pipeline. Seeing as I've had to piece together information from various sources, and travel back in time, I thought I'd summarize my findings here in case it helps anyone with a similar stack.

.gitlab-ci.yml

E2E Local Tests:
  image: cypress/browsers:node16.13.0-chrome95-ff94
  services:
  - mysql:5.7
  - name: registry.gitlab.com/your_project/api_ci:latest
    alias: api
  variables:
    # Create separate network, required for services to talk to each other
    # Reference: https://docs.gitlab.com/ee/ci/services/#connecting-services
    FF_NETWORK_PER_BUILD: 1
    MYSQL_DATABASE: myapp
    MYSQL_ROOT_PASSWORD: secret
    DB_USERNAME: root
    DB_DATABASE: myapp
    DB_PASSWORD: secret
    DB_HOST: mysql
    REACT_APP_API_URL: http://api:8000
  script:
    # Verify the api is up, and running (optional)
    - curl http://api:8000
    # Install npm packages, and start server in background
    - npm install
    - npm run start&
    - sleep 120 # Wait for server to be up
    - npm run e2e:local # run tests

Set FF_NETWORK_PER_BUILD to tell Gitlab to create a netowrk for our job. This is required if you want your services to talk to each other, ie., api, and db, which we do.
registry.gitlab.com/your_project/api_ci:latest would be your API Laravel app, bundled in a single docker image with your web-server. In our case it was our app + nginx (with php-fpm).
Aliased the API service to api
Make sure you set the DB_HOST to the service name as well, in this case mysql.
Tell React app the API url is now http://api:8000, where api is the alias we gave our service above.
Start react app with & to run in background.

API Docker Image - Laravel app

To get the API up, and running, 2 solutions came to mind:

Use git to pull in the project, and setup volume mounts + nginx service
Bundle everything together in a single Docker image

Option 2. is definitely the simpler option, so that's the one we went with.

Dockerfile

# Build
FROM php:7.4-fpm as build

# Install PHP dependencies to get Laravel up, and running
RUN apt-get update && apt-get install -y \
    git \
    curl \
    libpng-dev \
    libonig-dev \
    libxml2-dev \
    zip \
    unzip \
    libfreetype6-dev \
    libjpeg62-turbo-dev \
    libzip-dev \
    cron \
    openssh-client

# Install xdebug for code coverage
RUN pecl install xdebug \
  && docker-php-ext-enable xdebug

# Install PHP extensions
RUN docker-php-ext-configure gd --with-freetype=/usr/include/ --with-jpeg=/usr/include/
RUN docker-php-ext-install -j$(nproc) gd pdo_mysql zip bcmath pcntl

# Install Composer
COPY --from=composer:latest /usr/bin/composer /usr/bin/composer

# Where php-fpm expects the project files to live
WORKDIR /var/www

# FPM default user (www-data) must own the files,
# or we'll hit a permission error in Laravel
RUN chown -R www-data:www-data /var/www

# Include a docker-init.sh (optional)
COPY ./Docker/dev/docker-init.sh /usr/local/bin/docker-init.sh
RUN chmod +x /usr/local/bin/docker-init.sh

# Bake our entire project into the image
COPY . .


# Copy configs

COPY supervisord.conf /etc/supervisord.conf
COPY nginx-site.conf /etc/nginx/conf.d/default.conf

# Copy start script
COPY start.sh /start.sh
RUN chmod 755 /start.sh

# IMPORTANT - need to tell gitlab which port to check, otherwise it will timeout at 'waiting at services'
EXPOSE 8000

ENTRYPOINT [ "docker-init.sh" ]

CMD ["/start.sh"]

Installed nginx & supervisor to run the app.
Copied all files into the image.
docker-init.sh custom script that does prep stuff like run migrations, and seeders.
start.sh is the final docker command, in this case we're starting supervisor

Bonus: `docker-init.sh`

Here's where we init the app.

#!/bin/sh

# Exit if any fails
set -e

# Install dependencies / upgrade packages
composer install

# Clear cache/config to make sure env is read
php artisan route:clear
php artisan config:clear

# Migrate
php artisan migrate:refresh --seed

php artisan storage:link

# execute default entrypoint
docker-php-entrypoint $@

Next we have our start script, which is really only just starting supervisor.

`start.sh`

#!/bin/bash
# Start supervisord and services
exec /usr/bin/supervisord -n -c /etc/supervisord.conf

Build & Run

Once you've got your Dockerfile ready, build, and push it to your private Gitlab repository.

Note that the image name has to be the full URL of the repository.

Other Issues

App reading wrong ENV

If you find your API not reading the ENV set in either .gitlab-ci.yaml or the Dockerfile, it's because php-fpm aren't reading those values. Most likely because it was started by supervisor.

The fix is to make sure you use the same values in a .env file.

RxJS in a Single React Component (No Store/Redux)

Mike Wu — Tue, 31 Aug 2021 00:46:05 +0000

After you've got the basics of reactive programming down, the next question is usually 'ok great, so how do I use this thing?'. A quick search for using RxJS with React usually winds up at one of the following solutions:

A. Use Redux with redux-observable middleware.

B. Write your own store that's very similar to redux, but powered by RxJS.

While both are valid solutions, they don't really help if you're only looking to use RxJS in a single component/hook. You don't want a global store!

TL;DR

If you just want to see the hook, and an example here it is.

useObserve()

import {useEffect, useMemo, useState} from 'react'
import {Subject} from 'rxjs'

export function useObserve<T>(value: T) {
  const [ready, setReady] = useState(false)
  const subject = useMemo(() => new Subject<T>(), [])

  useEffect(() => {
    if (!ready) {
      return
    }

    subject.next(value)
  }, [value, ready, subject])

  const onReady = useMemo(() => {
    return ready ? null : () => setReady(true)
  }, [ready])

  return {value$: subject, onReady}
}

And here is an example of it in action:

export function usePriceForCredits(numCredits: number) {
  const [loading, setLoading] = useState(true)
  const [price, setPrice] = useState<number | null>(null)
  const {value$, onReady} = useObserve(numCredits)

  useEffect(() => {
    if (!onReady) {
      return
    }

    value$
      .pipe(
        tap(() => {
          setLoading(true)
          setPrice(null)
        }),
        debounceTime(1000),
        switchMap((numCredits: number) => {
          const url = api(`/price_for_credits?num_credits=${numCredits}`)

          const request = ajax.get(url, {
            'Content-Type': 'application/json', // Avoid rxjs from serializing data into [object, object]
          })

          return request
        }),
        map((res) => res.response.price),
        tap(() => {
          setLoading(false)
        }),
      )
      .subscribe({
        next: setPrice,
      })

    onReady()
  }, [value$, onReady, token])

  return {
    loading: loading,
    price: price,
  }
}

Breaking It Down

If you're curious about how I got to the above solution, let's keep going.

I'll be creating a custom hook that calculates the price given a number of credits:

The number of credits is updated via a slider.
If we fetched the price on every change we'd be sending way too many requests.
Want to debounce sending requests so we only send once after the user has stopped sliding.

A perfect case for some rx!

Creating the Observable

Here's our hook:

export function usePriceForCredits(numCredits: number) {
  // ...
}

We want to observer whenever numCredits changes. Let's manually send updated values whenever it changes.

Side note: redux-observable also uses Subject under the hood.

 function usePriceForCredits(numCredits: number) {
  const subject = useMemo(() => new Subject<number>(), [])

  useEffect(() => {
    if(!subject) {
      return
     }

     subject.next(numCredits)
  }, [numCredits, subject])
}

We wrap subject in a useMemo to avoid React creating new Subject on every render.
useEffect to handle when numCredits changes.
subject.next() sends a new value to the subject.

Writing the pipeline

Now on to the fun part! With our new observable (subject) we can write the actual pipeline that does the work.

 const [price, setPrice] = useState<number | null>(null)

  useEffect(() => {
    subject
      .pipe(
        tap(() => {
          setPrice(null)
        }),
        debounceTime(1000),
        switchMap((numCredits: number) => {
          const url = api(`/price_for_credits?num_credits=${numCredits}`)

          const request = ajax.get(url, {
            Authorization: `Bearer ${token}`,
            'Content-Type': 'application/json', // Avoid rxjs from serializing data into [object, object]
          })

          return request
        }),
        map((res) => res.response.price),
      )
      .subscribe({
        next: setPrice,
      })
  }, [subject, token])

Set in a useEffect to avoid subscribing on every render.
Use tap for side-effects
debounceTime(1000) - The debounce we needed!
switchMap() - returning an ajax observable that'll automatically cancel requests for us.
Finally, .subscribe({next: ...}) to kick off the subscription. In this example we're just setting the value via setPrice

A Bug!

Eagle-eyed readers might have spotted it, but there's actually a race-condition in the code above. The initial value is sent before the subscription is ready! This results in us always missing the first value.

In this example we'll need to fetch the price for the initial number of credits to so users don't start with a 0 price.

 const [ready, setReady] = useState(false)

  useEffect(() => {
    if (!ready) {
      return
    }
    subject.next(numCredits)
  }, [numCredits, subject, ready])


  useEffect(() => {
    if (ready) {
      return
    }

    subject
      .pipe(
        //... same as above
      )
      .subscribe(
        //... same as above
      )

   setReady(true)
  }, [subject, token])

Introduce a ready flag to know when to start sending values
Set ready to true only after pipeline is set.

React: When to use internal state vs. custom hook vs. render props vs. HOC

Mike Wu — Tue, 14 Jul 2020 11:45:06 +0000

As someone who picked up React after the introduction of hooks, one of the most confusing questions has been when/how to separate state.

Here's a decision table that helps me decide which technique to use.

Use	Internal State	Custom Hook	Render Prop	HOC
UI State	x
Non-UI State		x
Re-use layout			x
Duplicate components				x

UI State? Internal State

Things like toggle on/off, showing dialogs/modals. Use internal useState.

Not UI State? Custom Hook

Things like users, data handling logic. Lift these out of your component by creating a custom hook. It'll allow your components to only deal with render/view logic.

PSA: I don't recommend creating a custom hook for every Non-UI state related logic. Unless you like sifting through many similarly named files, and annoying your co-workers.

Re-using layout? Render Prop

An example of this would be a form layout that might be used to create multiple forms, but each with different child components.

Instead of duplicating the layout, using render props for each section can make for leaner components.

Duplicate components? Higher Order Component

Deciding between hooks, and HOCs is a little more nuanced, but one flag I use to consider HOCs is when I have:

2 (or more) components, rendering the same things, but with different internal hooks.

For example, recently I found myself with 2 sets of components:

<UrlOrders/> & <UserRestaurantOrders/>
<UrlLink/> & <UserRestaurantLink/>
<UrlEditorProvider/> & <UserRestaurantEditorProvider/>

Where the difference between each was that:

UrlComponent fetched a restaurant from a route param
UserRestaurantComponent fetch a restaurant for the authenticated user

Using HOCs allowed me to write it as:

<URLRestaurant>
    <Orders />
</URLRestaurant>

and

<UserRestaurant>
    <Orders />
</UserRestaurant>

Using the exact same Orders component, and reducing the number of overall components.

For a more in-depth comparison between Hooks, and HOCs, check out Eric Elliot's post on Medium.

Sounds good, how do I implement these?

There are plenty of excellent resources that will go into much more detail than I possibly could. Instead of repeating them, here are some that I really enjoyed:

Internal State: You're probably already doing this, if not, React docs are a good place to start.
Custom hooks: Check out Steve Kinney's course on Frontend Masters - State Management in React
Render props: React docs has a pretty clear example.
Higher Order Components: Kent C Dodd's Advanced React Patterns Workshop, or my post for doing it in Typescript.

Final warning: Use this post as a guide, I didn't cover all the reasons, and the ones I listed are not hard-rules. Do NOT blindly apply each technique, or you'll risk unnecessarily introducing complexity to your app. Start with internal state.

Use Vuex? Try this next!

Mike Wu — Sun, 17 May 2020 23:10:24 +0000

TL;DR, Define your mutation constant together with the function definition, and export both. Allows co-locating the constant with the function so you can cmd+click from inside a component, and see the implementation immediately.

Going by the Vuex documentation, to avoid string literals

this.$store.commit('setLoading', false)

is to define your constants in a separate file

mutation-types.js

export const SET_LOADING = 'setLoading'

MyComponent.vue

import { SET_LOADING } from './mutation-types'
this.$store.commit(SET_LOADING, false);

store.js

const store = new Vuex.Store({
  //...
  mutations: {
    [SET_LOADING] (state, val) {
       state.loading = val;
    }
  }
})

Anyone that has ever done this will realize pretty soon that you've lost the ability to cmd+click to see the function definition! What you end up at is at

export const SET_LOADING = 'setLoading'

And then usually selecting SET_LOADING, and doing a search in your IDE to get to your store. 💩

I've been writing Vue for around 4 years, and React daily for the last 2. If you've ever written action creators, for a React reducer, this should seem pretty familiar.

A better way would be to define your mutation in a separate file

mutations.js

export const SET_LOADING = 'setLoading'
export const setLoading = (state, val) => {
    state.loading = val;
}

You still have to make sure setLoading is the actual function name here, but now it's even easier to spot a typo!

And in your store you'd import both the constant and the function.

store.js

import {SET_LOADING, setLoading} from './mutations.js'
const store = new Vuex.Store({
  mutations: {
    [SET_LOADING]: setLoading
  }
})

Cool! Now you can avoid typing strings, and still cmd+click to see the mutation definition!

💰Bonus points

Storing the mutations in a separate file also allows breaking up the mutations according to usage, so user mutations can live at: src/user/state/mutations.js

💰💰Extra bonus points

If you've ever googled 'How to call a mutation from another mutation', you'll probably end up creating an action to dispatch multiple mutations. While this is perfectly valid, there are some cases where combining mutations makes more sense.

Now that all your mutations are just separate functions, you can just import and call other mutations as you like.

Combining multiple mutations will make them harder to debug. Consider why you're doing this, and whether you care if they happen in separate steps (use an action), or not (go ahead and combine them).


export const MOVE_ITEM = 'moveItem'
function moveItem(state, {oldIndex, newIndex}) {
   const item = state.items[oldIndex]
   deleteItem(state, oldIndex)
   addItem(state, {item, index: newIndex})
   /*
   * This is purely an example, actual implementation 
   * might need you to figure out the modified indexes.
   */
}

function addItem(state, {index, item}) {
   //...
}

function deleteItem(state, {index, item}) {
   //...
}

React vs. ❤️ Vue

React, and Vue might have some fundamental differences, but approaches in one can inspire cleaner code when working with the other.　

I've only recently started doing this, but it's made working with Vuex a better experience personally. If you hate this, and think I'm about to crash, and drown in a pile of spaghetti, please let me know asap!

Mapped Reducer Actions in TS

Mike Wu — Mon, 30 Mar 2020 15:18:04 +0000

You should have a working knowledge of react, reducers, and typescript to get the most out of this post. I wrote this before finding out about mapDispatchToProps. I still decided to post anyway in case someone not using Redux wanted to implement it themselves in TS.

The idea is to automatically bind a dispatch to a group of action creators.

So instead of manually dispatching:

import {createAddItemAction} from 'items/actions.ts'

const {dispatch} = useDispatch()
dispatch(createAddItemAction({position: 5}))

It'd be nicer to provide a method that already has dispatch in its scope:

const {addItem} = useEditor()
addItem({position: 5})

I'll be referring to such a method as a ~~mapped~~ built action.

You might also see them referred to as bound action creators, or mapped dispatch to props. Personally I prefer built actions, it implies they're all good to go.

Sounds simple enough, right? Something like this will do:

const addItem = dispatch => position => dispatch(createAddItemAction({position})

But What if we had multiple action creators, and we were passing these into a context value? A ton of repetition.

The rest of the examples will be in Typescript; if you can think of a better way to type the functions - let me know!

Binding multiple action creators

Starting with a standard action creator

item/actions.ts

export const REMOVE_ITEM = 'REMOVE_ITEM'
export interface RemoveItemAction {
  type: typeof REMOVE_ITEM
  category: Category
  position: number
}
const remove = (args: {in: Category; at: number}): RemoveItemAction => ({
  type: REMOVE_ITEM,
  category: args.in,
  position: args.at,
})

We'll also export a build function together with the actions that calls a withDispatch function

item/actions.ts


//... insert, and addNew action creators are also defined here

const remove = (args: {in: Category; at: number}): RemoveItemAction => ({
    //...
})

export const build = withDispatch({remove, insert, addNew})

withDispatch does most of the heavily lifting. Its job is to take an object of action creators, and return an object of built actions.

reducer.ts

// takes a bunch of actions ({remove, insert, addNew})
export function withDispatch<T extends ActionCreators>(actions: T) {
  return (dispatch: React.Dispatch<Action>): T => {
    const wrapped = {} as any
    return Object.entries(actions).reduce((acc, [key, createAction]) => {
      acc[key] = (...args: any[]) => dispatch(createAction(...args))
      return acc
    }, wrapped)
  }
}

And we'll define our action types too

reducer.ts

export type Action = CategoryAction | ItemAction | MenuAction

export interface ActionCreators {
  [prop: string]: (...args: any[]) => Action

Where the binding happens

We'll bind the dispatch where we use the reducer. I'm using it in a context provider here.

editor/state/index.ts

import {reducer, initialState} from 'menu/editor/state/reducer'
import {build as buildItemActions} from './item/actions'

type EditorContextValue = typeof initialState & {
  item: ReturnType<typeof buildItemActions>
}

const EditorContext = createContext(
  (undefined as unknown) as EditorContextValue,
)

export function EditorProvider(props: {children: ReactNode}) {
  const [state, dispatch] = useReducer(reducer, initialState)

  return (
    <EditorContext.Provider
      value={{
        ...state,
        item: buildItemActions(dispatch)
      }}
    >
      {props.children}
    </EditorContext.Provider>
  )
}

Don't combine everything into a single context like this by the way, it will trigger unnecessary re-renders. See the solution on Github.

Sending the action

Finally, in our component we can just send the action


import {useEditor} from './state'

export default function MenuEditor(props: {restaurantId: number}) {
  const {
    item,
    categories
  } = useEditor()

  const category = category[0]
  item.remove({in: category, at: 2}  // Calling our built action

  //...
}

Did I just re-invent the wheel? Sure did, but it's your wheel now too, enjoy!

Compound Components, and Implicit Prop Binding in TS

Mike Wu — Mon, 30 Mar 2020 14:57:38 +0000

You should have working knowledge of React, and Typescript to get the most out of this post.

So recently learning about compound components, and the ability to pass props ~~implicitly~~ magically to child components, I really wanted to try it out. Here's an example of an unnecessary use-case for both.

TL;DR: Compound components are no fun in TS, and if you're not sharing state between child components, or rendering elements, think about using a custom hook instead.

Alright so I had a component that was getting route params from React Router, and I wanted to do something like this:

export default function MenuEditor() {
  const {restaurant_id} = useParams()

  const history = useHistory()
  if (restaurant_id === undefined) {
     history.push('/restaurants')
     return null // <--- Nope!
  }

  const restaurantId = parseInt(restaurant_id)
  const {fetch} = useMenu()
  fetch(restaurantId)
}

But React won't let you do that right? Conditional hooks and all that. useEffect saves the day:

export default function MenuEditor() {
  const {restaurant_id} = useParams()
  const history = useHistory()
  const {fetch} = useMenu()

  useEffect(() => {
    if (restaurant_id === undefined) {
      history.push('/restaurants')
      return
    }

    const restaurantId = parseInt(restaurant_id)
    fetch(restaurantId).then(...update state).catch(...handle error)
  }, [history, restaurant_id])

  //... do more stuff
}

Cool and that worked but it didn't feel right. Why should the menu editor have to know where to redirect, right? But I couldn't think of anything better at the time, so I moved on.

Fast-forward to me learning about compound components, and wanting to see if it's the solution to all my problems, and here we are.

Before compound component

<Route path="/restaurant/:restaurant_id/menu/editor">
  <MenuEditor />
</Route>

After compound component

<Route path="/restaurant/:restaurant_id/menu/editor">
  <Restaurant>
    <MenuEditor />
  </Restaurant>
</Route>

Disappointed yet? Don't be. You'll have plenty of chance later, check out the menu editor now:

export default function MenuEditor({restaurantId}) {
  const {fetch} = useMenu()
  fetch(restaurantId).then(...update state).catch(...handle error)
}

See it? Yep, it received restaurantId as a prop even though we never passed it in. And guess where it lives? In the Restaurant (parent) component! It's called implicit prop binding, and it's pretty neat.

So figuring how to do this in Typescript took longer than I care to admit. Hint: You need to know the difference between ReactNode and ReactElement.

If you've got a better way to do this without lying to the compiler, I'd love to know.

interface RestaurantChild {
  restaurantId: number
}

export default function Restaurant(props: {children: React.ReactNode}) {
  const {restaurant_id} = useParams()
  const history = useHistory()

  // Redirect logic is now in a much better place
  if (restaurant_id === undefined) {
    history.push('/restaurants')
    return null // Don't render children
  }

  const restaurantId = parseInt(restaurant_id)

  const childrenWithProps = React.Children.map(props.children, (child) => {
    // This is absolutely required TS
    if (!React.isValidElement<RestaurantChild>(child)) {
      return child
    }

    return React.cloneElement(child, {
      restaurantId,
    })
  })

  // ...and this is also required TS
  return <>{childrenWithProps}</>
}

But we're not done

Unfortunately we'll have to turn restaurantId into an optional prop to keep TS happy. Typescript is starting to feel like a one-sided relationship.

export default function MenuEditor(props: {restaurantId?: number}) {
   if(!resturantId) {
     throw new Error( `Missing 'restaurantId'; MenuEditor must be rendered inside a Restaurant.`)
   }

   // 🍔🍔🍔🍔🍔🍔🍔🍔🍔🍔🍔🍔🍔🍔🍔🍔🍔
}

And now we're done. Let's recap:

Better separation of concern? ✅
Reduce repetition? ❌
Easier to debug? ❌
Required for shared state? ❌

So that's a 3:1 ❌ ratio which makes me think I might just re-write this with an explicit useRestaurant() hook instead. Be right back.