Comments (11)
if you can implement your lib without proxies that easy, you wouldn’t need proxies from the start, would you? That might be simpler.
from hookstate.
Thanks for the note. I have though about it and the original version was similar to the one without proxies. The difference with proxies and polyfill is documented at the end of this section.
Mainly proxies are lazily evaluated, polyfill is not lazy, it constructs nested object on get of a property. It is a trade off. Lazy is usually faster when only a segment of a state is consumed (most frequently the case with global states). If a user wants to drop proxies and speed up things, for example for JSON.stringify(state.get())
, it is easy to do so with the Degraded
plugin JSON.stringify(state.with(Degraded).get())
. .with(Degraded).get()
basically means all the properties (including all deeply nested one) are used from the usage tracking point of view, but proxies are not involved.
Secondly, proxies trap set() properly and block setting the value in the state directly (with an exception for symbol properties, which is frequently used by plugins). The exception is thrown and a hint message is shown to a user suggesting to use state.nested.prop.set(newvalue)
instead of state.get().prop = newvalue
. Polyfill does not trap the set method.
And thirdly, proxies allow to create state links for properties which are not defined on the target object. Polyfill does not have this functionality. More on this use case see the documentation for nested
property of the StateLink
.
Construction of proxies is only few lines of code in the library, so not a big deal from the complexity point of view.
I see the above is quite a good justification to have proxies. What do you think?
from hookstate.
The first point is about performance. The second point can be replaced with Object.freeze(), but it's a preference. The third point is probably the most important I missed. I wasn't aware your lib supports adding a new property on demand.
Overall, fair enough.
from hookstate.
Hi, I read your code a little bit more (unfortunately I don't fully understand it, but at least I understand, it's based on mutation like MobX), especially your ProxyPolyfill.
There was a misconception in our previous discussion.
What I propose is to use object getters instead of Proxies, and you can keep laziness.
The intuition behind this proposal is I learned that object getters is faster than Proxies.
If you are keen about performance, using object getters would improve it. (and you don't need polyfill.)
(and I'm interested in hearing the result
from hookstate.
from hookstate.
What I mean and expect is that you can keep the same API with object getters without Proxies.
So, state.nested.prop
won't change.
I might be wrong, but that's what I understand.
from hookstate.
from hookstate.
My assumption is that you already know what v
will be. I mean, the precise type of v
, not like string
.
from hookstate.
from hookstate.
Oh, now I get the point. Then, object getters won't work.
Thanks for the clarification again.
This just a random thought, but if I were to design API without Proxy (tbh, I would like to avoid it whenever possible), I would probably do state.nested(new_prop, new_value)
, but this might confuse people because it also allows state.nested.existing_prop
.
from hookstate.
New library api towards version 2: https://hookstate.js.org/docs/getting-started
Currently there are no plans to get rid of the proxy.
from hookstate.
Related Issues (20)
- Destructure State object to proxy-free plain JavaScript object HOT 4
- Prevent HOOKSTATE-111 exception being raised during Vite and NextJS HMR HOT 9
- Challenges updated nested values (proxy error) HOT 1
- Typescript error when defining a state with OR operator HOT 5
- Localstored raise type error at 4.0.0 HOT 2
- Partial Updates (Scoped State) with Classes HOT 1
- Array management hits call stack limit HOT 2
- `State.nested` does not work with `symbol` keys HOT 4
- Array.splice() does not work as the docs suggest, at least according to TypeScript HOT 2
- Subscribe extension type error defined types HOT 1
- Example with zod? HOT 1
- Any showcase how to work with Immutables? HOT 2
- Resource leak with `useHookstate` HOT 2
- Is this lib still being updated? HOT 3
- Request: throw error when trying to assign nested state to a Proxy object HOT 2
- Migration from 3 to 4 HOT 4
- Localstored - optional initializer HOT 1
- https://hookstate.js.org/docs/exceptions/#hookstate-106 is killing me HOT 1
- What is the meaning of `E` in State<S, E>? HOT 1
- Injecting React-Router-dom instance into the store HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from hookstate.