DEV Community: Michał Kardyś

Singleton-like Context for shared components managent

Michał Kardyś — Thu, 22 Apr 2021 09:33:44 +0000

(story originally appeared at kardys.dev)

Are you handling external modules or shared config in your React projects?

React Context, when overused, can become hell. On the other hand, Setting up shared modules/config with Context can be helpful.

How to handle shared config?

Regular Context is hidden by Provider down the render tree.

What if we... make a singleton?

Single place for your settings is helpful. You have easy go-to place if you need to update your config. Yet, with increasing modularity of your code it becomes harder and harder.

So, should you setup Redux workflow?

If the app is not big/complex Redux is not goto. It's like shooting a pigeon with a cannon. Overkill.

What then?

Single source of truth would be helpful. A singleton.

How to do it?

Let's inverse our context! Let's prevent providers down the tree. Let's...

Create context singleton

Simplest implementation for singleton-like context:

const NOT_INSTANTIATED = 'NOT_INSTANTIATED';

const Context = React.createContext(NOT_INSTANTIATED);

function SingletonContext(props){
  const value = React.useContext(Context)

  if(value === NOT_INSTANTIATED){
    return <Context.Provider {...props}/>
  }

  return <React.Fragment {...props}/>
}

What happens here?

You create React context with defaul "NOT_INSTATIATED" value. So, if use consume the context and no provider is rendered above - you get the default value.

Next is wrapper.

SingletonContext does following:

Consumes provider
If it hasn't been instatiated earlier create provider
Otherwise return Fragment

Singleton in action

const Display = () => {
  const value = React.useContext(Context)

  return <div>{value}</div>;
};

const App = () => {
  return <React.Fragment>
    <SingletonContext value={'first'}>
      <SingletonContext value={'second'}>
        <Display/>
      </SingletonContext>
    </SingletonContext>
  </React.Fragment>
}

When we create 2 SingletonContext components, the former Context.Provider is created

Result is:
first is passed to Display consumer

What if we create parallel Provider?

const App = () => {
  return <React.Fragment>
    <SingletonContext value={'first'}>
      <SingletonContext value={'second'}>
        <Display/>
      </SingletonContext>
    </SingletonContext>

    <SingletonContext value={'separate render tree'}>
      <Display/>
    </SingletonContext>
  </React.Fragment>
}

Now we have, as expected, 2 results:

first
separate render tree

That why it's not fully singleton (unless you put it in app root).

Use cases

Config shared between many apps
Redux singleton (we can render redux provider similar way)
Many components loosely scattered
- each needing a common theme provider or so
- this way we can 'safeguard provider' and render it if not present

It is, of course, not 'the only right way' to do things.

For external modules you might want this method from my previous post, too.

How do you manage your configs?

See code in action:
codepen

Setup external modules with React Context

Michał Kardyś — Thu, 22 Apr 2021 09:29:35 +0000

(story originally appeared at kardys.dev)

A pattern that is helpful when you use external modules in your app.

Some time ago Dan Abramov posted this tweet:
Dan Abramov's tweet

<Context.Provider value={<RenderedComponent />}>
  <Something />
</Context.Provider>

This pattern is neither necessary nor common, yet it is useful at certain times.

What are use cases?

The pattern is helpful when external modules arise. What exactly do I mean by external module?

See, chat. Let's assume you have SPA and you want to add Intercom-like chat to your app.

Should you setup it somewhere down in your render-tree?

It is an option.

FloatingButton.jsx
//...
<Chat
    prop1={prop1}
    flag
    anotherFlag
    />

Yet,

What if you need a change?

You might need it in 2+ places:
- under a floating button
- or when user selects 'help' section
- so, you instantiate 2 some components 2 times?
You might want to keep all external configs in one place
- to have an eye on dependencies
- to slowly replace all externals with your internal code
- would looking for all of these usages be simple? It might

...but there's another way

Setup external component with context

What if instead of:

FloatingButton.jsx
//...
<Chat
    prop1={prop1}
    flag
    anotherFlag
    />

HelpSection.jsx
//...
<Chat
    prop1={prop1}
    flag
    anotherFlag
    />

you do:

ExternalModules
export const ExternalChatProvider = (props) => <Context.Provider value={<Chat
    prop1={prop1}
    flag
    anotherFlag
    />}
    {...props}
    />
export const ExternalChatConsumer = (props) => <Context.Consumer {...props}/>

Main
//...
<ExternalChatProvider>
    <SPA/>
</ExternalChatProvider>

FloatingButton
//...
<ExternalChatConsumer/>

HelpSection
//...
<ExternalChatConsumer/>

It:

has single point of config
follows DRY rule
clearly signals that module is external (read: possibly unsafe)
rendered once

I've simplified code, but you could:

add memoization,
parametrize it,
etc.

This technique is useful not only for external modules, but for using shared components in general.

A word of caution: do not overuse

context is additional component,
it causes jumps in logic and
it is harder to read app flow with to many contexts.

How do you manage external components?

Safer (and fast) refactoring in React

Michał Kardyś — Thu, 22 Apr 2021 09:26:14 +0000

(story originally appeared at kardys.dev)

How snapshot testing is great for refactoring

Simple process

Snapshots work for things like data structures (as regular tests).
Refactoring is another great use case.

Here, I'm talking about refactoring.

To refactor, you need stability.

You work on SaaS app's frontend. New features flow in. You (or your teammates) develop new pieces of code.

What comes next?

At one point you need to refactor "little piece of code". And here you feel like you go through gates of hell.

you edit X - component A breaks down
you fix it, A works now - but suddenly Y fails

The deeper you go, the more problems arise. Even, when you try to edit just "one thing".

Does it often has to be like this?

Yes, I've exarregated situation (have I?).

Yet, we need to be sure if our refactoring works as before.

Otherwise we blow up part of the system and we are not aware of that.

How to refactor code safely without too much hassle?

Snapshot testing stabilize your code

Snapshots have had its 5 minutes.

When these arised, I've seen articles about snaps everywhere. People praising simplicity were most common.

The simplicity came with its' hidden cost. At one point I've made the same mistake.

It is:

too many snapshat tests.
too many and too fragile.

Tests have indicated changes in structure. Most often the change was meaningless (for instance, autogenerated class name change).

It builds insensitivity to further warnings. A good reason to avoid these.

But, there's great use case for snapshot testing which I learned some time ago.

Refactoring.

Refactoring with snapshot tests

The process is:

You make snapshot of a component you want to refactor. (don't commit these)
You refactor the code
If snapshot test passes after refactor, delete test.

Test is temporary. You don't have to push it anywhere.

It is just your helper, so you are certain that after refactoring, result looks exactly the same

Check it out.

It's:

simple
fast
easy

How do you refactor your code?