I think I’ve found a bug in the way Elm 0.19 diffs the
Model to determine whether to call
subscriptions or not. But need help refining my understanding of the problem before I try to file an official bug report. Hoping somebody out there can help…
I found it while trying to convert one of the first programs I wrote to 0.19.1 from 0.18. This code used a conditional subscription to
Time.every to determine when to stop an animation (which was achieved just by changing the CSS class of the element). It’s not the way I would do it now, I’d just use andrewMacmurray/elm-delay (which uses
Process.sleep under the hood). But back then it was the only way I knew to do it, and was indeed the way recommended to beginners — and probably would still be what a beginner might reach for today.
Anyway after converting to the 0.19.1 and the new elm/time I found the animation wasn’t stopping. I’ve made a minimal example here…
The animation should stop after 1-2 seconds. You should then be able to restart it by clicking on the square, after which it should play for 1-2 seconds again. What actually happens under 0.19 however is that the animation doesn’t stop until you click on the square. Looking at the debugger, you can see that for some reason the subscription to
Time.every isn’t firing at all until another click is made. It’s almost as if Elm doesn’t think the model has changed and so doesn’t reprocess the
So I tried to make the example even simpler and came up with this:
The count should go up one or two counts then stop. You can then get it to continue for another one or two counts by clicking on “Continue”. Strangely this now almost works except that the initial counting (and initial subscription to
Time.every) doesn’t work. But then after clicking on “Continue” once, everything then starts working. So clearly simplifying this far gets rid of the bug partially, but not completely.
Anyone out there who understands better the logic of what triggers Elm to re-examine
subscriptions, I’d be very grateful if you could help me to narrow down this bug to something I could put in a bug report… or explain (to my embarrassment!) why it’s not a bug (and why it worked as I expected under Elm 0.18).