Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ShouldComponentUpdate-like behavior for store #185

Open
ciaoben opened this issue May 20, 2020 · 2 comments
Open

ShouldComponentUpdate-like behavior for store #185

ciaoben opened this issue May 20, 2020 · 2 comments

Comments

@ciaoben
Copy link

ciaoben commented May 20, 2020

I was wondering if there is a way to obtain a "componentShouldUpdate"-like behavior for store edits.
From what I understand if I set a value on the store the render is trigger even if the new value is the same as the old value, is there a way to avoid it?

// current store situation store = {test: 2}
store.test = 2 // -> will trigger re-render
@solkimicreb
Copy link
Member

solkimicreb commented May 20, 2020

From what I understand if I set a value on the store the render is trigger even if the new value is the same as the old value, is there a way to avoid it?

It won't re-render if the value did not change with a strict equality check (===). See this minimal repro (just spam the reset button a few times).

You can also use raw() from the underlying @nx-js/observer-util package to update/read the store without the added reactivity but we don't promote that a lot because it is a low-level API.

import { raw } from '@nx-js/observer-util';

// this re-renders everything that uses `myStore.prop`
myStore.prop = 12

// this does not re-render anything
raw(myStore).prop = 12

You also have the option to use shouldComponentUpdate or memo in your component and do complex store comparisons there.

And we may add some low-level hooks in the future to handle this use-case. We will add a couple of low-level hooks for stores in the very next release which can intercept default language and reactivity behavior. I will think about adding a hook for this too. These will be part of the public and documented API but they will be mainly intended for library authors and for devs how would like to build custom solutions on top of easy-state.

@ciaoben
Copy link
Author

ciaoben commented May 20, 2020

Great! Thanks for the explanation! It is really a great library. We use it on a big application and the only problem it is to understand what changes triggered the re-render of a specific component.
I am looking forward for the next release to be able to hook on a console.log debugger to better debug re-renders!

Thanks for the great work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants