DEV Community: adam klein

Coverage and courage - the pillars of your codebase

adam klein — Tue, 12 Apr 2022 18:45:03 +0000

If you're going to run a marathon, you'll pace yourself and carry a bottle of water with you.

Your marathon is the software you build, and we all know good software is one that you can change. Because requirements - they change all the time. Preparing for a software marathon means preparing for continuous changes of requirements, of open source libraries, of the team's structure, and ever changing best practices.

But how do you prepare for change that you can't anticipate? The first ingredient is test coverage. Not just because you need to test the product before you ship a new version, but because you want the confidence to refactor your code, again and again. You want to see a nasty piece of code you didn't even intend to change, and change it along the way without thinking twice. It's like keeping your house tidy, every time you see something small out of place you put it back where it belongs. If you don't - in a few weeks you'll face long and tedious projects of making order, which you will postpone forever.

The second ingredient to this formula is your courage. The courage to rewrite parts of the code even though there's a pressing deadline. The courage to try out new technologies even though it means your code will have 2 ways of doing the same thing for a while. The courage to switch to a different 3rd-party provider because you realized they're not good enough, even though you just spent 2 months integrating with them. The courage to face your non-tech colleagues and stand behind your decisions that serve the long-run, and mid-run.

You have to remember that while other departments might be running sprints, your software department is running a marathon, and don't let the others set your pace for you. If you do, when you are completely out of breath and start to slow down dramatically half way through, you'll be the only one to blame for it.

Sure, not every period of time in a product development lifecycle is the same, but it's your job to make sure there are enough gaps for regrouping, refactoring, and improving the infrastructure.

React hooks - debunking the myths

adam klein — Sun, 25 Apr 2021 10:31:34 +0000

Sooooooooo many debates about React hooks.
It sometimes seems like people are either in love with the feature, or they completely hate it.

Myself - a hooks fan, but I'm aware of the drawbacks. I believe that everything in software is a tradeoff and has its drawbacks.

On many occasions though, I find arguments against hooks that are just an afterthought and don't represent the true considerations. In my opinion at least, which I'm sharing in this post:

Myth #1 - hooks have these annoying rules - and that means that there's something flawed about them.

Well, yeah - hooks have rules. But so do React classes.
Imagine I told you that all of your state must reside on the same object, must be initialized in a single function which must be named 'constructor', and you can only define one such method. Same of side-effects, each with its own specific name. Sounds pretty restrictive, no?

So it's not that hooks have rules and classes don't have, they just have different rules.

In fact, these limitations of classes are not only a mental overhead, they are a true obstacle for code reuse. If you want to write reusable code that connects to a socket, updates some state, and disconnect on component unmount - it's very hard to accomplish with classes.

Myth #2 - You keep encountering stale state and it's really annoying. If you need an ESLint plugin to write your code safely - there's something wrong with the feature.

Well, if you think about it, the ESLint plugin is not a burden of hooks, it's a benefit. With classes, if you didn't re-run your effect after the dependencies changed - nothing will protect you against it. For example, if you set up a setInterval on componentDidMount but forgot to update it on componentDidUpdate, or forgot to reset it on componentWillUnmount - there is no tool that will alert you that you're doing something wrong. The exhaustive-deps ESLint rule is like TypeScript for your side-effects, it prevents you from writing bugs in compile time.

The same can be said about memoized values. If you memoize a function, but forget to invalidate the cache on certain values - here comes the ESLint rule to protect you against it. In fact, if you don't write any bugs, you won't even know the ESLint rule is there.

Myth #3 - Hooks trade a more explicit API with a more implicit one, at the cost of moving the state and order of execution to behind the scenes

Well, in fact that is not true. The state and order of execution are behind the scenes anyway and completely managed by React. True for hooks, and true for classes. The "this" in classes is just an illusion that makes developers feel more in control, where in fact - React is the one managing the state behind the scenes, and making sure "this.state" is updated by the time our code runs.

Myth #4 - You can't use all the language features with them, like loops.

Well, have you ever tried to define a constructor in a loop? What about returning a Promise that resolves to JSX instead of returning the JSX itself - have you tried that as well?
A framework works in a certain way and expects specific values and formats from the developer. If you don't follow the rules - things break. A sign of a good framework though, is if the rules are simple to remember and reason about and provide tooling to help prevent problems. The rules-of-hooks ESLint plugin is like an extension of TypeScript to help the developer keep the format.

Side note

That being said, I completely understand the arguments about hooks, and I'm not religious about any technology. It takes time to get used to a new syntax, and to truly understand the benefits to it.
It's sometimes tempting to think that the people that created the API made a terrible job, and that there's probably a much better solution. But, there are many considerations that the React team has that you might have overlooked. I strongly recommend going over the discussions on Github for the Hooks RFC, and Dan Abramov's blog overreacted.io, in which he explains the motivation behine some of the decisions.

And if you still disagree - that's cool :)

package-lock.json - in GIT or not?

adam klein — Mon, 18 Jan 2021 15:48:56 +0000

tl;dr

Put it in GIT
Commit it every-time it changes
Never delete it

What is version locking and why we need it?

You write your software, commit it, push it, test it and if everything works well - deploy it to production.

But how do you know that what you tested locally is the same code that is tested on the CI, and is the same code that is being deployed to production?

Your code is inside GIT (or some other version control). If you pull the repository at the exact same commit, you will have the same code.

But your application does not consist only of your own code. It uses external packages as well. One solution for this problem is to commit the node_modules folder to GIT, which includes all of the code your application uses. This creates a problem by itself because then every npm install will create thousands and more changes, and will make it impossible to maintain your repository.

BUT, you don't really need the entire code of the packages you are using, only their versions. Every time you pull the same version from NPM repository you will get the same code.

So, a lock file keeps the version of all our dependencies, and whenever someone runs npm install, they will get the exact same version of your application, including external dependencies.

Why not just keep exact versions in package.json?

Your package.json only points to the versions of your direct dependencies. If they have dependencies too (and they do), these versions won't be locked.

Why not delete package-lock.json?

Think about it, if you delete package-lock and re-install, you are forcing the latest versions of all packages in the dependency tree. Meaning, you are changing the behavior of (potentially) the entire application.

What are you really trying to do? If you have some weird npm-related problem, simply remove node_modules and run npm install again. Removing package-lock.json is never the solution.

Why commit package-lock.json?

If you don't commit it, then the version of the application everyone else will get is different than what you are running locally. This means that things might work for you, but break on the CI/production/other local machines

Hope it helps to understand. And if you are still not certain about the explanation, just follow the 3 rules in the tl;dr section blindly. That's better than nothing

React context to replace Redux?

adam klein — Thu, 06 Aug 2020 08:37:17 +0000

React context is being used extensively for sharing state between React components. If you want proof, just go to facebook.com and open the React developer tools to see for yourself.

So if Facebook is using it so much - it must be a good way to manage state, right? Well, it turns out that React Context has its drawbacks that even Facebook developers are aware of.

The main 2 challenges are:

Performance - unnecessary re-renders
Flexibility - coupling state with the component tree

Performance

The first main challenge is performance. React Context doesn't allow us to use selectors and bailout of rendering. This makes it hard to reduce unnecessary renders and forces you to bend the architecture and reshape the providers all the time.

Flexibility

Context Providers are tied to components on the tree. This means that having dependencies between them forces you to carefully design the order of providers. Also, you cannot shape them as a tree of dependencies, since they are all on the same lineage.

The benefits

The main benefits of context are that it's a built-in mechanism inside React, which means it will naturally support concurrent mode and other changes by the React team. Also, since the state is eventually just a local component state (where the provider resides) - then you can manage it using hooks as you do for the local component state.

Are selectors coming to Context?

The second characteristic is built-in to Context, but there is a light at the end of the tunnel for selectors.
There is currently an open RFC for Context selectors, and we can all hope that it gets accepted sometime soon:
https://github.com/reactjs/rfcs/pull/119

Found mistakes? Think otherwise? Please let me know in the comments section below.

The only state management solution that uses React hooks

adam klein — Wed, 05 Aug 2020 11:48:58 +0000

As of today, we have 2 different ways of managing state and side-effects in React:

For local state and side-effects we use hooks *
For global state and side-effects, we use a library such as Redux or MobX **

* or this.state / lifecycle methods for class components.
** or React context, which has its drawbacks as a state management solution

The main problem is that we are forced to manage local and global state differently. Moreover, we move local state to global state quite often, and the migration costs us precious development hours.

This also means that we don't benefit from the reusability of hooks, and we can't enjoy our custom hooks in global state management.

ReusableJS

ReusableJS is the only global state management solution that uses native React hooks ***
Sure, you can use hooks to connect to Redux or MobX stores, but inside the stores you manage state, side-effects and computed values with a different mechanism.

ReusableJS allows you to manage your global state using native React hooks. It does so by wrapping each global store in a dummy component that executes the hooks, and allows you to subscribe directly to these stores, and use memoized selectors.

This will allow you to manage global state the same way you manage local state, while maintaining high performance, and decoupling your state management from the component tree.

To learn more about how to use ReusableJS, checkout the Repo:
https://github.com/reusablejs/reusable

*** If you know of another library that allow you to manage global state using native React hooks, please let me know. I haven't encountered one after doing a pretty extensive research.

How knowledgable you are about React? See common mistakes people make

adam klein — Sun, 12 Jul 2020 11:23:50 +0000

Low hanging fruits

From my experience interviewing React developers, there are things that many developers don't know, but are quite easy to learn, and will help them become better React developers, and handle quirks and bugs.

They are knowledge pieces about how to use React, and how React works.

Ready? Here are the the questions:

If we manually change the DOM, will React take this into consideration when rendering our app?

To answer this, you need to know how the virtual DOM works.
Plainly speaking, the virtual DOM is a representation of the DOM tree state, in plain JavaScript objects.
When React renders our application, it renders the new virtual DOM, and compares it to the previous virtual DOM. Notice that it doesn't look at the current state of the DOM at all in this stage.

Meaning - if you manually change the DOM, React will ignore these changes, and/or override them if it re-renders that element.

What causes a component to re-render?

The answer many people give is - either state changes, props change, or context changes.
A more correct answer is - state changes, the parent re-renders, or context changes.
By default, React renders all child components if the parent renders, even if the previous props are exactly the same.

The comparison of props only happens for pure components, or components that implement Memo/shouldComponentUpdate.

What is a functional component?

For some reason, many developers think that all functional components are pure. That is not the case. Functional components used to be stateless, but now with hooks that's not the case either. So the main difference between functional components and class components is just the syntax, and that you can only use hooks inside functional components.
Also, there are some things you can only do with class components, like defining ErrorBoundaries.

Does a component name have to start with a capital letter?

This is a tricky question. While a single variable must start with a capital letter to serve as a component, if you use a nested property then it can be a lowercase letter as well. This syntax is valid:

comps = { myComp: () => <div>hi</div> }
...
return <comps.myComp/>

Does state update asynchronously?

This is a very tricky one, especially since React docs literally say that it is asynchronous.

Take this code for example:

function MyComp() {
  console.log('render');
  const [counter, setCounter] = useState(0);

  const onClick = () => {
    setCounter(prev => prev + 1);
    console.log('after setCounter');
  }

  return <button onClick={onClick}>Click me</button>;
}

The logs will be: 'after setCounter', 'render'.
So it seems like render does happen asynchronously after state update. But what if we add an async log after promise resolve:

function MyComp() {
  console.log('render');
  const [counter, setCounter] = useState(0);

  const onClick = () => {
    Promise.resolve().then(() => console.log('promise'));
    setCounter(prev => prev + 1);
    console.log('after setCounter');
  }

  return <button onClick={onClick}>Click me</button>;
}

Now the logs will be: 'after setCounter', 'render', 'promise'. Which means that render was synchronous (it happened before the promise was resolved).

So what's going on?

It feels async, because React performs our event handlers inside a batch. Meaning the render function will only be invoked after the event handler finishes. All state updates are queued until then.
So it might feel asynchronous, but it happens synchronously after the event handler finishes.

To even complicate this further, in concurrent mode the render might be truly async after all.
So React team's advice is to treat state updates as if they were always asynchronous, and I think that is good advice.

When to use a layoutEffect and when to use an effect?

Layout effects receive much less attention, and many developers don't completely understand them. The main difference between them and effects, is that layout effects happen synchronously after the commit phase (meaning after the actual DOM changes), and effects happen asynchronously.

So when should you use a layout effect? For example, when you want to avoid flickering of the UI. For example:

const ScrollSync = ({ scrollTop }) => {
  const container = useRef();
  useLayoutEffect(() => {
    container.current.scrollTop = scrollTop;
  }, [scrollTop]);
  return <div ref={container}>...</div>
}

We use a layout effect to bind scroll position of an element to state, to ensure it will happen synchronously and not cause any delay.

Is it OK to save a reference to the event parameter from event handlers?

The answer is no.

The event object in React is recycled. Meaning - in the future, the same event reference might point to a different event.

If you must - save a reference to properties of the event, or the native event, or call event.persist() to detach it from the event pool.

Wrap up

I hope you learned something new, or at least got some order or new perspectives about the things you already know.

If you have any feedback or I made a mistake - please let me know in the comments section.

We don't know how React state hook works

adam klein — Wed, 08 Jul 2020 06:46:58 +0000

This article is about:

When is the state updated
The update queue and lazy computation
Batching
useState vs. useReducer
Performance optimizations
- eagerly computing state updates
- shallow rendering and bailing out
Will the updater function always run?

When is the state updated?

Look at this code:

const MyComp = () => {
  const [counter, setCounter] = useState(0);

  onClick = () => setCounter(prev => prev + 1);

  return <button onClick={onClick}>Click me</button>
}

What would you imagine happen after the button is clicked and setCounter is called? Is it this:

React calls the updater function (prev => prev + 1)
Updates the hook's state (= 1)
Re-renders component
Render function calls useState and gets updated state (== 1)

If this is what you imagine - then you are wrong. I was also wrong about this, until I did some experiments and looked inside the hooks source code.

The update queue and lazy computation

It turns out, every hook has an update queue. When you call the setState function, React doesn't call the updater function immediately, but saves it inside the queue, and schedules a re-render.

There might be more updates after this one, to this hook, other hooks, or even hooks in other components in the tree.
There might be a Redux action that causes updates in many different places in the tree. All of these updates are queued - nothing is computed yet.

Finally, React re-renders all components that were scheduled to be rendered, top-down. But the state updates are still not performed.

It's only when useState actually runs, during the render function, that React runs each action in the queue, updates the final state, and returns it back.

This is called lazy computation - React will calculate the new state only when it actually needs it.

To summarize, what happens is this (simplified):

React queue's an action (our updater function) for this hook
Schedules a re-render to the component
When render actually runs (more about this later):
- Render runs the useState call
- Only then, during useState, React goes over the update queue and invokes each action, and saves the final result in the hook's state (in our case - it will be 1)
- useState returns 1

Batching

So when does React say: "OK, enough queueing updates and scheduling renders, let me do my job now"? How does it know we're done updating?

Whenever there's an event handler (onClick, onKeyPress, etc.) React runs the provided callback inside a batch.
The batch is synchronous, it runs the callback, and then flushes all the renders that were scheduled:

const MyComp = () => {
  const [counter, setCounter] = useState(0);

  onClick = () => { // batch starts
    setCounter(prev => prev + 1); // schedule render
    setCounter(prev => prev + 1); // schedule render
  } // only here the render will run
  return <button onClick={onClick}>Click me</button>
}

What if you have any async code inside the callback? That will be run outside the batch. In this case, React will immediately start the render phase, and not schedule it for later:

const MyComp = () => {
  const [counter, setCounter] = useState(0);

  onClick = async () => {
    await fetch(...); // batch already finished
    setCounter(prev => prev + 1); // render immediately
    setCounter(prev => prev + 1); // render immediately
  }
  return <button onClick={onClick}>Click me</button>
}

State is Reducer

I mentioned earlier that "React runs each action in the queue". Who said anything about an action?

It turns out, under the hood, useState is simply useReducer with the following basicStateReducer:

function basicStateReducer(state, action) {
  return typeof action === 'function' ? action(state) : action;
}

So, our setCounter function is actually dispatch, and whatever you send to it (a value or an updater function) is the action.

Everything that we said about useState is valid for useReducer, since they both use the same mechanism beind the scenes.

Performance optimizations

You might think - if React computes the new state during render time, how can it bail out of render if the state didn't change? It's a chicken and egg problem.

There are 2 parts to this answer.

There's actually another step to the process. In some cases, when React knows that it can avoid re-render, it will eagerly compute the action. This means that it will run it immediately, check if the result is different than the previous state, and if it's equal - it will not schedule a re-render.

The second scenario, is when React is not able to eagerly invoke the action, but during render React figures out nothing changed, and all state hooks returned the same result. The React team explains this best inside their docs:

Bailing out of a state update
If you update a State Hook to the same value as the current state, React will bail out without rendering the children or firing effects. (React uses the Object.is comparison algorithm.)

Note that React may still need to render that specific component again before bailing out. That shouldn’t be a concern because React won’t unnecessarily go “deeper” into the tree. If you’re doing expensive calculations while rendering, you can optimize them with useMemo.

https://reactjs.org/docs/hooks-reference.html#bailing-out-of-a-state-update

Put shortly, React may run the render function and stop there if nothing changed, and won't really re-render the component and its children.

Will the updater function always run?

The answer is no. For example, if there's any exception that will prevent the render function from running, or stop it in the middle, we won't get to the useState call, and won't run the update queue.

Another option, is that during the next render phase our component is unmounted (for example if some flag changed inside the parent component). Meaning the render function won't even run, let alone the useState expression.

Learned something new? Found any mistakes?

Let me know in the comments section below

Why Code Reviews Shouldn't Exist

adam klein — Wed, 20 May 2020 10:30:51 +0000

CRs (Code Reviews) are the industry standard for keeping our code quality and sharing best practices between team members.
But if you think about what a CR is - it's someone reviewing your work after you're already done with it, and made a context-switch to a different task, and a different branch. Not a very effective way to ensure code quality.

Automation

Our coding practices evolved during the years. We tackle this problem by creating small commits, ensuring PRs (Pull Requests) are not getting stale and moving a large portion of code quality control to automated tools.

Code styling remarks are a thing of the past. We have linters and prettifiers, which means no more endless debates about code styling. Almost all errors are caught during coding time, and some are automatically fixed.

Most of these tasks already have automated tools that solve them.
Automated tests help verify the correctness of the code and regression.
We have automated checks that verify your code meets the performance metrics.

3rd party tools based on AI are starting to review our PRs automatically, and even create pull requests themselves, keeping industry standards, making patches to close security vulnerabilities, and updating open source packages.

What about code design and architecture?
If you think about it, if you've already written your code, wrote tests, and created a pull request - now it is probably a little too late for someone to suggest that you re-design your code.
Enter design reviews - ask for feedback before you write the code, and not after it.

The future of CRs - continuous review

Despite the current automation, we still do CRs. That's because we always want another pair of eyes on the code, and automation is still basic and can't understand the context of our code. So how will CRs change in the future?

In the future, more and more automation and collaboration will influence our coding environment. Thanks to AI, we will have tools that alert us in real-time if our code is duplicate or inefficient and if it conflicts with some other change that is being written by another developer. They will also suggest better names for our variables and methods and keep them consistent throughout the system.

The timespan between writing code and having it reviewed - by human and machine - will get shorter and shorter until it becomes continuous. The tools that shape our environment will become smarter, more real-time, and more collaborative.

The tools that allow us to collaborate will become more efficient and user friendly and will have a better and more intimate understanding of our work. These tools could, for example, allow us to review the history of comments and discussions around our code, who are the main contributors to it, ask for a review in real-time, and help us schedule the reviews to avoid bottlenecks and outdated branches.

So, unless AI can write code instead of us, and put us all out of work, I anticipate a bright future for developer productivity and happiness, and a future which lets us focus even more on what we like doing best - coding.

The true code behind the explosive buzzword marketing messages

adam klein — Fri, 01 May 2020 07:11:15 +0000

AI driven personalization and individualization

if (isReturningUser) {
  message = 'Welcome back!';
} else {
  message = 'Welcome!';
}

Cutting-edge security algorithms

const hashedPassword = sha256(password);
// TODO: read about salt

AI-based text sentiment analysis

sentence.split(',').forEach((phrase) => {
  if (['angry', 'upset', 'pissed off', 'disappointed', 'absurd', 'manager', 'get me your manager', 'get me the manager', 'I want to speak with the manager', 'your manager', 'the manager', 'a manager', 'shut up!', '!!!', 'insane', 'crazy', 'stop arguing with me', 'would you just listen?!', 'how many times', 'no!', `${F_WORD} you!`, `${F_WORD} off!`, `${F_WORD}!`].includes(phrase)) {
    return SENTIMENTS.ANGRY;
  } else {
    return SENTIMENTS.NEUTRAL;
  }
  // TODO: We are not using SENTIMENTS.HAPPY - consider removing
});

Rendering engine

function render() {
  components.forEach(c => render(c));
}

State of the art rendering engine

function render() {
  requestAnimationFrame(() => {
    components.forEach(c => render(c));
  });
}

Analytics

function sendAnalytics(event) {
  sendToServer('/analytics', event);
}
button.onclick = () => sendAnalytics('clicked');

Actionable Analytics

function sendActionableAnalytics(event) {
  sendToServer('/analytics', event);
}
button.onclick = () => sendActionableAnalytics('clicked');

Real-time collaboration

setInterval(() => {
  fetch('https://api.server.com/newData').then(isNewData => {
    if (isNewData) {
      this.refreshEverything();
    };
  });
}, 1000);

Data driven business intelligence

if (customer.lastLoggedIn < new Date() - 3 * MONTHS) {
  sendSmartAlert(SMART_ALERTS.USER_CHURN_ALERT);
}

Contribute more examples using the comments

If you think of funnier examples - comment and I'll include them (if they're good)

5 ways that will change how you write React hooks

adam klein — Sat, 25 Apr 2020 19:22:26 +0000

NOTE!

Tips and methods in this post are my own personal preference, and I'm sure many people will disagree.

There is no right or wrong. Every approach has its pros and cons. If you take just one good thing out of the post - I've done my share.

I do not mean to insult anyone who thinks differently. Some of the "bad code" examples used to be code that I've written myself!

If you do think differently - you are more then welcome to comment and change my mind.

Good reading!

1. An effect has no name

Writing several effects in the same component?

const MyComp = () => {
  useEffect(() => {
    ...
  });
  useEffect(() => {
    ...
  });
  useEffect(() => {
    ...
  });
}

I don't want to read your code just to know what they are doing... duh...

Here's a tip for you, use named functions:

const MyComp = () => {
  useEffect(function fetchData() {
    ...
  });
  useEffect(function subscribeToUpdates() {
    ...
  });
  useEffect(function useInterval() {
    ...
  });
}

Much better right?

There's another benefit - you will see the effect name in React dev tools:

Don't be a smarty pants and try to extract to constants, like this:

const MyComp = () => {
  function fetchData() {...}
  function subscribeToUpdates() {...}
  function useInterval() {...}

  useEffect(fetchData);
  useEffect(subscribeToUpdates);
  useEffect(useInterval);
}

Because then you are only fooling the linter, not me!
(Exhaustive deps rules won't work for the function implementations)

2. async functions

Effects don't support async functions (you can't return a promise).
It's so annoying, let's try to solve it:

const MyComp = () => {
  useEffect(() => {(async() => {
    ...
  })();});
}

WTF?! IIFE?! Are we in 2010?!
Try again please:

const MyComp = () => {
  async function fetchData() {...}
  useEffect(() => {
    fetchData();
  });
}

No! You are not listening! (See comment above about exhaustive deps)

OK, I'll give it to you:

const MyComp = () => {
  useEffect(function doSomething() {
    async function doSomethingAsync() {
    }
    doSomethingAsync();
  });
}

Sometimes you just gotta be verbose with them code.

Or, if you insist on taking the function out, take it out completely from the component and pass it the deps:

async function doSomethingAsync(dep1, dep2) {
  ...
}

const MyComp = () => {
  useEffect(function doSomething() {
    doSomethingAsync(dep1, dep2);
  }, [dep1, dep2]);
}

3. Debouncing the hooks way

It's really stupid to implement your own debounce when there is a ton of libraries out there who already have. Right?!

Wrong! 'Cause now we got hooks!!

const MyComp = () => {
  useEffect(function doSomethingDebounced() {
    const timeout = setTimeout(() => {
      doSomethingWith(value);
    }, 500);
    return () => clearTimeout(timeout);
  }, [value]);
}

Ummm.... what?
Yes, that is an implementation of debounce with nothing but effect, timeout and cleanup function. You're smart, think about it.

4. useCallbacks? Nahhh....

You might think that useReducer is better than useState when managing a complex object:

function reducer(state, action) {
  switch(action.type) {
    case 'MOVE_RIGHT':
      return { ...state, left: state.left + action.step };
    case 'MOVE_DOWN':
      return { ...state, top: state.top + action.step };
    default:
      return state;
  }
}
const [position, dispatch] = useReducer(reducer, { left: 0, top: 0 });

But think about it, you will still have to use useCallback for each action dispatch if you want a stable ref:

const moveRight = useCallback((step) => dispatch({ type: 'MOVE_RIGHT', step }), []);

Think about this version instead:

const [position, setPosition] = useState({ left: 0, top: 0 });
const actions = useMemo(() => ({
  moveRight: step => {
    setPosition(state => ({ ...state, left: state.left + step }))
  },
  moveDown: step => {
    setPosition(state => ({ ...state, top: state.top + step }))
  }
}), []);

All actions are memoized!
And no switch case, meaning better debugging experience and TypeScript integration.

5. Use `useContext` with selectors to bail out of render

You've probably heard many times that it's impossible to bail out of rendering if you're using Context.

Well.....

You're right. I'll give it to you.

But cross your fingers, 'cause selectors are coming to a version near you:

https://github.com/reactjs/rfcs/pull/119

When this is accepted, we would be able to do this:

useContext(MyContext, value => value.someProperty);

Hopefully in the next few months, but who knows, right?!

Hope you learned something new! Tell your friends.

You don't need useReducer

adam klein — Wed, 13 Nov 2019 09:15:36 +0000

There's a misconception these days in the React community that whenever you want to manage a complex object instead of breaking down to individual state variables, you should use useReducer.

But, as I'll show in this article, managing a complex object and the changes it can go through can be more easily done using useState.

Show me the code

OK, here are the 2 versions, which are pretty much equivalent in result:

useReducer:

