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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
