See this use case:
Let's say we have these props:
{
items: [{ id: 1, name: 'foo' }, { id: 2, name: 'bar' }],
hiddenId: 1,
someOtherVeryComplexObject: { ... },
}
And we want to do something like this:
withPropsOnChange(
(props, nextProps) => {
const subset = ['items', 'hiddenId']
// Lodash 'isEqual' provides deep comparison
return !_isEqual(_pick(subset, props), _pick(subset, nextProps))
},
props => ({
itemsWithoutHidden: _filter(({ id }) => id !== props.hiddenId, props.items),
})
),
It would be nicer to write it like this:
withPropsOnDeepChange(
['items', 'hiddenId'],
props => ({
itemsWithoutHidden: _filter(({ id }) => id !== props.hiddenId, props.items),
})
),
I'm happy to make a pull request for this, but let's see first if other people find this valuable too.
Hi,
In most cases you can avoid using deep equality checks, just operate with your data in immutable manner. IMO even we all use deep equality checks sometimes I can say that for me it's really rare operation, so two-three additional lines like in your first example is not a big code overhead vs just withPropsOnDeepChange.
Also this suggestion is somehow similar to this https://github.com/acdlite/recompose/pull/120
just operate with your data in immutable manner
You mean that as long as I only do reassignments when data actually changes, object references will stay the same and will pass shallow comparison? Why didn't I realise that before :')
Edit: haha, I just realized the real power of immutability, after using it for almost a year. Mind blown.
Most helpful comment
Hi,
In most cases you can avoid using deep equality checks, just operate with your data in immutable manner. IMO even we all use deep equality checks sometimes I can say that for me it's really rare operation, so two-three additional lines like in your first example is not a big code overhead vs just
withPropsOnDeepChange.Also this suggestion is somehow similar to this https://github.com/acdlite/recompose/pull/120