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…
https://ellie-app.com/7bhgBPtf49Xa1
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 subscriptions.
So I tried to make the example even simpler and came up with this:
https://ellie-app.com/7bhCFf639HMa1
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).
Thanks!
