-
Notifications
You must be signed in to change notification settings - Fork 3
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
WIP: Allow statify to be coerced to primitive #8
base: master
Are you sure you want to change the base?
Conversation
OK pretty good. I like this feature. I added some technical debt: the coreProxy returned for proxify is wayyy different than the one for statify and it no longer makes sense to share the same functionality. I think we should break up coreProxy into individual traps and have the proxy generation actually occur in the proxify, statify functions. This feature, along with directly setting values on statify, will allow for some pretty cool behaviors:
|
If you'd like, we can even add an immutable array function library to allow shit like: const state = statify({ a: ['Y', 'M', 'C' ]});
state.a.push('A');
console.log(state.a.join(''));
// YMCA |
Hey, Tyler! Welcome back! 🙂 🙌 This is a tough one! I've been wanting the [toPrimitive] thing for long, and I love the setting part: But lately, I had some doubts:
Generally, when calling I don't really know how to mix this feature with proxify well (speaking API-wise, no clue how it would be implementation-wise). I'm dubious. What do you think about all this? P.S.: and I really like the |
I absolutely agree with you on most points and was actually thinking that this functionality could be a separate function from statify, maybe even a different package altogether, with only the direct access and direct setting ability. Partly to disambiguate from proxify and partly because there's no need to pollute the consumer's namespace with properties like I could see many people particularly being frustrated by const state = statify({ creditScore: { description: 'Excellent', value: 750 }});
state.creditScore.value.subscribe(() => console.log('Your credit score has changed')); // <-- error RE array properties: arr.length in statify should still return a statify object, or whatever we call it, that can be coerced to a number: RE properties like toString and valueOf: You see how I handled the date object valueOf, I was actually already thinking about opening that up so that every property returns the [Symbol.toPrimitive]: () => readValue()[Symbol.toPrimitive], That would allow consumers to define custom coercion behavior: const state = statify({ a: { valueOf() { return 5; } });
console.log(+state.a); // 5; RE folding: Coercing the statify object to a primitive does not fold the actual observable, it just retrieves a value from the current state: const state = statify({ a: { b: 3 }});
const subState = state.a.b;
console.log(+subState); // 3
// Despite coercion, the substate still retains observable properties
subState.subscribe(() => console.log('Subscribed!')); // Subscribed! |
Hey, Tyler! Really sorry for not responding this long. The end of the year is a bit tense... 🙂 Each time I return to this PR I get mixed thoughts: on one hand, I like this simplification of handling primitives. On the other hand, I'm afraid that under-the-hood conversion from statify to proxify will confuse users, e.g. On the second another hand (yep, this situation is partially confusing due to three hands involved 😅) you've raised another very important question of accessing There, just wanted to clarify this before the year ends 🙂 HNY! 🎊 |
You mentioned in the comments that it would be cool if
statify
allowed direct access to itsBehaviorSubject
's value.So far, this allows direct access to strings and numbers by coercion. Typescript allows this through intersection types.
I'm not quite sure how to proxy [Symbol.iterator] yet to allow for direct access to array properties, but I think it's possible. I added some notes in the test cases.