4 ms·
With this one, you can write granular shared states (multiple "entities") without creating layers and layers of Context Providers in your component tree. Since
by aenero 6y ago
With this one, you can write granular shared states (multiple "entities") without creating layers and layers of Context Providers in your component tree.
Since data is not encapsulated inside React component tree, I found it to be multiple times faster than when using Context.
And one thing that's perhaps the most obvious... it's simpler because you don't have to use Providers at all.
- jeswin 6y ago> Since data is not encapsulated inside React component tree, I found it to be multiple times faster than when using Context. What do you mean by data being encapsulated in the tree? How does that make it slower?
- aenero 6y agoMaybe "encapsulated" is not the right term when I simply meant "scoped". I tried scoping the entities using Context in some prior art which we use in production. Some colleagues kindly gave me some benchmark results and the version without Context (external/module-scope) was faster. I'm not trying to debate against Context here. In fact, there's nothing that would stop anyone from using SimpleR State's entities with Context API.
- jeswin 6y agoNot that I'm a fan of Context (or even React); but without publishing the benchmark code or specific technical arguments, it's hard to support a claim about slowness or of speed.
- aenero 6y agoYup agreed. That's why I stated it as "I found it to be...", coz I'm not trying to convince everyone else LOL. It's never my intention for this library to try and be the "best" out there. I simply want to create what I sought for, which is the closest to the simplest approach I can think of. And to share it to the public, in case someone out there is looking for the same thing I am, and maybe it could help that someone. That's what open source is for, after all.
- sdfhbdf 6y agoThanks for the answer. > multiple times faster than when using Context Oh cool! Do you have some benchmark results for that? Would be awesome to post them in the README if you can. > simpler because you don't have to use Providers at all I think the Provider pattern is part of the functional programming pattern with React, so while I do agree it might be harder to get used to but it underlines the no side-effects affecting the state of a given React components and its children. At scale proper action, reducer pattern is helpful to manage a complicated state tree to still make it functional, easily testable and giving the same end result as a function of state.