Le 23/05/2017 à 18:13, 'Rupert Smith' via Elm Discuss a écrit :
> On Tuesday, May 23, 2017 at 3:30:44 PM UTC+1, Christophe de Vienne wrote:
>
> It is what I did at first, but it has serious drawbacks. The biggest
> was
> that a subscription implies an update of the Nats state... so I had to
> push the state to all the update functions and they had to sent it
> back... Very messy.
>
>
> This use case can be catered for by using a correlation id, I think.
> Also, perhaps the word 'subscription' is getting overloaded here, you
> have the Elm Sub(scription), and the NATS protocol subscription, and the
> middleware subscription (listen), making this conversation a little
> difficult to nail down...
>
> == Module Consuming the NATS Protocol
>
> Elmq.sendString "subscribe" "nats0"
> Elmq.listen "nats0"
>
Except that sending a command to initialize a subscription is not
something I want the final module to do. No more that having to send a
command to unsubscribe.
My current implementation allow the module consuming to simply do:
Nats.subscribe "subject" tagger
Used this way elmq does not improve the situation.
> == The module implementing the NATS protocol
>
> type Msg =
> NewNatsSubscription String
> | ...
>
> Elmq.listenString "subscribe" (\channel -> NewNatsSubscription)
> Elm.send channelName ...
>
> ==
>
> So I sent a subscription request to Nats, and when Nats processed it, it
> sends back messages on the named channel. The channel name is used as a
> correlation id to link together the act of creating the subscription and
> the messages that then flow over that subscription.
>
> I don't know the specific of NATS and whether it has named channels etc.
> but hopefully you get what I am on about?
I think I do, and it would work. But the resulting API is less natural
that what I achieved already without elmq (unless I am still missing
something of course).
For sending pure commands though (publish and... that's it I guess,
because request requires to handle a response, which elmq won't make
easy), elmq could make things better, as the update functions would
return only Cmd and not both a Cmd and a Nats.Cmd.Cmd as they have to do
right now.
That said once the boilerplate is in place, it is not that painful.
In the app I am building on top of elm-nats I even added a wrapper type
around Cmd and Nats.Cmd.Cmd:
type MyCmd msg = PCmd (Cmd msg) | NCmd (Nats.Cmd.Cmd msg)
along with batch, map and none functions.
All the update functions returns (Model, MyCmd), and the top-level
update separates the Cmd from the Nats.Cmd.Cmd and converts the
Nats.Cmd.Cmd and Nats.Sub.Sub to Cmd with the Nats API (which updates
the nats state at the same time).
--
Christophe de Vienne
--
You received this message because you are subscribed to the Google Groups "Elm
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
