What would you say that $effect.tracking is for?

[webJose]

Describe the bug

I'm writing this as a bug, but perhaps it is not. Long story short: $effect.tracking() returns false during component initialization, but during component initialization, effect placement is valid. Up to 1 minute ago, I have always thought of $effect.tracking() as the one tool I need to know if an effect can be set up. This discovery has shaken this knowledge away from me.

If this is not a bug: Would you still say that $effect.tracking is the only tool at our disposal to safely set effects up? Because then how do we detect component initialization?

Reproduction

Not needed, I suppose?

Logs

No response

System Info

REPL

Severity

annoyance

[brunnerh]

It's there to detect whether the calling code expects reactivity or not and tracking whether any code is still actively "listening". This is mainly useful for code extracted to separate modules.

An example would be the implementation of a start/stop notifier as found on the readable store.

Example of an auto-updating Date state:

import { tick } from 'svelte';

let subscribers = 0;
let handle;
let value = $state(new Date());

export const date = {
  get current() {
    if ($effect.tracking() == false)
      return new Date();

    $effect(() => {
      if (subscribers++ === 0) {
        console.log('starting interval');
        handle = setInterval(() => value = new Date(), 1000);
        value = new Date();
      }

      return () => {
        tick().then(() => {
          if (--subscribers === 0) {
            console.log('stopping interval');
            clearInterval(handle)
            handle = null;
          }
        });
      };
    });

    return value;
  }
}

Playground

[webJose]

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 says it isn't. Bug or not?

[brunnerh]

There is no tracking during component initialization, that would cause all sorts of problems, so this should be correct.
(There is a bug though, that $effect.tracking() returns false in the template.)

[webJose]

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

[brunnerh]

I would say that is mostly an issue of intent and documentation.

Some effects are intended to live outside of component lifecycles, so they require their own $effect.root.
Other effects should be coupled to the calling component, in those, the calling code has to treat the function like an $effect call: It is only allowed to appear in places where $effect is allowed.

E.g. I also always document functions that internally use setContext/getContext with "has to be used during component initialization". Even if I could detect whether the code is running during initialization or not, there would not be any way to make the code behave in a sensible way: Without context access it would just be broken.

[webJose]

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?

A custom module should be able to set an effect up:

class MyClass {
  #someState;
  constructor() {
    if (<something that can tell me I can set an effect up>) {
      $effect(() => ... );
    }
  }
}

[brunnerh]

What would you do with that information?
Would your class still function as intended without the effect?

If you give a more concrete example of what you are trying to do, it might be easier to determine whether the API is missing something here.

[webJose]

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 the class could still function as a store without the effect.

[brunnerh]

That seems like a case where you could also check $effect.tracking() only on access, rather than setting up an $effect immediately.

[webJose]

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?

[brunnerh]

If the value is only accessed once, e.g. in a click event, you don't need an $effect to listen to events but can just get the current value.
If the value is added somewhere in the DOM, you can use the $effect to subscribe to the event and keep it updated & unsubscribe when it's no longer necessary.

If I understood what you are trying to do incorrectly, please give more detail.

[webJose]

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 cases like that.

Still, moving the effect to the accessor is like 2 orders of magnitude more difficult than simply setting it up in the constructor. One has to count subscriptions and do getters and setters. All this can be avoided if there was something that could let me subscribe the effect on component initialization.

As it stands right now, it seems that the workaround (because it fells like one) is to go the complex route where one subscribes on value access.

[webJose]

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 just one effect during component initialization.

[webJose]

Look how simple things would be if Svelte gave the ability to set an effect up during component initialization:

// createStore.svelte.js
export function createStore(initialValue, componentInitializing) {
	const store = $state({ value: initialValue });
	if (componentInitializing || $effect.tracking()) {
		$effect(() => {
			console.log('Value: %o', store.value);
		});
	} 
	else {
		console.log('Not tracking.');
	}
	return store;
}

// App.svelte
<script>
	import { createStore } from './createStore.svelte.js'

	// Manually providing the missing part of the puzzle:  Because I, the dev, know this code is in
	// a script that initializes a component, I tell the function it is OK to set the effect up.
	let count = createStore(1, true);
</script>

This works. So my point here is: I think either $effect.tracking() should return true during component initialization, or there should be another API that accurately tells us whenever we can safely set effects up.

[webJose]

// createStore.svelte.js
export function createStore(initialValue, componentInitializing) {
	const store = $state({ value: initialValue });
	if (componentInitializing || $effect.tracking()) {
		$effect(() => {
			console.log('Value: %o', store.value);
		});
	} 
	else {
		// Maybe if the store cannot function without the effect, we can set up here with $effect.root.
		// Consumers would then need to know that there is some disposal needed to be done.
		$effect.root(...);
	}
	return store;
}