I have some code like this:

    createEffect(() => {
        props.dynamicFeatures;      
        updateDynamicMapLayers()}
    })

Here, updateDynamicMapLayers() is a throttled function that seems to break Solid's automatic dependency checking.

This code works, but I've been told this isn't a good idea, without a clear reason. I'm told I should use this somewhat clunkier version:

createEffect(
    on(() => props.dynamicFeatures, updateDynamicMapLayers),
)

Is there any particular problem with the first way?

I have some code like this:

    createEffect(() => {
        props.dynamicFeatures;      
        updateDynamicMapLayers()}
    })

Here, updateDynamicMapLayers() is a throttled function that seems to break Solid's automatic dependency checking.

This code works, but I've been told this isn't a good idea, without a clear reason. I'm told I should use this somewhat clunkier version:

createEffect(
    on(() => props.dynamicFeatures, updateDynamicMapLayers),
)

Is there any particular problem with the first way?

• solid-js

1 Answer 1

From the on docs:

on is designed to be passed into a computation to make its dependencies explicit.

createEffect(on(a, (v) => console.log(v, b())));

// is equivalent to:
createEffect(() => {
  const v = a();
  untrack(() => console.log(v, b()));
});

So it's mostly a matter of style. I'm not sure, but Solid might also not give any guarantees that your first version will continue to work. Accessing the props.dynamicFeatures signal without using the value might be optimized away in a future update.

If you don't like on, why not change your function to be explicit in its input? Like: updateDynamicMapLayers(props.dynamicFeatures)