Effect manager for Phoenix Channels

[Sascha Timme]

Hey,

I have been following elm for quite a while and started a side project with elm + elixir / phoenix a couple of weeks ago in which I want to use Phoenix Channels.

Inspired by this thread I started to develop an effect manager for phoenix. Since this is my first larger elm project and my first open source library I would love to hear some feedback on the api before I publish the package. The repository with documentation can be found here https://github.com/saschatimme/elm-phoenix.

P.S.: I'm still looking for package name, since elm-phoenix and elm-phoenix-socket are both already taken (I assume there cannot be two packages by the same name just with different repos?). So if someone has an idea :)

[Janis Voigtländer]

Concerning the naming: Packages are namespaced by GitHub user name, so you can publish yourname/elm-phoenix on the package site just fine. 

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/70cf5d1e-cf2d-46f0-a274-6eff1216a2a4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Evan Czaplicki]

Very cool! I'll try to take a look in the next few days, but ping the thread if I don't get to it in a week.

And yeah, just call it elm-phoenix. Literal names are the best and overlap is no problem. I think it's really important to know who you are collaborating with (by using their code) so the user name is part of the name!

On Sunday, September 18, 2016, Janis Voigtländer <janis.voi...@gmail.com> wrote:

Concerning the naming: Packages are namespaced by GitHub user name, so you can publish yourname/elm-phoenix on the package site just fine. 

Am 18.09.2016 um 17:25 schrieb 'Sascha Timme' via elm-dev <elm...@googlegroups.com>:

Hey,

I have been following elm for quite a while and started a side project with elm + elixir / phoenix a couple of weeks ago in which I want to use Phoenix Channels.

Inspired by this thread I started to develop an effect manager for phoenix. Since this is my first larger elm project and my first open source library I would love to hear some feedback on the api before I publish the package. The repository with documentation can be found here https://github.com/saschatimme/elm-phoenix.

P.S.: I'm still looking for package name, since elm-phoenix and elm-phoenix-socket are both already taken (I assume there cannot be two packages by the same name just with different repos?). So if someone has an idea :)

--
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/70cf5d1e-cf2d-46f0-a274-6eff1216a2a4%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/447695E5-DFF5-49E1-8886-8145B0126031%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
Sent from Gmail Mobile

[Oliver Searle-Barnes]

I've been using elm-jsphoenix but am keen to move to an effect manager. Just did a quick review and it looks great so far. I'll try and do a full review tomorrow. Many thanks for your efforts on this! 

[an...@cabine.org]

Great work!

It would be nice if we could pass a relative URL for the Phoenix socket. The JS client allows this and it makes it easier to have the same code running in different environments.

André

[OvermindDL1]

Nice, and I would very much like a replacement for my elm-jsphoenix library, however it looks like this one has the same issues that the other elm-phoenix and socket libraries had, which is what spurred me to make elm-jsphoenix (I still need to effect manager'ize elm-jsphoenix someday), and that is:

• I'm not seeing it handle reconnect properly, the site I handle is used over a local wifi that bounced a lot and proper reconnects are vital.
• I *have* to have access to the websocket via javascript for older javascript things written by others to be able to use it, so I cannot have elm have exclusive hold on it.

How would a user handle both of these cases with this new library?  (I really do not want to keep up with elm-jsphoenix to be honest, I have too much other stuff that I am working on ^.^).

[OvermindDL1]

Actually it looks like the low-level websocket interface does allow for reconnecting (why did the older phoenix libraries not use this?), so then that just leaves the final issue of that I need the phoenix websocket for other javascript purposes as well (plus some presence functionality).  :-)

[Sascha Timme]

Actually it looks like the low-level websocket interface does allow for reconnecting (why did the older phoenix libraries not use this?), so then that just leaves the final issue of that I need the phoenix websocket for other javascript purposes as well (plus some presence functionality).  :-)

Yes, the reconnecting is properly handled. This was one of the main reasons two write this as an effect manager :)

For the presence functionality: The best solution would probably be to integrate it natively into this library, but I haven't done anything with Presence yet. So I would have to play a little bit with it or maybe there is someone with some Presence experience who would like to contribute and we could figure something out.

For other javascript purposes: It would be possible to expose the Websocket (from WebSocket.LowLevel.open) with a command, but I don't know if you will get it through an port to javascript land. Also I really don't know whether this is an functionality which should be covered by this library. But if you want to try the feasibility just let me know and I will try to give you a hand.

It would be nice if we could pass a relative URL for the Phoenix socket. The JS client allows this and it makes it easier to have the same code running in different environments. 

As far as I know there is no way to get the current browser location besides the Navigation package which I wouldn't want to drag in as a dependency. So this could only be handed with a Native module.

[Evan Czaplicki]

Actually it looks like the low-level websocket interface does allow for reconnecting (why did the older phoenix libraries not use this?), so then that just leaves the final issue of that I need the phoenix websocket for other javascript purposes as well (plus some presence functionality).  :-)

Yes, the reconnecting is properly handled. This was one of the main reasons two write this as an effect manager :)

For the presence functionality: The best solution would probably be to integrate it natively into this library, but I haven't done anything with Presence yet. So I would have to play a little bit with it or maybe there is someone with some Presence experience who would like to contribute and we could figure something out.

For other javascript purposes: It would be possible to expose the Websocket (from WebSocket.LowLevel.open) with a command, but I don't know if you will get it through an port to javascript land. Also I really don't know whether this is an functionality which should be covered by this library. But if you want to try the feasibility just let me know and I will try to give you a hand.

I don't think the library should try to do this. Sharing the socket between JS and Elm is not great. I'd recommend that it is owned by either Elm or JS and you use ports to communicate to it if you need to. So maybe you do it all in Elm, but send certain messages out to JS to be handled by old stuff. Or the reverse.

 

It would be nice if we could pass a relative URL for the Phoenix socket. The JS client allows this and it makes it easier to have the same code running in different environments. 

As far as I know there is no way to get the current browser location besides the Navigation package which I wouldn't want to drag in as a dependency. So this could only be handed with a Native module.

Don't worry about this in the initial release. Not blocking IMO. 

[Oliver Searle-Barnes]

I've had a better look at it and it definitely covers everything that I'm using in my current app. If you publish it I'd be looking to integrate it very soon.

Push.map is a nice touch, as the replies will likely have different shapes I wonder if Push.mapOk and Push.mapError would work better though.

An area that I'm interested in exploring is controlling the queuing behaviour, in particular I'd like to be able to wait for replies before sending the next message. This makes it easier to conflict resolution in the client. Anyway, definitely one for future consideration, just thought I'd put it out there in case it's of interest to other people. It's something that I'll most likely have time to work on in the next month or so.

[Josh Adams]

For the presence functionality: The best solution would probably be to integrate it natively into this library, but I haven't done anything with Presence yet. So I would have to play a little bit with it or maybe there is someone with some Presence experience who would like to contribute and we could figure something out.

For what it's worth I built an API-identical(ish) version of this for elm-phoenix-socket, here: https://github.com/fbonetti/elm-phoenix-socket/pull/16

It has some...silly things because they aren't really necessary and I just wanted to match the API identically.  Probably not best to have that as a focus though, could clean up the API a bit and make it less silly in a couple of places.

Anyway, I use this extensively and it just works (haven't had to deal with reconnection but since lowlevel already supports that there's no reason the existing non-effect-manager thing couldn't support that as well)

So yeah if you want some help I'd be glad to.  I also outlined all of my work in some screencasts/text episodes for dailydrip, glad to send those your way if you want detailed walkthroughs by chance.

-Josh 

[Sascha Timme]

Sound's great! I don't want to block the initial release for this, but after that I will take a closer look and ping you :)

[Sascha Timme]

Very cool! I'll try to take a look in the next few days, but ping the thread if I don't get to it in a week.

 

did you get a chance to take a look?

[Oliver Searle-Barnes]

Did anything come of this? 

[André Cruz]

Don't think so. 

--
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/MD5r5P3Tl7Q/unsubscribe.
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/39053569-2c43-43c1-905b-e392d55a3aaa%40googlegroups.com.

[Sascha Timme]

Nothing yet. But I understand that at the moment the focus is to get 0.18 done and that there are problems to get effect managers properly working with the upcoming debugging features.

So if there is something I could do to to help to move this forward just let me know.

[Oliver Searle-Barnes]

Over the weekend I switched over a moderate app (~3000 lines of Elm) to elm-phoenix. I've been very happy with the results and generally think that it's the phoenix effects manager that we'd all been hoping for :) Starting an Elm/Phoenix app will now be as pleasant as it has been for apps using http based APIs. 

I've seen a few questions/threads around with people getting stuck with other elm/phoenix libraries. It seems a shame to have such a great option but for it to not be generally available/advertised. Personally I've forked the repo and tagged a version so that I can install it using elm-github-install. What do you think to tagging a version and adding instructions so that other people can get up and running easily? (happy to PR the instructions) Obviously longer term it would be great to have it published but in the mean time I think it would be great to get it out there.

[Gusztáv Szikszai]

We are using it in a project at work, and I personally did the same with the forking and elm-github-install (nice to see others are using it as well), working pretty well so far.

[Dustin Farris]

Sascha, was this comment from Evan ever addressed?

Sharing the socket between JS and Elm is not great. I'd recommend that it is owned by either Elm or JS and you use ports to communicate to it if you need to.

Scanning through this thread, it looks like this is the only reason elm-phoenix has not been approved yet.

[Sascha Timme]

That was just a wish from @OvermindDL1. The socket is completely owned by Elm.

[Dustin Farris]

Evan, is there anything else holding this up?

--
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/MD5r5P3Tl7Q/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/01ffd287-97fd-40d2-9448-3285fc0c23cf%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

-- 

Dustin Farris

[Dustin Farris]

Hi Evan, just pinging this thread.  Not sure the right way to confirm this is on your radar.

On Wednesday, February 22, 2017 at 8:52:37 PM UTC-5, Dustin Farris wrote:

Evan, is there anything else holding this up?

On Feb 23, 2017, at 3:37 AM, 'Sascha Timme' via elm-dev <elm...@googlegroups.com> wrote:

That was just a wish from @OvermindDL1. The socket is completely owned by Elm.

Am Mittwoch, 22. Februar 2017 15:44:56 UTC+1 schrieb Dustin Farris:

Sascha, was this comment from Evan ever addressed?

Sharing the socket between JS and Elm is not great. I'd recommend that it is owned by either Elm or JS and you use ports to communicate to it if you need to.

Scanning through this thread, it looks like this is the only reason elm-phoenix has not been approved yet.

On Sunday, September 18, 2016 at 11:25:29 PM UTC+8, Sascha Timme wrote:

Hey,

I have been following elm for quite a while and started a side project with elm + elixir / phoenix a couple of weeks ago in which I want to use Phoenix Channels.

Inspired by this thread I started to develop an effect manager for phoenix. Since this is my first larger elm project and my first open source library I would love to hear some feedback on the api before I publish the package. The repository with documentation can be found here https://github.com/saschatimme/elm-phoenix.

P.S.: I'm still looking for package name, since elm-phoenix and elm-phoenix-socket are both already taken (I assume there cannot be two packages by the same name just with different repos?). So if someone has an idea :)

--
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/MD5r5P3Tl7Q/unsubscribe.

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/01ffd287-97fd-40d2-9448-3285fc0c23cf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 

Dustin Farris