v5.2.3

New feature - development only

You can now navigate through the history of changes to the store with the below functions (in your DevTools console):

• __RR__.back() will go back to the state before the last store change.
• __RR__.forward() will go forward again.
• __RR__.goTo(index) will go to a particular index in the history.
• __RR__.getHistory() will log out the entire history.
• __RR__.clearHistory() clears the history.
• __RR__.setHistoryLimit(limit) limits the number of store instances kept in history. Defaults to 50. Setting to 0 disables time travel. Is stored in local storage.

If you update the store with initStore or execute multiple updates within the batch function callback, those changes are recorded as a single history event.

v5.2.2

Updates to collected components are now batched into a single render. This boosts performance in some cases, for example if all of these are true:

• a parent and child component are both wrapped in collect
• the parent passes props to the child
• a change in the store triggers an update on both components
• the change is such that the props passed from parent to child are also updated

v5.2.0

New stuff

• Recollect now exports PropTypes, a replacement for the prop-types library. This ensures that Recollect ignores reads from the store that occur while React is checking prop types.
• getListenersByComponent() and getComponentsByListener() helpers for better debugging in the console.

Improvements

Webpack has been replaced with Rollup, and there are now CommonJS, ES6 modules, and UMD builds - each with a separate prod and dev build. Dev builds contain better errors and the two new helpers mentioned above.

Builds are now smaller in many cases. For example, if a project already has @material-ui/core, adding Recollect is only 3 KB instead of 5 KB.

Bug fixes

• Previously, reading from the store using the in operator (e.g. if ('title' in store.page) ...) inside componentDidUpdate would result in reads for the 'previous' store being routed to the current store.

v5.1.4

A minor tweak to have the batch function execute synchronously.

v5.1.3

The release adds a warning if a user tries to pass part of the store from one collected component to a child collected component. More: https://github.com/davidgilbertson/react-recollect#how-many-components-should-i-wrap-in-collect

v5.1.2

This release fixes an issue with Recollect not recording store reads for a collected component that has PureComponent or React.memo() children when those children are skipped by React during an update.

v5.1.1

This release fixes an issue with <React.StrictMode> in development. Strict mode executes a component's render method multiple times, which was logging "You are attempting to modify the store during a render cycle" errors to the console.

v5.1.0

New feature

• The new useProps function lets you tell Recollect that your component will be using a prop in the future. More: https://github.com/davidgilbertson/react-recollect#usepropsproparray

Improvements

• This release tightens up the logic for selecting which components to re-render for any given change. This results in fewer unnecessary renders.

Bug fixes

• Previously, prop type checks were being counted as 'reads' for a component, potentially creating far too many subscriptions for components. This was only an issue during development, but it meant dev/prod could have different behaviours.

v5.0.0

Version 5 brings a major change to the way the Recollect store works, making it almost identical in behaviour to a normal JavaScript object (the only difference being that the Recollect store is immutable under the hood).

New stuff

• It should now be impossible to read from the 'wrong' store. You can refer to the Recollect store via props.store in a collected component, or import {store} from 'react-recollect'. Previously, attempts to read from the imported store inside a collected component was an error. This also means you no longer need to pass props.store to a selector.

Breaking changes

• The prevStore property has been removed from the event passed to an afterChange callback. If you would like to compare to the previous store, you will need to track this yourself.
• Any code that relied on (or worked around) the Recollect store behaving differently to a plain JS object will probably break.

Fixed

• #71 - sorting in Node.js 10 was unpredictable
• #83 - getting a reference to an object in the store, then deleting its parent would make that object unreachable.
• Generally, any behaviour where the Recollect store exhibited different behaviour to a plain JavaScript object should now be gone.

v4.0.4

Fixes an issue with a collected component's componentDidUpdate receiving an already-updated version of the store as the prevProps arg when that component had child components wrapped in collect.