Svelte: Question: Reactivity not triggering when variable changed in a function ?

[Fygo]

EDIT: I just realized this actually reproduces in REPL, so here I go writing this up again...

I have a problem I can't seem to figure out and I am not quite sure where to look so I am bit lost.

Let's assume I have something like this: https://svelte.dev/repl/1df2eb0e67b240e9b1449e52fb26eb14?version=3.25.1

You can see that changing the "value" prop of the Comp.svelte instance:

1. triggers the reactive statement if condition which then calls updateInputValue(value)
2. that then sets the inputValue...
3. ... and NOTHING. The reactive statement validate(inputValue) is never executed.

When I omit the updateInputValue(value) call in the reactive if condition and just put this function's content directly into the condition, then the validate(inputValue) fires as expected. So it seems like the reactivity is not triggered when updateInputValue function changes the variable. But why?

Any ideas? How should one debug this? What am I doing wrong? Thanks for any comments.

[antony]

Hi @Fygo

We reserve github issues for bugs and feature requests for Svelte, since it's a pretty bad tool for realtime support.

However, feel free to come and chat to the community and maintainers on discord to see if we can help you diagnose and fix your issue.

[Fygo]

@antony Sorry, let me rephrase. Is this how it is supposed to work? Because right now it looks like a bug. The documentation is really terribly sparse on this topic.

Why I think it is a bug:

1. The HTML input text element is updated (i.e. it reacts to the bound inputValue) but the reactivity stops there, not calling the reactive $: validate(inputValue) when inputValue changes
2. Unluckily the discord server provided basically 0 feedback but SO did and it was found that changing the position of $: validate(inputValue) AFTER the function declaration works (actually, after the reactive if condition). Here is the fixed REPL: https://svelte.dev/repl/4dce7d79a41d4251960257bc1b2feb33?version=3.25.1

Is this really the intended behavior? Is the placement/position of reactive statements important in this case? If it is, it should be pointed out somewhere.

HOWEVER: why is the position not important when the reactive if condition doesn't call the function but instead contains the function's code? It makes no sense.

[johannchopin]

Hi @antony 👋

As you can see in this stackoverflow Q/A, nobody can really explain the behaviour of this code snippet and it really looks like a bug if there is nothing mentioned about it in the doc. For sure @Rich-Harris knows why it behave like that 😉 Thanks a lot for all your work guys 👏

[tanhauhau]

@johannchopin @Fygo i've explained the issue in the stack overflow. have a nice day.

[Florian-Schoenherr]

So we now need to order reactive statements?

[Fygo]

@Florian-Schoenherr Have you read the answer on SO? If not, give it a read, definitely worth it.

But basically yes, the easiest is to order them if you hit the same issue.

I still cannot get over the fact that this is not mentioned in the documentation. I do not want to sound negative or unappreciative towards the work that went into this tool (because it has many awesome parts and awesome people working on it and contributing to it), but I do feel kind of let down that "basic" internal mechanics are not explained at all. You either have to find them out yourself or hope some other programmers did and wrote an article about it. @antony Some advanced section in the docs would be really nice.

[Florian-Schoenherr]

Yes I did read it, and I essentially thought there is no ordering in reactive statements, because it orders based on dependencies.
I hope there is some kind of pattern to keep it that way, do you @tanhauhau know of a way to make the SO example use dependencies to order?
Would

$: if (rendered) {
  updateInputValue(value);
  inputValue = inputValue; 
}

work?
@Fygo I think you can reformulate this issue to "please mention this in the docs", I had some versions of the same problem before.