Forem: Adrien TRAUTH

You should not use lodash for memoization

Adrien TRAUTH — Fri, 26 Jul 2019 14:18:20 +0000

A few days ago, I tracked down a bug causing a react component to never update. Debugging showed that the cause was the memoize function of lodash.


    
const lodash = require('lodash');

const add = function(a, b){return a + b};
const memoizedAdd = lodash.memoize(add);

console.log('1 + 1 = 1 + 2', memoizedAdd(1,2) === memoizedAdd(1,1));

This is not really what I expected

In frontend projects we use memoization for different optimizations:

Avoid component rendering - React.memo
Avoid re-computing internal component state - useMemo
Avoid re-computing information derived from the redux state - createSelector from reselect

The goal is always the same: do not redo an expensive computation if inputs are the same as the previous call. It is faster to just return the last computed result directly. More about memoization on Wikipedia

Using memoize in a react app

useMemo, React.memo, and createSelector are usually enough for all your memoization needs. However hooks don't work in class components. If you still have some in your codebase, you need a custom memoization function to replicate the functionality of useMemo. One implementation is described in the react docs.

// function component with memoization

const ComponentWithMemo = ({propA, propB}) => {

    const memoizedValue = useMemo(
        () => computeExpensiveValue(propA,propB), 
        [propA, propB]
    );

    return <p>{memoizedValue}</p>
}


//class component with memoization

import memoize from 'memoize-one';

class ComponentWithMemo extends React.Component {
   // Need to define a memoized function in the component
   memoizedCompute = memoize(computeExpensiveValue)

   render() {
       const {propA, propB} = this.props;
       // and call it on render
       const memoizedValue = this.memoizedCompute(propA, propB);
       return <p>{memoizedValue}</p>
   }
}

2 implementations of memoize to avoid re-computing on render

Lodash being very common, using lodash/memoize seems like a good option to implement the pattern without adding (yet) another dependency.

Problem 1: Lodash uses only the first parameter

Here is how the first example is interpreted by lodash internally:

var memoizedAdd = _.memoize(add); // cache = {}
memoizedAdd(1,1) // cache[1] = 2; return 2;
memoizedAdd(1,2) // return cache[1]; <== My :bug: is here
memoizedAdd(2,1) // cache[2] = 3; return 3;

Step-by-step of the memoized add example

This happens because the memoize function from lodash is only using the first parameter as a cache key by default. So, as long as the same first parameter is passed, the function always returns the same result.

On the other side, memoize-one and the other implementations running in react or reselect re-compute the function when any parameter is changed, thus it always returns the right result.

The problem is not caused by a lodash behavior being undocumented. In fact the documentation states clearly that they're using the first parameter as a cache key. The root cause of those errors is that it's very different from the other implementations that often live in the same project and are supposed to provide the same functionality.

Problem 2: You don't need an unlimited cache

While the first difference may lead to visible bugs, this one may affect performances. This is usually hard to detect but it can have a big impact on the user experience.


    
//
const lodash = require('lodash');

const add = function(a, b){return a + b};
const lodashAdd = lodash.memoize(add);


    
// use the memoized add 1000 times

for(let i = 0; i<1000; i++){
    lodashAdd(i,2);
}

console.log('lodash cache size: ', lodashAdd.cache.size);

Running the memoized functions 1000 times saves 1000 results in the cache. Does that mean that memoize is a good cache? Kind of. But this is not what we need from a memoize function.

Lodash uses a Map to cache all function results associated with a key.

// from https://github.com/lodash/lodash/blob/master/memoize.js
memoized.cache = cache.set(key, result) || cache
...
memoize.Cache = Map

This means that ALL keys and return values will be saved (by default) forever.

If you don't have a lot of different keys, you won't see the difference. If you are using unique IDs, this can become problematic. Memory leaks are hard to track as they may only happen in specific use cases like a page that stays open for a long time. Using a cache that by default can create leaks is thus not recommended.

You could configure lodash cache to limit the number of saved values. I would argue that in a frontend application the best limit for a memoize cache is just one value: the latest computed one.

Memoization is used to avoid recomputing expensive things and make rendering faster. But the bottleneck is not recomputing just one thing. Performance issues happen when an application recomputes every expensive operation on every change.

Memoization with a cache containing just the last value allows your application to only do the few expensive computations that are impacted by a change. This should be enough in most cases.

Note: If you have expensive operations that are too slow to be done even once, then memoization is not the right tool to solve that problem anyway.

Postmortem: lodash/memoize is no more

The first option to fix the bug is to configure lodash memoize to match the react, reselect, memoize-one... implementations.

let cacheKey;
let cacheResult;

// replace the cache to save one value
_.memoize.Cache = {
    set: (key, result) => {
        cacheKey = key;
        cacheResult = result;
    } 
    get: (key) => {
        if(cacheKey == key) {
            return cacheResult;
        }
    }
    // ... other map functions
};



// create a resolver that maps all parameters to a key
const keyResolver = (...args) => JSON.stringify(args);

const add = (a, b) => a + b;

// use the resolver in a memoized function
const memoizedAdd = _.memoize(add, keyResolver);

