3 ms·
If the model changes, a new view is generated, so your message should take that into account. I can't remember of any concurrency issue arising from handling m
by pyrale 6y ago
If the model changes, a new view is generated, so your message should take that into account.
I can't remember of any concurrency issue arising from handling multiple messages from the view, to be honest. I don't know if there's a specific mechanism blocking them, but it's simply never happened in 3 years of building elm apps for a living.
- Latty 6y ago> If the model changes, a new view is generated, so your message should take that into account. You don't have any guarantees about when that will occur though. Updates and view rendering are run independently. I have an application that tracks mouse movement using pointer events for the user to draw, and I've definitely had a message from that come through after my model has updated and I'm no longer on that screen (and so nothing in the view generated from the model should produce that message), so it definitely can happen, even if you haven't encountered it. Even if you don't encounter it that way, there are a bunch of footguns using this approach (e.g: doing this with tasks, HTTP requests, anything that has a defined delay before the message comes back).