DZ intro

Hi, I'm Matt Riley. I've been with Thoughtworks for 4 1/2 years, and at Xero for about 2 years and I'm currently a tech lead in the Lending team under Financial Services. I'm passionate about agile delivery, architecture, engineering and practices, clean code, and I have opinions about front-end dev.

The lending team have been working with React over the past year. And like many teams, our skills and experience with React and front-end development in general are varied. Our understanding of "what good looks like" is rapidly evolving and is a common topic of our daily tech huddles. While many of our back-end discussions revolve around good application design, patterns and practices, our front-end discussions tend to be dominated by tools and technology. Whether we're aware of them or not, every dependency we introduce comes with trade-offs and constraints. One theme that comes up time and again is how best to share data between components. And as far as we can tell, we are far from the only team wrestling with this theme. We've developed a point-of-view we thought might be of value to share with you.

Before we get into it, let's do a quick refresher of a couple of basics.

Let's start with a really quick refresher. There's nothing magic about React components. They're just functions that receive props and return React elements.

So, what is a pure component?

And please note, this is not an exhaustive list. Unfortunately React Hooks are not a solution. An impure hook makes an impure component.

all inputs described by the function signature; no need to peek under the hood

no need to set up dependencies and state. No mocking required

Both enabled by being easier to reason about and test

Impure components are sometimes necessary. Especially if you want to actually do something useful.

There tends to be two primary ways of sharing data between components.

That is, React is not typically done this way

You probably do it all the time in JavaScript without even realising it

The double arrow syntax is shorthand for a function that returns another function. This is similar to what is know as currying in functional programming. The first function receives namesById and returns actual component function. These two functions can be called at different stages of the application lifecycle. The body of the function can access both namesById and props.

Idiomatic React involves tightly coupling components by importing child components directly into parent components. __These functions are analogous to static functions__ The problem with static functions, is there's no opportunity for __initialisation__. __Would you design a C# application composed exlusively of static functions?__ By enclosing the component function within an "initialiser" function, we can make data available to the component earlier in the application lifecycle, before the component is even created.

Now we have three options. Closure state, props and external state.

With the theory out of the way, I'll hand over to DZ for a demo.