After months of prototyping and technical derisking, I’m working on the first production version of our SaaS SPA application in Elm that communicates with a Phoenix backend. I try to take the most reasonable decisions to limit future technical debt, therefore:
At this time, what is the expected future of effect managers (including their process or lack thereof) and is Phoenix channels still a suitable use case?
Notes:
@luke provided an answer to the first point in the Elm 0.19 - From a production perspective thread but I don’t think this takes into account the missing features in elm-lang/websocket and this does not fully answer the why from my perspective, hence this new thread dedicated to the subject. Given the current situation, I am more inclined to go with a port. I hope that this discussion will help taking a thoughtful decision.
I only link to saschatimme/elm-phoenix discussions because this is almost always the library used in Phoenix channels discussions. But there might be some perfectly working solutions that people are happy with and don’t talk about. Therefore if you have a solution in production that works well and can be shared, please do so.
Please let’s try to avoid speculating in order to keep the discussion focused, particularly for 2. and 3. Some questions may not have answers yet.
Sorry for the questions being very dense in links, but I tried to link to all relevant discussions, hoping that this will avoid having some duplicate discussions between them and this one.
This is not a discussion about Elm language development or kernel/effect-managers policies, however the processes (or lack thereof) involved and resulting constraints might be relevant.
Thank you for your answer, my triggerfish was feeling alone in this empty ocean .
I am not that worried about making this library work without being an effect manager, but it seems reasonable to first know why this should be done (why it might not be a suitable effect manager use case anymore).
However even if this is done, I am more worried about the missing notifications of reconnection in elm-lang/websocket, as forking those won’t be possible in 0.19.
How does elm-phoenix get around this missing feature?
Ok, it seems that I was confused by a previous dramatic post (I removed the link) and should have done more research to clear my mind.
elm-phoenix actually uses Websocket.LowLevel and is therefore not impacted by those missing features. This actually confirms the answer from @luke, I will edit my post in consequence.
Now the main point remaining concerns the status of the elm-phoenix effect manager. Is it still a suitable use case to be accepted as an official effect manager? If so what could be done to reach this position?
Will post when we have something working properly for 0.18. Also, as I said previously, once 0.19 starts to get into Alpha, we’ll revisit this and all of our native code bits and give solutions for how we migrate.
I’ve used both the effects manager and the existing regular package. The big difference from a coding standpoint is the absence of subscriptions as a mechanism for specifying interest in a channel in the regular package. It’s easy enough to specify gaining interest in a channel — just do it whenever you init the thing that is interested in it — but specifying losing interest in a channel and triggering a leave requires some uncommon patterns for Elm code either because one either needs to add termination to balance init or one needs to parallel what subscriptions does in recursing through the model and one needs to do this at a time when the book keeping data structures can be updated. So, if I were converting the effects manager over to being a regular library, I would start with figuring out how those API issues were going to be resolved because they will likely establish much of the flavor of the resulting API.
that communicates with a Phoenix backend. I try to take the most reasonable decisions to limit future technical debt, therefore:
.