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

Performance Tradeoffs? #17

Open
RobMaple opened this issue Jan 3, 2020 · 6 comments
Open

Performance Tradeoffs? #17

RobMaple opened this issue Jan 3, 2020 · 6 comments

Comments

@RobMaple
Copy link

RobMaple commented Jan 3, 2020

Are there any performance tradeoffs in using this library? At first glance it seems like wrapping your app with the subscribe function will rerender the whole app on any update which as far as I'm aware means it will at least miss out on any perf benefits of using React's native state (batched updates for instance).

@gunn
Copy link
Owner

gunn commented Apr 22, 2020

Hi @RobMaple sorry, I missed your comment somehow.

Many smaller apps in the react world will actually render the entire app every update which is possible because react's v-dom diffing means it only updates the dom nodes that actually change.

I wouldn't do this though - instead I'd use React.memo to only re-render components when their props change (or if they have internal logic that triggers it). Because pure-store updates data immutably, it's a perfect match for this approach. If you are not currently using React.memo, you are probably re-rendering large parts of your component tree unnecessarily.

So to answer your question: no, no tradeoffs, the performance story is excellent. The most simple use of this library gives you efficiency you have to fight for with many other approaches.

By the way, I've just released a new version which gives you a usePureStore hook to make use with react even easier.

@RobMaple
Copy link
Author

Thanks, will take another look.

Out of interest, is there any equality checks that could be built in to the pure-store hook so as to only fire 'setState' when necessary?

@gunn
Copy link
Owner

gunn commented Apr 23, 2020

setState in src/react.ts is the equality check - and it's just a very fast == check which works because of immutability.

We also have a test to make sure that re-renders don't occur unnecessarily - https://github.com/gunn/pure-store/blob/eea8a8e14c81/src/react.test.tsx#L217

@RobMaple
Copy link
Author

Ah ok, that makes sense.
On a side note though, I've just been trying out a very basic implementation (essentially the same code in the documentation) and it's causing every component that is using the hook to render twice. I presume this isn't correct?

Heres a sandbox illustrating the issue: https://codesandbox.io/s/condescending-browser-9hihf?fontsize=14&hidenavigation=1&theme=dark

@gunn
Copy link
Owner

gunn commented Apr 24, 2020

Hi Rob, thanks for investigating and making a nice demo, I really appreciate it.

I looked into it a bit, and the cause is wrapping the app in React.StrictMode - it does this without pure-store too.

The idea seems to be to double render to catch bugs from render side-effects - https://reactjs.org/docs/strict-mode.html#detecting-unexpected-side-effects

@RobMaple
Copy link
Author

Ah! Sorry, completely missed that. Just fired up a codesandbox default react app, didn't realised it used Strict Mode. Thanks for taking a look!

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

No branches or pull requests

2 participants