3 ms·

Yes, the message needs to never be sent in a batch with other messages which change the model.

• dwohnitmok 6y ago
  But it's not just that, you may e.g. be racing against messages from a subscription (this one is really dangerous if your subscriptions are things like listening for resizing, where that can mean your resizing message is effectively dropped and users see a really needed up UI).
  • k_bx 6y ago
    Correct, you shouldn't do that. On the other hand, event of simultaneously resizing and writing input is kind of rare, and this will be fixed on next resize/input event, so I wouldn't be too bothered.
    • dwohnitmok 6y ago
      Well the tricky thing is you can't "not do that" because your Elm code doesn't have control over when subscriptions fire. Note that this applies to any subscription and that it is effectively dropped forever; the next input event won't recover it (so in the case of resizing only the next resize event will change things, not the next input event). So e.g. you could have a long running operation in a Web Worker over ports and then if its result comes in right when your user happens to be inputting something then it is dropped and never returns.