memoize-one

The addition of a named import for memoize-one in 5.2.0 created an unintentional breaking change for our CommonJS bundle #116 (Thanks @ehmicky for finding this)

5.2.1 reverts the addition of the named import of 5.2.0. 5.2.0 has also been deprecated on npm

⚠️ 5.2.0 is deprecated on npm ⚠️

The addition of our named import created a breaking change for our CommonJS build #116 (Thanks @ehmicky for finding this)

The named import feature has been reverted and you can continue to use the default import has you always have

import memoizeOne from 'memoize-one';

New feature: Added a named import #37

DEPRECATED Please continue to use default import

This resulted in a minor bump for the library

You can now import memoize-one using a named import if you want

import { memoizeOne } from 'memoize-one';

Alternatively, you can continue to use the default import

import memoizeOne from 'memoize-one';

Fix: Correctly handling NaN #101

Our default equality checking function does a === equality check for all arguments. This was problematic when providing special "not a number" number → NaN as NaN !== NaN. Our default equality function now handles NaN values correctly

Thank you @ohoho7 for raising this and @Ayub-Begimkulov for diving it forward

Improvement: Documentation

I have added more detail to the readme which explains in greater detail how our default equality function works

Improvement: Bumping dev dependencies

I have upgraded all the devDependencies of memoize-one to be their latest versions. A reminder that memoize-one has no dependencies 🎉

Looser EqualityFn type

For 5.1.0 we shipped an EqualityFn type that was not ideal. It was decided that the simplest path forward for consumers was to move to a looser EqualityFn type. #73

- export type EqualityFn = (newArgs: readonly unknown[], lastArgs: readonly unknown[]) => boolean;
+ export  type EqualityFn = (newArgs: any[], lastArgs: any[]) => boolean;

Thanks @SanderDeWaal1992 for raising this issue

Typescript support! 🤘🤩🤘

Typescript consumers will now start getting correct types without having to rely on installing @types/memoize-one. Internally memoize-one is now authored in Typescript.

memoize-one is still shipping flow types, so if you are using, or want to use flow, then you will still get the same fantastic types you always have.

And if you want to use good old regular vanilla JS then you can do that too!

This change has been marked as a feature release as it will not break any existing flow consumers

❤ Thanks to @PavelVanecekAtlassian, @danieldelcore and @TrySound for their assistance. And thanks to @karol-majewski and @franklixuefei for creating the previous memoize-one typescript types on DefinitelyTyped

• Naming functions for better stack traces #68
• Bumping all dev dependencies #68
• Bumping node for travis build and adding .nvm file #69

😢 Unwinding: Improved typing #61

This change broke existing flow type consumers. We need to look into how our local flow type tests did not pick this up. For now, the flow change has been reverted. If we do move to the new flow types then we will need to publish a good upgrade story.

⚠️ This release has been deprecated on npm. However, all improvements are available in 5.0.4. There were some issues with the updated flow types

🚀 Performance #59

We tweaked our default equality function to run much faster.

From 1.1 to 15.5 times faster!

Thanks to @wbinnssmith for creating performance benchmarks to test ideas #62. Thanks @theKashey for your input!

👩‍⚕️ Improved typing #61

Removed in 5.0.4

Thanks to @wbinnssmith we now have even better flow typing.

Other

• Upgrading to flow 0.96 #63

• Fixing flow issue #58. Caused by using non-standard $ExpectError comment. Thanks @jmansor for the pick up

Engineering health

• Bumping all dev dependencies #56
• Upgrading to flow 0.95.1 #56
• Minor internal cleanup of flow types #56

Other

• Improving language used for argument length checking for the default equality function in the docs #56

New custom equality function api

Previously we could call a custom equality function for each argument. Now we call it once and pass in the complete sets of arguments. This allows for a lot more flexibility.

- type EqualityFn = (newValue: mixed, oldValue: mixed) => boolean;
+ type EqualityFn = (newArgs: mixed[], lastArgs: mixed[]) => boolean

Old behaviour

const memoized = memoizeOne(fn, isEqual);

memoized(1, 2);
// isEqual not called on first call

memoized(1, 3);
// isEqual called two times
// first call: (1, 1) (newArg, oldArg)
// second call: (3, 2) (newArg, oldArg)

New behaviour

const memoized = memoizeOne(fn, isEqual);

memoized(1, 2);
// isEqual not called on first call

memoized(1, 3);
// isEqual called one time
// first call: ([1, 3], [1, 2]) (newArgs, oldArgs)

We have provided a detailed usage guide

This resulted in a breaking change 💥. However, it will only impact you if you are using a custom equality function. Addtionally, some libraries such as lodash.isequal will handle this api change without you requiring to make any code changes.

Engineering health

• Moved to flow 0.89
• Moved to prettier for formatting
• More tests!

Thanks to the following people for their assistance with this release ❤️:

• @petegleeson
• @treshugart
• @Noviny
• @marcusdpeterson
• @nihgwu
• @alamothe
• @ehtb

🛑This release has been deprecated

New feature: index provided to equality function #42

🛑This feature has been removed and replaced with a new custom equality pattern

Thanks @nihgwu for submitting this one!

If you are not providing your own custom equality function then there nothing to see here 👍

Custom equality functions are now provided with a third argument: the index of the argument.

-type EqualityFn = (newValue: mixed, oldValue: mixed) => boolean;
+type EqualityFn = (newValue: mixed, oldValue: mixed, index: number) => boolean;

This can be useful if you want to do different types of checking depending on the order of the argument.

import memoizeOne from 'memoize-one';
import deepEqual from 'lodash.isEqual';

const myEqualFn = (newArg, lastArg, index) => {
  // use deep equal for first arg
  if(index === 0) {
    return deepEqual(newArg, lastArg);
  }
  // use shallow equal for all other arguments
  return newArg === lastArg;
}

const fn = (...args) => {
  console.log('called with', ...args);
};
const memoized = memoizeOne(fn, myEqualFn);

memoized({hello: 'world'}, 5);
// console.log('called with', {hello: 'world'}, 5);

memoized({hello: 'world'}, 5);
// no call to console.log

This resulted in a feature release

Engineering health

• Upgraded to flow 0.88
• Upgraded all flow-typed lib definitions
• Upgraded all dev dependencies

• Upgrading to flow 0.85
• Upgrading dev deps

Improvements

Faster and less cache busts with throw

We are still gracefully handling result functions that throw. We have made a few improvements:

• no longer using a try / catch for maximum performance - more details
• calls to the result function that end up causing a throw will no longer break the memoization cache

Thanks @ChristopherChudzicki for originally pointing me in this direction

Fixes

Handling functions that throw #31

Previously if your result function threw a value you could get some strange behaviour. We have fixed this so that memoizeOne is aware when your result function throws a value. If your result function throws then the memoized function will also throw. A thrown value is not cached and the result function will be re-executed if called again with the same arguments.

const willThrow = (message) => {
  console.log(message);
  throw new Error(message);
}

const memoized = memoizeOne(willThrow);
let firstError;
let secondError;

try {
  memoized('first message');
  // console.log => 'first message'
} catch (e) {
  firstError = e;
}

try {
  memoized('first message');
  // console.log => 'first message'
  // even though the arguments are the same the result function was called again
} catch (e) {
  secondError = e;
}

// result is regenerated and not cached
console.log(firstError === secondError);
// false

Thanks @ChristopherChudzicki for raising this issue and for the initial PR. Thanks to @scinos and @jamiebuilds for working this through with me.

Improvements

• Moving to babel 7 #34
• Moving to flow 0.79.1 #34
• Added example for custom equality function with multiple arguments to README #29. Thanks @andwilley!!

Changes

A bundle of joy 🎁

We are now publishing a number of bundle builds for your consumption needs!

• dist/memoize-one.cjs.js CommonJS bundle
• dist/memoize-one.esm.js ESM bundle
• dist/memoize-one.min.js UMD bundle (production build)
• dist/memoize-one.js UMD bundle (development build)

This was listed as a breaking change 💥 - even though there are no api changes. The only changes are to the names and paths of the build files.

Bumping flow

We are now on the latest version of flow: 0.75.

Fixes

• We had an error in IE11 due to manually setting the .length property of our result function (added in 3.1.0). For now we have rolled back the feature and deprecated 3.1.0 which added it. We could have wrapped the code in a try/catch but we where not sure of the performance implications of going so. Thanks @eugene1g for finding this and @theKashey for helping work through it

This release has been deprecated on npm due to a critical bug in IE11. Please use 3.1.1.

Features

• We now add the correct .length property to the result function. Thanks @theKashey for this one!
• We now add a .name to the result function for improved debugging. Thanks @theKashey!

Other

• We now publish a esm module build! Thanks @Andarist!
• Upgraded to the latest flowtype
• Moved from mocha to jest
• Upgrade all dependences to the latest versions

As with 2.0.0 this release has no javascript api changes. This version bump is the result of this pull request: #12

In this pull request the flow types for memoize-one where improved to be more correct. In doing so the flow type became a little tighter and more correct. There may be a situation where some code could potentially be relying on the less stringent type checking and in which case this change would break their code. As this is a change in public api that may possibility by some remote chance break a consumer - I thought it safest to do a major version bump.

I have created a github release for this major version bump because I thought it warranted an explanation.

This release has no javascript api changes so you can probably upgrade without any issues. The version bump is because of this pull request: #9.

This major version bump was the result of removing module from package.json:

-   "module": "src/index.js",

module is used to expose raw es6 sources for bundlers. It seems like the main use case for using module is to allow removing duplicate imports via tree shaking. A few problems with module in memoize-one:

• The file itself was the raw source file. This meant that it would require the consumer to have the correct environment or babel setup for the file to be parsed correctly. This would mean that consumers would need and environment that supported: babel-preset-es2015, babel-plugin-transform-object-rest-spread and babel-plugin-transform-flow-strip-types.
• The file contained flow types. This is similar to the previous issue where it forced consumers to have the correct babel plugins set up. If you where not using the strip-flow-types babel plugin then your build would throw errors.

My thoughts on what would be the ideal module: compiled es5 source with es6 imports.

Given that memoize-one has no dependencies there is no tree shaking advances in exposing it through module.

Given that some people may have been explicitly relying on using the module in memoize-one previously I have made it a major version bump to remove it. While I expect that most module bundlers would have simply switched to main with no issues - I wanted to be really safe and just do a major version bump. I think that module is a public api and removing it therefore constitutes a break in api.