While replacing the cache can be done once and for all, the keyResolver to use all parameters as the cache key needs to be added to each new memoized function.

This made me choose a second option: Replace the memoize function by another-more straightforward- implementation. The easy part about having to switch from one memoize to another one is that there are already a lot of available implementations in most projects.

I used defaultMemoize from reselect as a short-term replacement and will then either introduce memoize-one or convert the component to be able to use hooks. The other change I'd like to do is adding a linting rule to warn users when they import lodash/memoize.

As a more long-term fix for the whole community, we may want to rename the lodash function to something along the lines of cacheResults(fn, generateKey) so that the name matches better the default behavior and not clash with the common memoize implementations.

Things I learn at standups

Adrien TRAUTH — Wed, 10 Jul 2019 16:18:38 +0000

A few days ago, someone told me that they felt that standups do not bring a lot of value for their team. It got to a point that his team members were getting disengaged.

I've always been a big proponent of this meeting and feel kind of lost when I miss it for a few days. So I took this as an good opportunity to explore what makes me feel that way and wanted to share with you:

Why it’s an important part of my day.
A few tips to make the most out of those 15 minutes.

The team, going to a standup

A valuable standup

We often evaluate if we should keep a meeting by comparing the value it brings to the time spent. Standup being the most recurring meeting, it's understandable that it needs to help the team quite a lot to be worth it. However, I do feel like it has some real hidden benefits for a team.

It's a social event

My team has remote developers and we're not all working on the same things. The standup is sometimes the only opportunity of the day we get to see and interact with each other. It's a mini team-building moment where we get to:

Share our problems.
Get support from the team.
Congratulate each other on achievements.

Team cohesion becomes a critical factor as your team grows and takes on bigger projects. It helps boost morale, streamline exchanges and helps pursuing the common goals of the team. Most of us spend our day working on a piece of code with headphones on. I do believe we need these kind of moments to create cohesion.

Everybody is available

Being forced to all stand in the room has some perks, the first of which is that everybody is ready to listen to anything that is said. It makes it a perfect moment to bother people with small things that don't require interrupting a teammate during the day.

"Do you have 5 minutes to demo that to me today?",
"Can I send you this PR? I'd like to have your opinion on the pattern I used."

These types of questions are all easier to ask (and do get better answers) at a standup than if they were sent as slack notifications. People can also ask for more details and get their answers instantly: it's interactive and fun :-) .

Pull requests do not cover the full story

I used to think that I could know everything that's happening within my team just by reading the pull requests and RFCs. While those artifacts cover the result of peoples' work, they don't always cover how the author got there and what he/she plans to do next.* It's also unlikely that everybody on the team is reading all the PRs-Emails-RFCs. At standup, you can be fairly sure that people are listening.

I learn a lot from hearing what my teammates tried before choosing a final implementation, and I also find it easier to understand the "next steps" when a teammate is explaining them out loud.

*: Unless the team writes amazing pull request descriptions, in that case: bravo.

My teammates have secret talents

And our projects have secret dependencies.

Hey! I worked on something similar, maybe I can help is my favorite thing to hear at a standup. Sometimes I forget that somebody worked on the subject, or discover that they worked on the same thing at their previous company: in either case it's a welcome help.

The other side of that coin is the infamous
Be careful I'm working on the same file, we'll probably have to handle conflicts. Not as exciting to hear that one, but it's still better than learning about it when authors are in rebase hell trying to get their PRs merged.

It helps me structure my days

I take a minute before the meeting to think about what my priorities of the day will be. I feel like this is a good habit and it helps me focus on what's important.

As a way to make sure the meeting stays beneficial as we grow, I usually give our new hires a few pointers before their first standup.

Making the most out of 15 minutes

Also known as: our internal guidelines to a successful standup.

Be precise

You should never say the same thing two days in a row. If you are working on the same subject, then give some details on what you did yesterday that was different from the day before. Your coworkers are all familiar with the context, it's okay to expect them to understand detailed explanations on your subject. The more precise you can be in the time you have, the more value you bring to your teammates.

Make it interactive

Being precise opens the discussion for questions and interactions. The meeting has more value when everyone can ask questions or ask for some details on the part that interests them the most. It makes the meeting more lively and keeps people interested, it's also a good way to discover dependencies or how people can help.

Of course the goal is not to discuss something for 30 minutes. If the question requires a long answer, it should be postponed to either the end of the standup-so the uninterested can leave and get on with their day- or be scheduled as a separate meeting.

It's okay to have a bad day

Sometimes you don't have much to say because you had a bad day for any number of reasons. It's okay to not have a lot to say at standup, it's not a performance review. As long as you're precise about whatever you did yesterday your team will still get value from hearing you. In fact, sometimes explaining why you had a bad day might give your teammates an insight that would allow them to help unstick you.

Focus on the team

I try to highlight the part of my day that was related to the team. If I write a new feature and do a candidate interview, I'll focus more on the pull request because the team is directly impacted by that change.

Own your standup

I hope this can help other teams enjoy that moment as much as I do.

I highly encourage you to spend time making sure your standup meeting is as valuable as possible for your team. It's often a required meeting anyway.
Write your own guidelines, try things, iterate #devopslife