José Pablo Ramírez Vargas

Thanks @MrAmericanMike but that's the same thing but on keyup.

That would be an interesting approach, but unsure how it would play in the TypeScript world. The idea of this function is probably simpler to achieve. I just need the...

If you guys go for this (which I would love to see), may I also ask for an `isComponent()` function? Just to complete the set. 😄

Thanks. What is your opinion about the fact that `$effect.tracking()` returns `false` when called from component initialization, then? It is a place where reactivity can take place, yet the function...

Ok, so is there a way to safely set effects up during component initialization? I mean, from non-component modules such as custom stores.

> It is only allowed to appear in places where $effect is allowed. Well, component initialization allows $effect. Yet, I have no way of knowing/asserting this. Or am I misunderstanding?...

Yes, for example, saving to local or session storage. Imagine the class needs to set the effect up for this. Also subscribing to the `'storage'` event (and then unsubscribing). But...

> That seems like a case where you could also check $effect.tracking() only on access, rather than setting up an $effect immediately. Can you elaborate on the reasons behind this?

Whether is accessed here or there, once or twice, should not matter to the conversation about the general availability of information, I think, but I suppose that yes, there are...

Also, I just thought about performance: The subscribe-on-read approach sets one effect up per read operation. What if the value is read thousands of times? When I could have had...