This is only an adequate solution, if a round-trip from and back to JS happens synchronously. Otherwise it may be possible to receive further messages even after Elm code has unsubscribed. I remember reading somewhere that messages in 0.19 are delivered synchronously to Elm, is the same true for a round-trip?
@pdamoc, I think this is a really great suggestion!
Reading this thread has been a bit interesting, because there seems to be a great deal of misunderstanding about your proposal.
I’m trying to outline what you’re saying in a few words:
- We will still be using ports (and have all of today’s benefits)
- The only ports defined will be standardized (input and output) so we don’t have any of the issues that come along with defining our own.
- This better enforces the pattern presented in Murphy Randle’s elm-conf talk, where he found a better JS interop experience.
For those of you concerned with this proposal, I’d recommend an example of how this is not just a slight enhancement on top of the current model.
I haven’t found an edge case, but there very well might be one!
1 Like
This is an interesting point and I do agree that it needs to be well thought through. I do not know enough about the Elm internal implementation of the platform code and the interaction with the JS event handlers to comment on this.
I believe that for most cases this would be a non-issue. For exceptional cases (like the one you just described), there could be workarounds.
Yes, usually you would work around such an issue by designing your model as a state machine. I think that this is not the most straight forward way to solve such a problem, you would basically introduce 2 solutions to solve just one problem, this usually feels like a hack.