-
Notifications
You must be signed in to change notification settings - Fork 15
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
Better detection of forbidden recursive update steps #10
Comments
I've just hit I got around it using
What are pro and cons of doing this compare to delaying the update with |
You mean |
yes |
Sorry forbidden. |
When saying
is forbidden ? |
No this should be right. The rule is very simple: you just need to yield at the end of the update cycle if you want to update a primitive/create a new step. It is actually even better if you yield any side effects to the concurrency library, as this makes a good separation of concerns (purely functional reactive logic/effects on the world). I think that |
In general it is not allowed to update primitives from an update step. If this happens and two update steps get intermingled it seems we get assertions errors from
react.ml
which lead to believe there's a bug in react itself. Can we report better errors while keeping react free of any global data structure ?Besides better guidelines should be provided on how to avoid that. I think the best way of handling this is through interaction with a monadic concurrency library. Instead of having side effecting events at the outputs of the reactive system we should convert occurences to futures and that future representing the occurence should always and unconditionally immediately defer/yield which will bring the update step to an end (rather than the update step potentially continuing to execute in the future value which may trigger primitive updates and blow the whole system).
The text was updated successfully, but these errors were encountered: