DEV Community: Anton Gunnarsson

Building flexible and expressive React components

Anton Gunnarsson — Wed, 10 Mar 2021 13:59:16 +0000

Sometimes you find yourself in a situation where you need to build a component that is reusable but also very flexible so it can adapt to a myriad of situations. It could be something like a toggle, tabbed navigation, or an accordion. A pattern that I think is fantastic for solving these problems is compound components. That is when you have multiple components working together in a coupled but flexible way.

Let's look at how we could build this accordion as a compound component:

You can find an interactive version of this article with some extracurricular information over here.

This accordion consists of three components: One for the toggling button, one for the collapsible content, and one parent that ties everything together. Here's how it looks when using it:

<Accordion>
  <div>
    <Accordion.Toggle eventKey="item1">Item 1</Accordion.Toggle>
    <Accordion.Content eventKey="item1">Content 1...</Accordion.Content>
  </div>
  <div>
    <Accordion.Toggle eventKey="item2">Item 2</Accordion.Toggle>
    <Accordion.Content eventKey="item2">Content 2...</Accordion.Content>
  </div>
  <div>
    <Accordion.Toggle eventKey="item3">Item 3</Accordion.Toggle>
    <Accordion.Content eventKey="item3">Content 3...</Accordion.Content>
  </div>
</Accordion>

There's a couple of things to note here. First off <Accordion.Toggle> and <Accordion.Content> might look a little weird with it if you haven't seen it before, but it is because the <Toggle> and <Content> components are added as static properties on <Accordion>. This is not a requirement in any way but I think it makes it clearer that we are dealing with tightly coupled components intended to be used together.

If you've ever used Reach UI or React Bootstrap this probably looks familiar to you. They use this pattern for accordions and other components.

Secondly neither the <Toggle> and <Content> components are direct children of <Accordion>. This is possible because we use a Context to pass data between our components, which gives us a lot of flexibility in how we want our accordion to look and work.

Here is how the parent component <Accordion> is implemented:

const AccordionContext = React.createContext()

function Accordion({ children }) {
  const [activeKey, setActiveKey] = useState(null)

  const setKey = (newKey) => {
    if (newKey === activeKey) setActiveKey(null)
    else setActiveKey(newKey)
  }

  return <AccordionContext.Provider value={{ activeKey, setKey }}>{children}</AccordionContext.Provider>
}

There's a bit to unpack here so let's start at the top. We create a context called AccordionContext that will be used to connect our components. Then we set up some state, activeKey, to hold the currently open "tab"s key and create a function that updates our state to open/close the accordion. Lastly, we return the component's children wrapped in our contexts <Provider> which value we set to an object with activeKey and setKey.

With that set up we can take a look at <Content> where the implementation looks like this:

function Content({ children, eventKey }) {
  const { activeKey } = useContext(AccordionContext)

  if (activeKey !== eventKey) return null

  return children
}

We get activeKey from the AccordionContext and if it doesn't match the prop eventKey we return null, otherwise we return children.

Finally, this is how <Toggle> looks:

function Toggle({ children, eventKey }) {
  const { setKey } = useContext(AccordionContext)

  return <button onClick={() => setKey(eventKey)}>{children}</button>
}

Here we grab setKey from our AccordionContext and when the user clicks the button we call it with the toggles eventKey as its only argument.

And with that our accordion is complete! You can find the complete implementation here.

So to recap: By splitting the implementation across multiple components that share an implicit state using Context we've created a more expressive and flexible API for our accordion. If we suddenly decide we want to have the accordion buttons below the content we only need to change the usage and not the implementation. This is one of the biggest benefits of compound components.

Hopefully this has given you some insight into why and when compound components are useful. I think it should be a tool in every React developers toolbox.

You're more than welcome to hit me up on Twitter if you have any suggestions or feedback!

Thanks for reading!

DO Hackathon Runner game submission (DevLog #3)

Anton Gunnarsson — Sun, 10 Jan 2021 23:14:24 +0000

What I built

A platformer game featuring top lists and passive multiplayer.

Category Submission:

Random Roulette

App Link

https://hackathon-runner-cztm4.ondigitalocean.app/

Screenshots

Description

HACKATHON RUNNER is small platform game built with React, Phaser3, NestJS, Postgres and Redis. Basic at its core it features game play mechanics such as collectible gems, bouncing pads, water, wind, keys and doors. It also has top lists over who can complete the level the quickest with different amount of completion.

The most technically interesting feature however is its passive multiplayer which means that when you play you can see every other player who are playing at the same time. They can't affect your game but maybe you'll find inspiration for a quicker path to get on that top list.

Link to Source Code

https://github.com/anton-g/hackathon-runner
(I tried adding the "Deploy to DO"-button but seems it doesn't work for my app with these limits?)

Permissive License

MIT

Background

I wanted to build something for this hackathon but had zero ideas so I started playing around with Phaser and suddenly inspiration came, which then turned into this. I expand a bit more on this in a previous post.

How I built it

The game consists of four components: The game client, the server, a Postgres database and an Redis instance.

The game client is built with React and uses Phaser3 as its game engine. I had never used Phaser before this project and found it surprisingly easy to get something up and running. There's so much resources in the development community that I rarely ran into an issue that I got stuck on. It's hosted as a static page on DO since that is just what it is. All communication with the server is done with WebSockets and REST calls.

The server in itself is built with Node and the NestJS which I think it's fantastic. It comes with a lot of out of the box functionality for building APIs, setting up web sockets and communicating with databases. It's hosted as a Web Service on DO.

Finally I used a Postgres Dev Database for persisting the top lists and then a Redis instance to support horizontal scaling without segmenting the passive multiplayer in the game.

I found that specifying the entire app in the App Specification worked really well. Previously when I've built similar things there's always been a hassle to handle environment variables but with the bindable variables it worked like a charm. The only thing I ran into was that I didn't realise I had to create a Redis DB cluster manually since it couldn't be done with the doctl CLI, but other than that: 👏👏👏

Additional Resources/Info

Building this wouldn't have been possible without a lot of things, including the incredible community that we developers have around us. I've probably missed something below, but here's a lot of resources I've used:

ReactJS
Phaser3
NestJS
Socket.IO
Tiled - Map editor
KenneyNL - Free graphics
Atlas Packer - Tool to create sprite atlases
tile-extruder - Tool that fixed an annoying bug with some sprites
Snapshot Interpolation - Library that assists with "snapshot interpolation", a technique to reduce lag in multiplayer games.
Phaser3 and Tiled tutorial

DO Hackathon Runner DevLog #2

Anton Gunnarsson — Fri, 08 Jan 2021 19:38:00 +0000

I've been toying away at my small game for the DigitalOcean hackathon but promptly forgot to add another post to this series so here we go!

Since the first post in the series I've worked on a lot of stuff, but let's focus on the actual game for now. Some of the new stuff includes:

Collectible gems
Bouncy pads
Water
Keys and locked doors
Wind from fans
An actual goal :D

It's been a lot of fun and easier than I anticipated to implement. I doubt I'll ever build a large scale game in the future but if I did the Phaser3 engine seems like a good choice!

I also added React to add some better styling around the game but mainly to support a few other ideas I have.

https://hackathon-runner-v2-hahqf.ondigitalocean.app

Next up I wanna take advantage of the DO App Platform some more, so I'm looking into adding top lists or similar features. Feels exciting!

DO Hackathon Runner DevLog #1

Anton Gunnarsson — Thu, 17 Dec 2020 16:33:55 +0000

Last Saturday, just as the DigitalOcean Hackathon had been announced, we hosted a remote hackathon at my company. I had already been thinking about building something for the DO hackathon but couldn't for the life of me come up with an idea that ✨sparked joy✨, so the short 8hr hack on Saturday felt like the perfect breeding ground for some ideas to sprout.

As Saturday morning came I toyed with a couple of different ideas for projects that could utilize the App Platform but I didn't really get that big light bulb moment that you're looking for. Instead, I started fiddling with the JavaScript game engine Phaser3 as a way to do something else for a while. I've wanted to try and build a game in JS for a while but have never gotten around to finishing anything, always becoming frustrated by tooling, me not understanding something, or running into a dreaded m a t h problem 😱

It's moments like these I appreciate the open and supportive community around software development. There are so many resources available for free which without I never would have gotten anywhere at all. To mention a few I used this starter project that helps set up Webpack for Phaser3, this tutorial on building a platformer with Tiled, a free tileset from KenneyNL and tools like sporadic-labs/tile-extruder for issues I ran into.

I won't say I wasn't frustrated (especially when I decided mid through to convert everything to TypeScript because I'm just dumb 😅), but with the motivation that comes with talking with other hackathon participants about our projects, I powered through.

And finally, much to many of my colleagues' surprise I managed to scrape together a sort of functioning game! 🎉 It wasn't a game with a lot of features or very fancy graphics but it works, and I made it!

Without much further ado, here's a very bare-bones version of a game:

https://hackathon-runner-v1-emb3n.ondigitalocean.app

(Control with arrow keys)

At the beginning of this, I didn't have any ideas at all, but after just going with something I'm now at a point where I have so many ideas I want to add to the game. Some of which I've already started working on, but that's for the next post in this series! 🙌

7 code smells in your React components

Anton Gunnarsson — Mon, 09 Nov 2020 20:37:41 +0000

A growing collection of things I consider code smells in React components.

Too many props
Incompatible props
Copying props into state
Returning JSX from functions
Multiple booleans for state
Too many useState in a component
Large useEffect

Too many props

Passing too many props into a single component may be a sign that the component should be split up.

How many are too many you ask? Well.. "it depends". You might find yourself in a situation where a component have 20 props or more, and still be satisfied that it only does one thing. But when you do stumble upon a component that has many props or you get the urge to add just one more to the already long list of props there's a couple of things to consider:

Is this component doing multiple things?

Like functions, components should do one thing well so it's always good to check if it's possible to split the component into multiple smaller components. For example if the component has incompatible props or returns JSX from functions.

Could I use composition?

A pattern that is very good but often overlooked is to compose components instead of handling all logic inside just one. Let's say we have a component that handles a user application to some organization:

<ApplicationForm
  user={userData}
  organization={organizationData}
  categories={categoriesData}
  locations={locationsData}
  onSubmit={handleSubmit}
  onCancel={handleCancel}
  ...
/>

Looking at the props of this component we can see that all of them are related to what the component does, but there's still room to improve this by moving some of the components responsibility to its children instead:

<ApplicationForm onSubmit={handleSubmit} onCancel={handleCancel}>
  <ApplicationUserForm user={userData} />
  <ApplicationOrganizationForm organization={organizationData} />
  <ApplicationCategoryForm categories={categoriesData} />
  <ApplicationLocationsForm locations={locationsData} />
</ApplicationForm>

Now we've made sure that the ApplicationForm only handles its most narrow responsibility, submitting and canceling the form. The child components can handle everything related to their part of the bigger picture. This is also a great opportunity to use React Context for the communication between the children and their parent.

Am I passing down many 'configuration'-props?

In some cases, it's a good idea to group together props into an options object, for example to make it easier to swap this configuration. If we have a component that displays some sort of grid or table:

<Grid
  data={gridData}
  pagination={false}
  autoSize={true}
  enableSort={true}
  sortOrder="desc"
  disableSelection={true}
  infiniteScroll={true}
  ...
/>

All of these props except data could be considered configuration. In cases like this it's sometimes a good idea to change the Grid so that it accepts an options prop instead.

const options = {
  pagination: false,
  autoSize: true,
  enableSort: true,
  sortOrder: 'desc',
  disableSelection: true,
  infiniteScroll: true,
  ...
}

<Grid
  data={gridData}
  options={options}
/>

This also means that it's easier to exclude configuration options we don't want to use if we're swapping between different options.

Incompatible props

Avoid passing props that are incompatible with each other.

For instance, we might start by creating a common <Input /> component that is intended to just handle text, but after a while we also add the possibility to use it for phone numbers as well. The implementation could look something like this:

function Input({ value, isPhoneNumberInput, autoCapitalize }) {
  if (autoCapitalize) capitalize(value)

  return <input value={value} type={isPhoneNumberInput ? 'tel' : 'text'} />
}

The problem with this is that the props isPhoneNumberInput and autoCapitalize don't make sense together. We can't really capitalize phone numbers.

In this case the solution is probably to break the component up into multiple smaller components. If we still have some logic we want to share between them, we can move it to a custom hook:

function TextInput({ value, autoCapitalize }) {
  if (autoCapitalize) capitalize(value)
  useSharedInputLogic()

  return <input value={value} type="text" />
}

function PhoneNumberInput({ value }) {
  useSharedInputLogic()

  return <input value={value} type="tel" />
}

While this example is a bit contrived, finding props that are incompatible with each other is usually a good indication that you should check if the component needs to be broken apart.

Copying props into state

Don't stop the data flow by copying props into state.

Consider this component:

function Button({ text }) {
  const [buttonText] = useState(text)

  return <button>{buttonText}</button>
}

By passing the text prop as the initial value of useState the component now practically ignores all updated values of text. If the text prop was updated the component would still render its first value. For most props this is unexpected behavior which in turn makes the component more bug-prone.

A more practical example of this happening is when we want to derive some new value from a prop and especially if this requires some slow calculation. In the example below, we run the slowlyFormatText function to format our text-prop, which takes a lot of time to execute.

function Button({ text }) {
  const [formattedText] = useState(() => slowlyFormatText(text))

  return <button>{formattedText}</button>
}

By putting it into state we've solved the issue that it will rerun unnecessarily but like above we've also stopped the component from updating. A better way to solving this issue is using the useMemo hook to memoize the result:

function Button({ text }) {
  const formattedText = useMemo(() => slowlyFormatText(text), [text])

  return <button>{formattedText}</button>
}

Now slowlyFormatText only runs when text changes and we haven't stopped the component from updating.

Sometimes we do need a prop where all updates to it are ignored, e.g. a color picker where we need the option to set an initially picked color but when the user has picked a color we don't want an update to override the users choice. In this case it's totally fine to copy the prop into state, but to indicate this behavior to the user most developers prefix the prop with either initial or default (initialColor/defaultColor).

Further reading: Writing resilient components by Dan Abramov.

Returning JSX from functions

Don't return JSX from functions inside a component.

This is a pattern that has largely disappeared when function components became more popular, but I still run into it from time to time. Just to give an example of what I mean:

function Component() {
  const topSection = () => {
    return (
      <header>
        <h1>Component header</h1>
      </header>
    )
  }

  const middleSection = () => {
    return (
      <main>
        <p>Some text</p>
      </main>
    )
  }

  const bottomSection = () => {
    return (
      <footer>
        <p>Some footer text</p>
      </footer>
    )
  }

  return (
    <div>
      {topSection()}
      {middleSection()}
      {bottomSection()}
    </div>
  )
}

While this might feel okay at first it makes it hard to reason about the code, discourages good patterns, and should be avoided. To solve it I either inline the JSX because a large return isn't that big of a problem, but more often this is a reason to break these sections into separate components instead.

Remember that just because you create a new component you don't have to move it to a new file as well. Sometimes it makes sense to keep multiple components in the same file if they are tightly coupled.

Multiple booleans for state

Avoid using multiple booleans to represent a components state.

When writing a component and subsequently extending the functionality of the component it's easy to end up in a situation where you have multiple booleans to indicate which state the component is in. For a small component that does a web request when you click a button you might have something like this:

function Component() {
  const [isLoading, setIsLoading] = useState(false)
  const [isFinished, setIsFinished] = useState(false)
  const [hasError, setHasError] = useState(false)

  const fetchSomething = () => {
    setIsLoading(true)

    fetch(url)
      .then(() => {
        setIsLoading(false)
        setIsFinished(true)
      })
      .catch(() => {
        setHasError(true)
      })
  }

  if (isLoading) return <Loader />
  if (hasError) return <Error />
  if (isFinished) return <Success />

  return <button onClick={fetchSomething} />
}

When the button is clicked we set isLoading to true and do a web request with fetch. If the request is successful we set isLoading to false and isFinished to true and otherwise set hasError to true if there was an error.

While this technically works fine it's hard to reason about what state the component is in and it's more error-prone than alternatives. We could also end up in an "impossible state", such as if we accidentally set both isLoading and isFinished to true at the same time.

A better way to handle this is to manage the state with an "enum" instead. In other languages enums are a way to define a variable that is only allowed to be set to a predefined collection of constant values, and while enums don't technically exist in Javascript we can use a string as an enum and still get a lot of benefits:

function Component() {
  const [state, setState] = useState('idle')

  const fetchSomething = () => {
    setState('loading')

    fetch(url)
      .then(() => {
        setState('finished')
      })
      .catch(() => {
        setState('error')
      })
  }

  if (state === 'loading') return <Loader />
  if (state === 'error') return <Error />
  if (state === 'finished') return <Success />

  return <button onClick={fetchSomething} />
}

By doing it this way we've removed the possibility for impossible states and made it much easier to reason about this component. Finally, if you're using some sort of type system like TypeScript it's even better since you can specify the possible states:

const [state, setState] = useState<'idle' | 'loading' | 'error' | 'finished'>('idle')

Too many useState

Avoid using too many useState hooks in the same component.

A component with many useState hooks is likely doing Too Many Things™️ and probably a good candidate for breaking into multiple components, but there are also some complex cases where we need to manage some complex state in a single component.

Here's an example of how some state and a couple of functions in an autocomplete input component could look like:

function AutocompleteInput() {
  const [isOpen, setIsOpen] = useState(false)
  const [inputValue, setInputValue] = useState('')
  const [items, setItems] = useState([])
  const [selectedItem, setSelectedItem] = useState(null)
  const [activeIndex, setActiveIndex] = useState(-1)

  const reset = () => {
    setIsOpen(false)
    setInputValue('')
    setItems([])
    setSelectedItem(null)
    setActiveIndex(-1)
  }

  const selectItem = (item) => {
    setIsOpen(false)
    setInputValue(item.name)
    setSelectedItem(item)
  }

  ...
}

We have a reset function that resets all of the state and a selectItem function that updates some of our state. These functions both have to use quite a few state setters from all of our useStates to do their intended task. Now imagine that we have a lot of more actions that have to update the state and it's easy to see that this becomes hard to keep bug free in the long run. In these cases it can be beneficial to manage our state with a useReducer hook instead:

const initialState = {
  isOpen: false,
  inputValue: "",
  items: [],
  selectedItem: null,
  activeIndex: -1
}
function reducer(state, action) {
  switch (action.type) {
    case "reset":
      return {
        ...initialState
      }
    case "selectItem":
      return {
        ...state,
        isOpen: false,
        inputValue: action.payload.name,
        selectedItem: action.payload
      }
    default:
      throw Error()
  }
}

function AutocompleteInput() {
  const [state, dispatch] = useReducer(reducer, initialState)

  const reset = () => {
    dispatch({ type: 'reset' })
  }

  const selectItem = (item) => {
    dispatch({ type: 'selectItem', payload: item })
  }

  ...
}

By using a reducer we've encapsulated the logic for managing our state and moved the complexity out of our component. This makes it much easier to understand what is going on now that we can think about our state and our component separately.

Both useState and useReducer come with their pros, cons and different use cases (pun intended). One of my favorites with reducers is the state reducer pattern by Kent C. Dodds.

Large useEffect

Avoid large useEffects that do multiple things. They make your code error-prone and harder to reason about.

A mistake that I made a lot when hooks were released was putting too many things into a single useEffect. To illustrate, here's a component with a single useEffect:

function Post({ id, unlisted }) {
  ...

  useEffect(() => {
    fetch(`/posts/${id}`).then(/* do something */)

    setVisibility(unlisted)
  }, [id, unlisted])

  ...
}

While this effect isn't that large it still do multiple things. When the unlisted prop changes we will fetch the post even if id hasn't changed.

To catch errors like this I try to describe the effects I write by saying "when [dependencies] change do this" to myself. Applying that to the effect above we get "when id or unlisted changes, fetch the post and update visibility". If this sentence contains the words "or" or "and" it usually points to a problem.

Breaking this effect up into two effects instead:

function Post({ id, unlisted }) {
  ...

  useEffect(() => { // when id changes fetch the post
    fetch(`/posts/${id}`).then(/* ... */)
  }, [id])

  useEffect(() => { // when unlisted changes update visibility
    setVisibility(unlisted)
  }, [unlisted])

  ...
}

By doing this we've reduced the complexity of our component, made it easier to reason about and lowered the risk of creating bugs.

Wrapping up

All right, that's all for now! Remember that these by any means aren't rules but rather signs that something might be "wrong". You'll definitely run into situations where you want to do some of the things above for good reason.

Got any feedback on why I'm very wrong about this? Suggestions for other code smells that you've stumbled upon in your components? Write a comment or hit me up on Twitter!

React component code smells: Incompatible props

Anton Gunnarsson — Sun, 23 Aug 2020 13:50:39 +0000

I've started researching and writing about code smells in React components, and one of the most common ones I've come across is having incompatible props on the same component.

Read full article here

Troubleshooting NodeJS memory leaks with node-memwatch

Anton Gunnarsson — Mon, 01 Jun 2020 19:26:33 +0000

I recently released my social drawing game draw.wtf where you compete against each other by drawing things and getting judged by a machine learning model. While I've gotten a lot of positive feedback since I released it, I also quickly discovered that something was wrong. The backend for the game is written in Nest (node) and hosted on Heroku (which I can really recommend, their free tier is great for passion projects). But looking at the memory usage in the metrics overview I could clearly see that things we're not alright:

There was no way that my game would use this much memory so it was clear that I had a memory leak.

A memory leak is when an application uses memory (RAM) without eventually releasing it. Most modern (high level) programming languages today implement some sort of automatic cleanup of unused memory and Node uses something called a "garbage collector". For the sake of this debugging story that's all you need to know!

Back to the issue in draw.wtf! I have almost only worked in languages with garbage collection so starting to troubleshoot this issue I had no experience with finding memory leaks. My first thought was just to skim the code and find the issue buuut to no avail. I had no idea where in the code the bug might live, and since we don't do any manual handling of memory there shouldn't exist any bugs! :(

The next step was to reach for the most common tool in every developers toolbox: Google!

I read a lot of articles on finding memory issues in node, but none that led me close to a solution. Finally I found an article that recommended the library node-memwatch which looked promising! Unfortunately it hasn't been updated for 7 years...

Open source to the rescue! 🚀

Looking at the forks of node-memwatch we can try finding one that is still maintained, and after looking through a couple I ended up with this fork from AirBnB.

Heading back into the code I started by testing the librarys heap diffing by running new memwatch.HeapDiff(); and heapDiff.end(); which outputs before and after memory usage. And sure enough, I can see the memory grow with about 2mb for every round played in the game.

One thing I did discover when testing this was that the memory did not grow when I didn't draw anything! 🤔 This was really great since it narrowed down where in the code the issue is. With this knowledge I moved the heap diffing functions to a couple of different places where drawn lines are handled, and THIS led me to the function that was leaking memory: calculating scores.

To calculate the scores I have a machine learning model trained with Azure Custom Vision and then runs it locally with TensorFlow. Here is the implementation of this calculation function, with the memory leak issue intact:

async function calculate(pixels) {
  const inputs =
    pixels instanceof tf.Tensor
      ? pixels
      : this._preprocess(tf.browser.fromPixels(pixels, 3))

  const outputs = await this.model.execute(inputs, null)

  const arrays = !Array.isArray(outputs)
    ? await outputs.array()
    : Promise.all(outputs.map(t => t.array()))

  const result = Array.isArray(arrays[0])
    ? arrays[0].map((x, i) => ({ probability: x, tag: this.tags[i] }))
    : []

  return result
}

Do you see the issue? (It's not in the _preprocess function).

I sure didn't, no matter how much I looked at this code so next up I dived into the TensorFlow.js documentation where I found this little nugget of wisdom:

"When using the WebGL backend, tf.Tensor memory must be managed explicitly (it is not sufficient to let a tf.Tensor go out of scope for its memory to be released)."

Aaah, the solution! With that it wasn't very hard to read some more documentation and end up with a score calculation that works:

async function calculate(pixels) {
  const inputs = tf.tidy(() => {
    return pixels instanceof tf.Tensor
      ? pixels
      : this._preprocess(tf.browser.fromPixels(pixels, 3))
  })

  const outputs = await this.model.execute(inputs, null)

  const arrays = !Array.isArray(outputs)
    ? await outputs.array()
    : Promise.all(outputs.map(t => t.array()))

  const result = Array.isArray(arrays[0])
    ? arrays[0].map((x, i) => ({ probability: x, tag: this.tags[i] }))
    : []

  inputs.dispose()
  Array.isArray(outputs) ? outputs.forEach(o => o.dispose()) : outputs.dispose()

  return result
}

tf.tidy() automatically disposes of any tf.Tensor created within, and then I manually run dispose() on any tensor I have to create outside of it. And that's it! Now the memory isn't leaking any more:

To finish this up, if you're gonna take anything with you from this post I think it should be that node-memwatch is a pretty nice tool for troubleshooting memory issues. If there is something you should not take with you, it's probably the code samples. I have no idea if they're good, bad or ugly 😅

Would you have solved it another way? Let me know in the comments!

Render props in the Age of Hooks

Anton Gunnarsson — Mon, 18 May 2020 06:12:32 +0000

Through the years many different patterns have emerged to solve problems we encounter writing React components. One of the most popular patterns ever is the render prop-pattern.

You can read the original, interactive version of this post here.

In this post, we'll walk through what render props are, what the implementation looks like, and how they fit into the React landscape now that we live in the Golden Age of Hooks. Let's get started!

If you know what render props are but are curious about its current use cases, feel free to skip ahead!

So what is a render prop?

In theory, a render prop is a way to share common functionality. It follows a principle called "Inversion of Control" which is a way to move control from the abstraction to the user of said abstraction.

Wait.. what?

Yeah, I know. Let's take a look at a very simplified example instead of talking theory.

This is a small component that renders a button and when you click that button you increase the count by one:

export default function Counter() {
  const [count, setCount] = useState(0)

  return (
    <div>
      <h1>Counter</h1>
      <button onClick={() => setCount(c => c + 1)}>Increase count</button>
      <p>{count}</p>
    </div>
  )
}

Now, for the sake of the example let's say we want to give the user more control of how the number is displayed. The first thought might be to add a prop to the component to add some styling. That would work if we just wanna change the styling, but what if we run into a situation where we also want to wrap the count in some text? While we could add another prop for this it's also a perfect time to try using a render prop.

Imagining we want to add some styling and then display the count like "The count is X!" we can move this control to the consumer of the component by refactoring our component to this:

export default function Counter({ renderCount }) {
  const [count, setCount] = useState(0)

  return (
    <div>
      <h1>Counter</h1>
      <button onClick={() => setCount(c => c + 1)}>Increase count</button>
      <p>{renderCount(count)}</p>
    </div>
  )
}

Now our component receives a prop called renderCount which we expect to be a function. We then invoke this function passing it the current count.

And here is how we now use this component:

<Counter renderCount={count => <span>The count is {count}!</span>} />

We pass in the renderCount prop as an arrow function that receives the count and returns a span with our desired text.

By doing this we've inverted the control of rendering the count from the component itself to the consumer of the component.

Note that the prop renderCount could be called anything.

Function as children

Before moving on to why render props aren't as widely used anymore and in which cases they might still be relevant, I just want to mention the concept of function as children. While React doesn't support passing a function as a child of a component and rendering it, you can use it together with render props since children are just a prop.

Refactoring our component once again we end up with this:

export default function Counter({ children }) {
  const [count, setCount] = useState(0)

  return (
    <div>
      <h1>Counter</h1>
      <button onClick={() => setCount(c => c + 1)}>Increase count</button>
      <p>{children(count)}</p>
    </div>
  )
}

This looks very similar to before, we've just removed our custom prop and now uses the reserved children prop instead and hence we pass the function down as the child:

<Counter>{count => <span>The count is {count}!</span>}</Counter>

I had a really hard time wrapping my head around this syntax when I first learned about render props, but it's also the most popular way of using them so it's likely you'll encounter it too.

In reality, it's more likely you'll encounter components that use render props to handle tracking mouse movement, scrolling or similar things.

Drawbacks

While render props might sound great there are a couple of issues that I want to talk about.

One problem is that when you get to a point where you need to use multiple components with a render prop api you could end up in what you might recognize as "the pyramid of death". Below is an example where we have a component that needs access to its measured size, the scroll position, mouse position, and some styling for animation purposes:

<Mouse>
  {mouse => (
    <Scroll>
      {scroll => (
        <Motion>
          {style => (
            <Measure>
              {size => (
                <ConsumingComponent
                  mouse={mouse}
                  scroll={scroll}
                  style={style}
                  size={size}
                ></ConsumingComponent>
              )}
            </Measure>
          )}
        </Motion>
      )}
    </Scroll>
  )}
</Mouse>

Comparing this to a pseudo-code version using Hooks you can see why a lot of people prefer Hooks:

const mouse = useMouse()
const scroll = useScroll()
const style = useMotion()
const size = useMeasure()

return (
  <ConsumingComponent mouse={mouse} scroll={scroll} style={style} size={size} />
)

Another thing that this example illustrates is that we get a much clearer separation between rendering and preparing to render. In the render prop-example we don't care about the <Mouse> component, we just care about the value we get in the render prop function.

This also means that if need to use or process the values returned by our hooks we don't need to have this logic mixed with what we return. This separation is so much clearer in comparison to render props which I think is very good.

In the Age of Hooks

When Hooks were introduced back in 2018 I can't say that the community screamed with joy. The reaction was mostly complaining about this completely new thing that we'll also have to learn. Yet here we are two years later and most of the hate has died down and modern React is now mostly defined by Hooks. This has also meant that the render prop pattern isn't as popular as it was just a couple of years ago. But while hooks are superior to render props in most cases there are still a couple of situations where you might want to reach for a good ol' render prop.

Wrapping hooks

One of the most straight forward use cases for render props is to wrap hooks so you can use them in class components. Let's say we've previously used a render prop to track whether the mouse is hovering an element and now we refactor this to a useHover hook instead. To use this in a class component we can wrap it in a render prop:

function Hover({ children }) {
  return children(useHover())
}

And then we can use it in a class component just like we would if Hover took care of the implementation itself:

class MyComponent extends React.Component {
  render() {
    return (
      <Hover>
        {([hoverRef, isHovered]) => {
          return <div ref={hoverRef}>{isHovered ? '😃' : '😞'}</div>
        }}
      </Hover>
    )
  }
}

Pretty neat, right?

Enable custom rendering

In the below example we have a component called Grid that takes a prop called data. It renders a table with two rows and two columns, and handles the logic for sorting, filtering, rearranging columns and so on.

const data = [
  {
    name: 'Anton',
    age: 28,
  },
  {
    name: 'Nisse',
    age: 32,
  },
]

return <Grid data={data} />

Now imagine that we need to change how a row or cell is displayed. This is a perfect opportunity to implement two render props in the component that defers this rendering to the user:

<Grid
  data={data}
  rowRenderer={(row, idx) => <div>...</div>}
  cellRenderer={(cell, row, idx) => <div>...</div>}
/>

This could be implemented with a hook that takes the renderers as arguments, but in this case I believe the render prop api is much more pleasant to work with.

Performance

Finally, I recently watched a talk by @erikras and learned about a third use case when you might want to use render props. Below is a component that uses the previously mentioned useHover hook, but it also renders a component called VerySlowToRender which is, well.. very slow to render. It's probably from a third-party package that you have no control over but for some reason you still have to use it.

function MyComponent() {
  const [hoverRef, isHovered] = useHover()

  return (
    <VerySlowToRender>
      <div ref={hoverRef}>{isHovered ? '😃' : '😞'}</div>
    </VerySlowToRender>
  )
}

So in this case the problem is that when you hover the div the entire component will rerender, including the slow part. One way to solve this might be to try wrapping the slow component in some memoization or breaking out the div that is being hovered into its own component, but sometime that might feel like overkill.

What we could do instead is to use our previously defined Hover component with a render prop!

function MyComponent() {
  return (
    <VerySlowToRender>
      <Hover>
        {([hoverRef, isHovered]) => {
          return <div ref={hoverRef}>{isHovered ? '😃' : '😞'}</div>
        }}
      </Hover>
    </VerySlowToRender>
  )
}

Now when we hover the only thing that's gonna rerender is the div! I do think this is maybe the most opinionated use of the render prop pattern, and I can't decide whether I prefer this over breaking it out to another component. Choice is always good though!

Summary

While Hooks have taken over a lot of the responsibility of render props, render props should still have a seat at the table of patterns we use when solving problems with React, as long as we use them for the right reasons.

Thanks for reading! 🙌

Mob programming for a year

Anton Gunnarsson — Wed, 04 Mar 2020 20:27:27 +0000

Last week marked the day when I've been mob programming full time for a whole year. In case you don't know what mob programming is, Woody Zuill, who is credited for discovering the method describes it like this:

"All the brilliant people working on the same thing, at the same time, in the same place, and on the same computer."

In short, it means that you sit together with 2 or more developers and work together on one computer, in a similar fashion to pair programming but with more people. This might sound counterproductive but in reality, it's a very effective way of working. If you want to learn more about the why and the how of mob programming I recommend watching Woody's talk from GOTO conf 2017.

I've really enjoyed discovering mob programming this past year so I wanted to write down some of my key takeaways.

Processes

When you work as closely with your team as you do when you mob program, it turns out that lots of processes are unnecessary.

No pull requests or code reviews since that is done "live" during the day.
We very rarely work in feature branches since the mobs most often don't work in the same part of the application at the same time.
The daily sync meeting is mostly for the benefit of product owners who wants to know how we're doing since everyone in the team is on the same page already.

When mob programming, all of these feel more like bloat and obstacles in the way of delivering value. I dread the day I'll have to go back to attending unnecessary meetings just because someone needs to "talk something through".

My best code

I'm quite certain that I've written my best code ever this past year and I attribute a lot of that to the fact that my code has been constantly code-reviewed, that I've learned so so much from my colleagues and that we (almost) never get stuck.

Most of my time nowadays isn't even spent at the keyboard, but rather in a chair to the side discussing the problem we're trying to solve. In the same way as learning by teaching is a great way to learn, constantly discussing the code I write is a great way for me to improve.

And while it might be rewarding to be stuck on a problem and struggle with it for some time before finally solving it, not getting stuck in the first place beats it. There is always someone in the mob who has an idea of how to solve the issue and since everyone is in the loop already, you don't have to explain the context when discussing it.

Hopefully, I've also helped my colleagues write the best possible code and taught them something along the way.

Interpersonal issues

Working this close to other people all day every day isn't just hunky-dory though. It also means that interpersonal issues rise to the surface quicker than they might otherwise do. While I do see this as a net win, it also requires that everyone dares to be vulnerable, open up and discuss their feelings.

This is something you have to continuously work on if you do mob programming. It is extremely important to build a team where everyone feels safe since so much work is done closely together.

However, regardless of how your way of working looks, your team will perform better if they dare to open up to each other and be vulnerable. There are a lot of resources out there about this but I recommend everyone to read the book Dare to Lead by Brené Brown.

“Leaders must either invest a reasonable amount of time attending to fears and feelings, or squander an unreasonable amount of time trying to manage ineffective and unproductive behavior.” － Dare to Lead

Scaling is hard

I joined the project as my current team grew to six developers, and today we've grown to a total of nine. In my opinion, this has been one of our biggest challenges and is something we still struggle with.

When we were six people we usually split into one or two mobs depending on if someone was sick or working from home. This worked great. We didn't have to spend time syncing what the others did since we sat so close together and almost always worked on the same thing. Now that we're nine and have added just one more mob station so that we usually split into three groups, some of the benefits of mob programming are suffering.

We immediately get some knowledge silos since some people end up working on certain parts of the application for a longer time than others, and hence learns more about it. There is also more overhead communicating between us. It's surprising how much of a difference just one more mob does to the ability to keep track of what everyone is doing.

If you have any experience scaling a mob programming team I'd love to hear your thoughts.

In the end

Mob programming might not fit everyone but I do think that it is an excellent tool to use as a developer. I've had an extremely fun, rewarding and developing year. Let's hope the next one is just as good :)

Recursive components

Anton Gunnarsson — Thu, 16 Jan 2020 19:47:21 +0000

Originally posted over at my blog.

I always had a hard time understanding recursive functions when I stumbled upon them while learning to code. While I've got a better understanding today I don't use them much since they most often make the code harder to read and reason about. One place I do use recursion however is when implementing recursive components.

In this post we'll touch on what recursion is, why recursive components are pretty cool for solving certain kind of problems and implement one that renders a folder structure like this:

While we will use React to implement this component it's possible to build recursive components in all other modern JS frameworks too.

Before we get started, let's talk just a little bit about recursion. Feel free to skip ahead if you got a good grasp on it already.

But what is recursion really? Wikipedia defines it as "a method of solving a problem where the solution depends on solutions to smaller instances of the same problem.". In reality, this often translates to problems where hierarchical structures like trees are involved.

So a recursive function is a function that invokes itself. In the case of traversing the above tree, we would have a function traverse(node) that we'd invoke for the root of the tree, and then it would invoke itself for every child. So first traverse(A), then traverse(B) and then those would invoke the function on their children and so on.

A recursive component, on the other hand, is a component that renders itself. One place where this comes in handy is when implementing features that deal with tree-like data, for example, a nested menu, comments with a hierarchy or as we'll implement in this post; a component that displays a folder structure.

The only important part of recursion we need to keep track of in our implementation of a recursive component is the base case. This is the case when we need to break out of the recursion and stop rendering ourself, otherwise we'd be stuck in an infinite loop. We'll get back to this is just a second.

Let's get to building the component. The data for the folder structure looks like this:

{
  "name": "Desktop folder",
  "children": [
    {
      "name": "Pics",
      "children": [
        {
          "name": "Cats"
        }
      ]
    },
    {
      "name": "Important stuff",
      "children": [
        {
          "name": "Memes"
        },
        {
          "name": "Funny pics"
        }
      ]
    },
    {
      "name": "Blog post drafts"
    }
  ]
}

We'll start by creating a new component called Folder that will take a single prop called folder. It will render the name of the folder and then render itself (ie the same component) for each of its children.

import React from 'react'

export default function Folder({ folder }) {
  return (
    <li>
      {folder.name}
      {folder.children.map(child => (
        <Folder folder={child}></Folder>
      ))}
    </li>
  )
}

The one thing missing from this is that we need to identify our base case so that we can break out of the recursion. In our case, this will be when the folder has no children, or in other words, when it's a leaf in our tree. Let's add a conditional that checks just this.

import React from 'react'

export default function Folder({ folder }) {
  const isLeaf = !folder.children

  return (
    <li>
      {folder.name}
      {!isLeaf &&
        folder.children.map(child => <Folder folder={child}></Folder>)}
    </li>
  )
}

Finally we render the <Folder /> component somewhere:

<ul>
  <Folder folder={data}></Folder>
</ul>

And that's it! You've just created a component that recursively renders itself until it reaches its base case. If you'd like you can now add some better styling, expand/collapse buttons or try implementing it a recursive comment structure. You can find the complete source to the example at the top in this CodeSandbox.

Thanks for reading! 🙌

Looking back at NordicJS 2019

Anton Gunnarsson — Wed, 23 Oct 2019 19:15:16 +0000

A few weeks ago I attended the developer conference NordicJS for the first time. I've been to quite a few other conferences in Sweden since I started working as a developer, but I have to say that this was something else. There was this very welcoming and positive feeling in the air and among the attendees that I haven't experienced anywhere before.

All the talks was of very high quality and I can recommend watching them all, but below are a few thoughts on the talks that resonated with me the most.

Value Driven Development

by Isa Silveira

The very first talk of the conference was Isa Silveira talking about Value Driven Development and opening the talk in a very personal, authentic and vulerable way. She talked about meeting her current partner at last years NordicJS, moving to Sweden from Brazil and using that as a segway into the core of the talk, value driven development.

She talked about how we as developers have an accountability for what we do but that we're also in a position of power in todays society. How are we gonna shift our culture from being solution driven to value driven? And can we use software as a tool to reduce human suffering?

The talk was a great start of the conference and really set the tone for the next two days, and I wholeheartedly recommend watching it.

Gettin’ into the (Tensor)Flow

by Piérre Reimertz

I've tried to learn TensorFlow way to many times, and failed way to many times. I've never found a tutorial or introduction that was light hearted enough to keep me inspired but still compact enough to actually teach me something. But along came Piérres talk at NordicJS.

By combining a fun, practical introduction to real life examples of machine learning with an introduction to the internals of TensorFlow(.js) we get an excellent talk using machine learning as a web developer.

I can't say that I know TensorFlow after watching this talk, but I feel that I have better foundation and I'm definately more inspired to try and learn TensorFlow.js again.

Build dumb sh*t

by Sara Vieira

Finishing off the entire conference was this amazing talk by the hilarious Sara Vieira about "building dumb shit". I don't want to go into to much details about the talk because I believe it's much better if you watch it for yourself. But I'll say that you'll hear about (not) making the world a better place, why useless is not worthless, what an NPM drinking game looks like and much much more. Just watch it.

It was a perfect mix of serious and silly and ended up being my favorite talk of the conference. So inspiring and motivating that at a hackathon a week later I developed a chrome extension that screams back when you scream at your computer ¯\_(ツ)_/¯

Finally

The entire conference was live streamed at Twitch (day 1 & day 2) so if you can't wait for the videos to be uploaded you can already watch it all (I'll update this post with link to the videos when they're uploaded). It was by far the greatest conference I've attended so if you get the chance to attend I highly recommend it.

Software development is a social profession

Anton Gunnarsson — Sun, 02 Jun 2019 16:34:36 +0000

I'm a strong believer that software development is a social profession and not a technical one. And I say that as someone who has read the books on clean code and test-driven development, watched the talks on type systems and listened to everyone who preached about all the other hot fuzz methodologies and technologies. I've enjoyed it thoroughly and learned much, but the more experience I get the more I feel like we as a community need to shift our focus from the nitty-gritty technical details to The Real Problems™.

What would you say is the single most important part of a successful software project? The methodologies we use? React or Vue? TDD or not? Tabs or spaces?

No, the most important part of any software project is its people.

I believe that the developer community has become so focused on the newest frameworks, the coolest libraries and the quickest way to learn it all that we've lost ourselves in a maze of programming languages and buzzwords. I constantly see discussions (mostly online) about programming topics turn toxic and people personally attacking each other for not sharing their opinion. This shouldn't be necessary and I think one way forward is to talk about the human issues we all face more than we do today.

In 2012 Google did an internal research study called Project Aristotle that investigated what makes a team at Google successful. They concluded that the number one key factor of a successful team is psychological safety. The big problem that follows is that people are complex. It's much easier for us to discuss which framework to choose than it is to talk about what makes us feel safe at work. React vs Vue is concrete. Feelings are not.

And despite most companies being very good at talking about how they take care of their employees' and how the employees health always comes first, there are still many reports on crunch in the gaming industry, over 700 posts about burnout on HackerNews and many articles and great discussions about it at dev.to.

Software development is a relatively young industry, and these are issues other industries struggle with as well, but we are also an industry with an incredibly engaged community. How many other professions can say that you can learn everything you need to get a job for free on the internet? Or that so many amazing people share what they know without requiring anything in return? It's a knowledge sharing culture that should impress everyone.

As developers we are very quick to show off our projects in portfolios and on GitHub, taking immense pride in our technical skills (and we should!), but we need to shift our focus from just the technologies we use to the people we are working with. I want to see more discussions like this thread about why sleep might matter more than technical skills, or the feeling of not keeping up with the industry because so much is changing so fast, or how to combine family life with working in tech. I want us to talk about what it is like being a human in the context of software development, instead of just talking about the technical bits of software.

Brené Brown is a researcher and author that has studied vulnerability, courage, shame, and empathy. She is a huge inspiration to me, and I wholeheartedly recommend reading her books (or watching her recent Netflix show). In her book Dare to Lead she writes:

"I define a leader as anyone who takes responsibility for finding the potential in people and processes, and who has the courage to develop that potential."

This is what I wish we would do. Use our empathy and vulnerability to help ourselves and other developers. For most of us, this will most likely be scary. I know it is for me. Talking about real feelings puts you in a very vulnerable position, but it's also how we build trust and how we grow as human beings.

Software development is a social profession because without the interaction between people, there would be no software. Frameworks wouldn't grow, ideas wouldn't spread and projects would fail. We should all strive to go to work and feel that there is joy in what we do, that we can contribute, that what we do matter. And we should strive to make our colleagues feel the same.

"What we know matters but who we are matters more." - Brené Brown