Looks interesting... One critique is "light/tiny/lightweight" whenever I read about software being "light" I cringe and get an eye-twitch(ok not really). But adding "light" or claiming your product is "light" means usually nothing other than its new . Sure it might start out as small/lightweight but usually this is because the software is new . Once you start adding in corner-cases (the ones you haven't even thought…
Show HN: A tiny and fast reactive observables library via functions
11–20 of 41 posts
Re: Show HN: A tiny and fast reactive observables library via functions
#12Re: Show HN: A tiny and fast reactive observables library via functions
#13Re: Show HN: A tiny and fast reactive observables library via functions
#14Couldn’t read only be replaced with wrapping an observable in a closure?
const $a = $observable(42)
const $b = () => $a()
IMO “use after dispose” should crash to make it easier to detect bugs. Also dispose should error when it texts a request to dispose something that still has a dependency. It is unlikely this is intended as it would likely lead to a “use after free” or memory leak.
Re: Show HN: A tiny and fast reactive observables library via functions
#15Looks interesting... One critique is "light/tiny/lightweight" whenever I read about software being "light" I cringe and get an eye-twitch(ok not really). But adding "light" or claiming your product is "light" means usually nothing other than its new . Sure it might start out as small/lightweight but usually this is because the software is new . Once you start adding in corner-cases (the ones you haven't even thought…
Re: Show HN: A tiny and fast reactive observables library via functions
#16I don’t understand the purpose of effect. Seems like compute can be used in all cases since you can dispose compute as well. Couldn’t read only be replaced with wrapping an observable in a closure? const $a = $observable(42) const $b = () => $a() IMO “use after dispose” should crash to make it easier to detect bugs. Also dispose should error when it texts a request to dispose something that still has a dependency. It…
Not OP, but:
- You could just use computeds instead of effects, but:
- Effects don't have an internal observable, so they are cheaper to make and to keep in memory.
- If OP will implement something like Suspense they'll probably want to pause the execution of effects, but not the execution of computeds.
- OP didn't implement this, but potentially you could support returning a cleanup functions inside effects, you can't do the same for computeds.
> Couldn’t read only be replaced with wrapping an observable in a closure?Yes, internally it's probably just a `$computed( $observable )`. The differences are that one is just a function and the other is an observable, which is a detectable difference that may matter, but also potentially the utility function could return you always the same observable if it has already a reference to a read-only version of the one you give it, which may consume less memory (1 function to keep around rather than N), though this is a bit of an edge case.
Re: Show HN: A tiny and fast reactive observables library via functions
#17Re: Show HN: A tiny and fast reactive observables library via functions
#18Add me to the list of people who've made their own "tiny" observable js lib (https://github.com/kevinfiol/vyce). Albeit, this one looks more complete.
Re: Show HN: A tiny and fast reactive observables library via functions
#19I poured over several state management libraries before just deciding to write a naive solution on my own. I've got a very simple stateful class - the data model itself is private, and it has a custom getter/setter for access. The setter broadcasts a custom event for each top-level key that changed.
Super simple, easy to understand, and the limitation forces me to keep my state as shallow as possible.
Am I missing something? I expected to run into trouble but so far it's been easy breezy.