Catering to new Elm users

[André Cruz]

Hello.

I have been following the redesign of Elm's home page and the new blog posts, that try to attract new developers to the Elm ecosystem, and they seem like good efforts. However, I feel that improvements can also be made in order to improve the situation of developers that are already trying Elm and trying to introduce it to their workplace.

I can provide my situation as an example. A few months ago we were given the opportunity to build a self-contained component from scratch that would talk to a Phoenix backend through its channels (websockets), and build a UI. I managed to persuade a few key people in order to build two parallel versions, one in Javascript and the other in Elm. While building the Elm version we very much liked the functional aspect of the language, the static types and the help the compiler gives. It seemed like we were over the most difficult parts, but then we started hitting some roadblocks typical of new ecosystems:

Heartbeat on websocket
https://github.com/fbonetti/elm-phoenix-socket/issues/7

Basically a part of the phoenix channels protocol was not implemented which caused connection to fail after some idle time. This issue was quickly resolved and the author released an updated version.

Then we had problems with a core module:

Inherit protocol and endpoint when not specified
https://github.com/elm-lang/websocket/pull/12

The current websockets module requires absolute URLs and for us this was a problem because it meant differences between dev/staging/prod environments. I submitted that PR with a small patch, but did not get feedback even after a few months.

API is missing notification of reconnect thus unnecessarily limiting its utility
https://github.com/elm-lang/websocket/issues/10

The current websockets module reconnects when there is a problem with the connection, however it does not re-subscribe to previously subscribed topics or provide any feedback to the client code that a reconnection happened. This does not seem like a complete implementation. We were thinking of tackling this problem but were waiting on feedback on the previous patch, since there is no point in sending PRs if they are not merged or rejected.

As time went by and since we had deadlines, we went with the Javascript version which just worked. I was a bit frustrated since it seemed like the perfect opportunity to introduce Elm and it mostly works, but I failed.

Providing feedback in a sensible timeframe is essential for maintaining an healthy ecosystem and one in which early adopters can feel they are a part of and are contributing, since they are the ones hitting these problems and hopefully solving them for future Elm generations. I understand that at this time most of the Elm language rests on the shoulders of just one person, but I'm a bit spoiled by the Elixir ecosystem. :)

Anyway, Elm is great, I wish I could use it at work and persuade my colleagues to use it as well.

Best regards,
André

[Oliver Searle-Barnes]

Good integration with phoenix channels does seem like an opportunity to attract more people to Elm. TEA is a great fit for channels and people building apps with phoenix channels are often in a position to be looking at new languages/frameworks. 

As André mentioned, without a fix for the reconnect issue there currently isn't production ready integration. I'm hopeful that this can be resolved without time from Evan, the addition of a reconnect hook to https://github.com/elm-lang/websocket would be very appreciated though :) 

What I'd really love is for an experienced Elmer to do a review of the elm-phoenix-socket API. Is it an idiomatic approach to the problem and how should an app be architected to share a phoenixSocket?

I'm planning on taking a look at the reconnect issue (which should at least make it usable in production) but any high level advice/guidance would be very appreciated.

[OvermindDL1]

If you need a phoenix-correct socket interface I have a wonderfully port-filled implementation that uses the native Phoenix javascript library for all communication.  I think I expose every possible feature but I might have missed something.  I am using it in production and I know at least one other person is:  https://github.com/OvermindDL1/elm-jsphoenix

But yes, I almost stopped using Elm too for the *exact* same reason, but I decided to try implementing my own version of the library that uses Phoenix's instead.  It is not very Elm'y in design (was my first real Elm project and nowadays I'd implement it as an effect manager), but it works wonderfully well.

[Oliver Searle-Barnes]

Replied from my email client but it doesn't seem to have come through so I'll repeat here

Thanks OvermindDL1, I’ll take a good look at that.

It also occurred to me that an effect manager might be a better solution. It would be nice to be able to just use subscriptions to manage listeners for channel/messages. If you’ve any thoughts regarding how the API might look please add them here or the #phoenix channel. I’ve been considering having a go at building one but I’ve only just finished my first month with Elm so would appreciate even any vague thoughts.

[OvermindDL1]

Since I first wrote that I have written a *lot* of elm.  The library as-it-is is fully functional and works perfectly for me, but if I were to rewrite it I'd make it an Effect Manager so I could 'subscribe' to things.  The phoenix javascript library supports subscribing and unsubscribing with ease so it should work quite well.  I'd probably also get rid of ports and switch to a native module (ports are already not allowed on elm packages so I may as well go full-out) with a method that javascript could call somehow to get the original phoenix socket (probably on `window` or so, I have to have the original socket for some old javascript things to use).  That would make it very self-contained and easier to place into a project instead of copying in a javascript Port manager (which though easy, is irritating for me to force on others).

Basically I'd just make the subscription API look very similar to how my Command API looks now (since you register listeners 'through' it, currently no way to unregister without closing the topic, which is fine for my use-case since the API stays constant per-topic), just via pure subscriptions.

I'd love a PR if you work on that though.  ^.^

[Oliver Searle-Barnes]

My initial impression is that the API seems closer to what I'd expect for an Elm client. I'll need to take a look and see if it makes more sense to take this route than elm-phoenix-socket but it's certainly reassuring to have the official phoenix js client underneath.

[Oliver Searle-Barnes]

Thanks OvermindDL1, I’ll take a good look at that.

It also occurred to me that an effect manager might be a better solution. It would be nice to be able to just use subscriptions to manage listeners for channel/messages. If you’ve any thoughts regarding how the API might look please add them here or the #phoenix channel. I’ve been considering having a go at building one but I’ve only just finished my first month with Elm so would appreciate even any vague thoughts.

--
You received this message because you are subscribed to a topic in the Google Groups "elm-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elm-dev/25StjGJVqeM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to elm-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/580d09e2-b7a8-4a9c-8e60-40cd347c46d6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[André Cruz]

Thanks Overmind. I'll keep an eye on that project if another opportunity arises.

André

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+unsubscribe@googlegroups.com.

[Evan Czaplicki]

Yeah, I always thought the Phoenix Channels library would be an effect manager. This was one of the specific cases I had in mind when designing that part of the language, and I designed WebSocket.LowLevel such that it would be used to implement Phoenix Channels. The WebSocket module was never meant for that, and it doesn't sound like a nice way to go to me.

So if folks are interested in working on that, please keep me in the loop on elm-dev! Introduce yourself and your work. If you have a potential API, share it. Etc.

To unsubscribe from this group and all its topics, send an email to elm-dev+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/580d09e2-b7a8-4a9c-8e60-40cd347c46d6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/85D793F2-B71F-42FB-AFD0-952E3FFD519B%40opsb.co.uk.

[Oliver Searle-Barnes]

Having spiked out elm-jsphoenix it does look like a better way to go for now.

I'm definitely interested in working on an effect manager. I won't have bandwidth in the next month but it would be good to start discussing the API. FWIW, the elm-jsphoenix API does seem pretty close to how I'd expect it to look so that seems a good starting point (obviously without the port acrobatics :) ).

To unsubscribe from this group and all its topics, send an email to elm-dev+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/580d09e2-b7a8-4a9c-8e60-40cd347c46d6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+u...@googlegroups.com.