function reducer(state, action) {
  switch(action.type) {
    case 'MOVE_RIGHT':
      return { ...state, left: state.left + action.step };
    case 'MOVE_DOWN':
      return { ...state, top: state.top + action.step };
    default:
      return state;
  }
}
const [position, dispatch] = useReducer(reducer, { left: 0, top: 0 });

dispatch({ type: 'MOVE_RIGHT', step: 10 });

useState:

const [position, setPosition] = useState({ left: 0, top: 0 });
const actions = useMemo(() => ({
  moveRight: step => {
    setPosition(state => ({ ...state, left: state.left + step }))
  },
  moveDown: step => {
    setPosition(state => ({ ...state, top: state.top + step }))
  }
}), []);

actions.moveRight(10);

Note the useMemo. The reason it is there is to make sure we gain feature parity with useReducer. Since the dispatch parameter of useReducer is always constant throughout renders, I wanted the actions to be that as well

So what did we gain?

Easier TypeScript support.
Inside the reducer, you are dealing with different types of actions, each with its own parameters. To get that working well with TypeScript you'll need to add a type per action and follow some rules to make sure TypeScript can differentiate between the different action types inside the switch case.
It's less intuitive and more verbose than working with plain function signatures, which have the parameter types colocated next to the implementation.
Better IDE Support
If you use functions and not action objects, you can jump to its definition, look for references to a function, and rename it globally with the help of the IDE.
Less error-prone
String action types are prone to undetected errors. You can obviously bypass this with some constants or TypeScript magic, but that means you need to add more boilerplate code.

Did we lose anything?

It's easier to test a reducer. Or is it?
Since a reducer is a pure function, it's easier to test. Testing a function that uses the setter function will require some extra wiring.

But, we could easily write a test-util once that will help us test object actions, and reuse it where-ever we need. Moreover, the benefits of functions over action objects will also prove useful inside tests, such as better TS and IDE support.

So all in all, I would argue that the benefits surpass the drawbacks in terms of testing.

What about reducers in Redux?

For a global state manager, there are other benefits to using action objects. Several reducers can handle the same action, you get a nice view of the history of the app state using the devtools, and it's easy to export and import entire user flows. You can think of every state mutation as a user intent that is expressed using an object - and it opens up more possibilities.

But for a local state, these benefits do not exist. You always handle the action in the same reducer, and the action history of a single component is not that interesting.

Change my mind

I know it's a very common pattern in the industry to use a useReducer, but I really hate doing things just because they're popular if they don't make any sense to me.
So I'm very very very much open to other opinions and ideas, and if you can change my mind I'd love to see how.

A recipe for deciding between technologies

adam klein — Sat, 14 Sep 2019 16:08:36 +0000

I've written in the past why I think choosing between technologies is extremely difficult.

So, here are my 2 cents on how to do that effectively. It's not a bullet-proof method, but I hope it will help guide you on that journey:

Do some unstructured and unbiased research of pure facts and verify them against different sources. Don’t make any prejudgments and don’t choose sides.
Look at who’s writing the article and what education they have on the subject. Try to understand if it’s a technical, experienced person, or a content writer. Check out the comments as well.
Find people that you trust and that face similar challenges, and share your view on development, and consult with them.
Write down a list of features for each technology.
Find the features that satisfy your needs in all options, and remove them from the list. For example, if all technologies are performant enough for you — no need to compare their performance.
Decide on each feature what is a pro and what is a con for you.
Think about the things that matter the most to you. For each technology, write down at most 3–4 pros/cons that are important for you, and ignore the rest.
Go over the list and see if there's any technology that you can already cross out based on the pros/cons list.
For the remaining techs, make a PoC, and determine the barrier of entry and the quality of the documentation.

Your choice

Remember, these are YOUR personal interpretations. Some people will see a framework’s full solution as a pro, some will see it as a con. Some don’t really care about popularity, for others, it’s the most important requirement.

Your choice will affect future developers for potentially years, so making a good research at this stage is worthwhile.

Good luck!