-
Notifications
You must be signed in to change notification settings - Fork 361
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
_Platform_gatherEffects can throw runtime exception - Maximum call stack size exceeded #1123
Comments
Thanks for reporting this! To set expectations:
Finally, please be patient with the core team. They are trying their best with limited resources. |
How deep of a nesting are you talking about? I thought current browsers typically allow 10,000-30,000 levels of stack calls. Do you have thousands of updates you're composing, or is this happening with just tens or hundreds of nesting levels? |
Also note that: andThen :
(model -> ( model, Cmd msg ))
-> ( model, Cmd msg )
-> ( model, Cmd msg ) is not a describing monad. As you can see it's |
Elm 0.19.1
This function is not tail recursive when working with a nested
Cmd.batch
. Large flat batches are ok, since a for loop is used to iterate those.https://github.com/elm/core/blob/master/src/Elm/Kernel/Platform.js#L273
Workarounds:
Cmd.batch
that keeps the batch flat, and gets transformed into aCmd.batch
later one, once the whole batch has been built.===
It is conventient to use an update monad like this:
When operating over a large number of update functions, which are written in this style:
It can be convenient to create a larger update by folding over a list of smaller ones, like this:
Even if the smaller
someUpdate
functions returnCmd.none
, a large nestedCmd.batch
will be created.This can be fixed by avoiding using this style of programming, but it seems a shame to not allow it.
Solutions:
Cmd.batch
a bit smarter, by having it flatten any nested batching.The text was updated successfully, but these errors were encountered: