Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reactive block not being evaluated again on internal change of variable #6118

Closed
atava opened this issue Mar 23, 2021 · 3 comments
Closed

Reactive block not being evaluated again on internal change of variable #6118

atava opened this issue Mar 23, 2021 · 3 comments

Comments

@atava
Copy link

atava commented Mar 23, 2021

Reactive statements/blocks don't seem to be "recursive" (so to speak).
When a reactive block checks for a condition to apply and the condition changes within the reactive block itself, the condition is not rechecked.

See this REPL:
ScreenClip

At component's creation, the reactive block is evaluated and count is assigned itself plus 1.
But then after this assignment it doesn't go on checking if count is less than 10 and increment it accordingly (which is what I was expecting).
Assigning to count outside the block through the button makes the block run again (and count is added twice, one because of the handler and one because of the block).

I don't know if this is the expected behavior (that's why I'm writing this as a question and not as an issue), but I would have expected (and wanted) the reactive block to be evaluated any time that count changes, be it outside the block or within it.

Maybe a variable is not deemed a dependency of a block if it's also among its performed assignments? (e.g. $: count += 1 doesn't work either, while I would have expected it to stack overflow).

Thanks.

@Mlocik97
Copy link
Contributor

REPL seems to work correctly for me. As designed.

@Conduitry
Copy link
Member

This is the intended behavior, although it is indeed a TODO to find somewhere to document this better. The short answer is that synchronous changes to variables during reactive blocks do not trigger another a run through the reactive blocks afterwards. It's not precisely the question you're asking here, but I talk a bit about what's going on in this comment.

@atava
Copy link
Author

atava commented Mar 24, 2021

Your explanation about synchronous code in reactive blocks matches what I found on a stackoverflow question about using setTimeout() for another use case. Putting it here makes the block "loop" as I expected, too.

Yes, I think that currently the biggest drawback for me in using this technology is lack of detailed documentation (both the tutorial and API docs are fine, but we're programmers and rather than the "do-this-to-have-that" sort of bits I'd like to know exactly what happens when I write code).
Thank you for the answer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants