Subscribing with a token

[akeating]

I'm interested in the use-case of using token authentication on connect. That is, I login, obtain a token and add it to the socketUrl used to define the subscription:

ws://localhost:3000/socket/websocket?vsn=2.0.0&token=blah

If I define the subscription in the init I'm tied to a static url. See also https://hexdocs.pm/phoenix/channels.html#tying-it-all-together in the section Using Token Authentication. However I have not yet been able to make that work. I think part of the reason is the coupling between my model and Graphqelm.Subscription module, where in a few places, I am required to pass-in my full model.

Ideally, I would only pass you back the graphqlSubscriptionModel . subscriptions would then look like this:

subscriptions : Model -> Sub Msg
subscriptions model =
    listen GraphqlSubscriptionMsg model.graphqlSubscriptionModel

and the update:

GraphqlSubscriptionMsg graphqlSubscriptionMsg ->
    let
       ( updatedGraphqlSubscriptionModel, updateMsg ) =
            Graphqelm.Subscription.update graphqlSubscriptionMsg model.graphqlSubscriptionModel
    in
       ( { model | graphqlSubscriptionModel = updatedGraphqlSubscriptionModel }, updateMsg )

This means I have flexibility to do something such as (where CounterState is one of my data types):

type alias Model =
   {  graphqlSubscriptionModel : Maybe (Graphqelm.Subscription.Model Msg (Maybe CounterState)) }

Aside from the separation of concerns, I can then define a subscription dynamically. Interested in your thoughts. Let me know if I'm missing something really obvious! I can put up a pr if you like, but be sure to carefully review it :)

[dillonkearns]

Hey Adam, thanks for the issue! That's a great point, I hadn't considered that use case. The reason that I had the Graphqelm.Subscription.update coupled to the specific record attribute was because I was hoping to remove a potential point of failure where you call Graphqelm.Subscription.update but forget to update the result in your record. Plus it makes that a little more concise.

But given this use case it seems that maybe that design isn't ideal. I'll go ahead and make the changes. It's an easy change, but unfortunately it will require me to do a major version bump.

[dillonkearns]

Hey Adam, I made the update, I think this show now support your use case nicely. Please let me know how it goes!

I was rushing out the door a for my two week vacation so I think the code examples need to be updated a bit for the Subscription module docs. But my code example in examples/src/Subscription.elm is up-to-date and is confirmed working with Elixir/Absinthe 👍

[dillonkearns]

Hey @akeating, I’m going to close this out, but please let me know if there’s anything else to discuss here! And of course there will be a lot to consider as we discussed in #43 as to whether the framework-specific communication should be delegated to a different package, but I’ll leave that discussion to a different issue.

[akeating]

Thanks DIllon!

[dillonkearns]

Thank you for helping me improve the package, I very much appreciate your feedback Adam!