Questions about Phoenix channels, elm-phoenix and effect managers

[dmy]

Hi,

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:

1. What is the best strategy to use Phoenix channels right now that won’t break with 0.19 given the effect managers policy and the websocket low-level features currently missing in elm-lang/websocket for this use case (mainly https://github.com/elm-lang/websocket/issues/10 and potentially https://github.com/elm-lang/websocket/pull/12) ? (Edit: those are not an issue if Websocket.LowLevel is used).

2. Why the saschatimme/elm-phoenix effect manager did not make it into official packages given that it was one of the specific cases Evan had in mind when designing that part of the language, but then it was removed from the main guide, and given that some feedback was asked, it was received positively, and no concern was raised? And could this change?

3. 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.

[madasebrof]

Just an FYI, we are using https://github.com/saschatimme/elm-phoenix in production and it works brilliantly.

I’d go ahead and use it.

I promise we’ll re-write it for Elm 0.19 if no one else does.

[dmy]

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?

[dmy]

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.

However fbonetti/elm-phoenix-socket is in the official packages and uses the higher level Websocket. It is impacted by the missing features therefore think twice before using this library.

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?

If not the best way seems indeed to join the effort to convert it as a standard library.

[madasebrof]

We’ll tackle this:

Issue: Do things without an effects manager

I feel like it’s the least we can do!

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.

[valberg]

Yay! Just say the word if we should do some collaboration on this

[MarkHamburg]

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.

Mark