Thanks a lot for the detailed answer!!! I clearly wasn't aware of the
effect manager. I would read more about it.
Thanks!
On Tuesday, November 15, 2016 at 6:20:27 PM UTC-3, OvermindDL1 wrote:
>
> Comments i
>
> On Tuesday, November 15, 2016 at 2:02:10 PM UTC-7, Guido Marucci Blas
> wrote:
>>
>> Hi everybody! I've been reading the docs and following Elm every now and
>> then. I did some toy application to learn the language and the
>> architecture. I am working on a native iOS application so using Elm in my
>> day job won't happen (for now). The main reason I want to learn Elm (apart
>> from it being awesome!) is that I want to apply Elm's architecture to iOS
>> with Swift (yeah a lot of people is doing the same thing). There are quite
>> a few libraries that try to bring Elm's architecture to Swift but I don't
>> want to use them. I want to implement something myself because that way I
>> will be able to understand it better.
>>
>> The reason I am writing is that I want to better understand how
>> subscriptions work internally. Please correct me if I am wrong. My
>> understanding of how subscription works is that they provide a mechanism to
>> "hook" to a stream of infinite events. Those events get mapped to your own
>> application message by virtue of the message constructor function that is
>> passed when creating a new subscription. As far as I can tell the only way
>> of creating subscription is by a model update. Every time the model gets
>> updated, Elm's runtime calls the subscription function (passed to the init
>> function when you bootstrap your app). This gives us the change to create a
>> new subscription based of the current state. Am I correct?
>>
>> - Is there any other way of creating subscriptions?
>> - What happens when the process of starting a subscription needs to
>> perform a expensive side-effect?
>> - What is the Elm way of doing this?
>>
>> No other way of creating subscriptions.
> The subscription itself should be fairly minimal, the effect manager
> handling the subscription setup and teradown should be doing all the costly
> stuff 'out-of-band' of your main app.
>
> On Tuesday, November 15, 2016 at 2:02:10 PM UTC-7, Guido Marucci Blas
> wrote:
>
>> Lets say that I have an application that connects to an external device
>> and after connecting with this device it wants to start listening to a
>> stream of data that this device reports every one second. Lets imagine this
>> device is thermometer that advertises the room's temperature. I want to
>> have an app that prints the average temperature since a connection with
>> thermometer was established. We can omit how we connect with thermometer
>> for now
>>
>
>> type alias Model =
>> { thermometer: Maybe Thermometer
>> , temperatureSamples: List Float
>> }
>>
>>
>> type Msg
>> = ConnectedThermometer Thermometer
>> | TemperatureSample Float
>>
>>
>> update : Msg -> Model -> (Model, Cmd Msg)
>> update msg model =
>> case msg of
>> ConnectedThermometer thermometer ->
>> ({ model | thermometer = thermometer }, Cmd.none)
>>
>>
>> TemperatureSample temperature ->
>> ({ model | temperatureSamples = temperature :: model.
>> temperatureSamples}, Cmd.none)
>>
>> view : Model -> Html Msg
>> view model =
>> let
>> averageTemperature = (List.sum model.temperatureSamples) / List.length
>> model.temperatureSamples
>> in
>> Html.text (toString averageTemperature)
>>
>>
>> subscriptions : Model -> Sub Msg
>> subscriptions model =
>> model.thermometer
>> |> map Thermometer.temperature TemperatureSample
>> |> withDefault Sub.none
>>
>>
>> -- Inside the Thermometer module
>> temperature : (Float -> Msg) -> Thermometer -> Sub Msg
>> temperature msgConstructor thermometer = ...
>>
>>
>> *I am assuming there is a function in the Thermometer that knows how to
>> create subscription for a given connected thermometer. I am also assuming
>> that this MUST be implemented in Javascript and that all needed
>> side-effects in order to create the subscription are performed on the JS
>> side.*
>>
>
> Nah, subscription can be managed within Elm by an effect manager (though
> it tends to eventually go out to a javascript effect manager, like via HTTP
> requests or whatever).
>
>
> On Tuesday, November 15, 2016 at 2:02:10 PM UTC-7, Guido Marucci Blas
> wrote:
>
>> If my assumptions are correct then my main concern is that for every
>> state update this "expensive" side effects that could be performed on the
>> JS side by creating a new subscription are executed for every model update.
>> If that is the case then I have the following questions
>>
>
> A subscription is just that, a subscription, saying that you 'want to
> listen to messages from a given effect manager'. The remote effect manager
> could even be doing stuff even when nothing is subscribed, a subscription
> is just that the main app wants to listen to messages from that effect
> manager. Subscriptions should change only based on your state. Basically
> it works kind of like this:
>
> 1. You have a subscription that appears when something on your model is,
> say, True.
> 2. The system sees that a new subscription has appeared compared to the
> last check, so it calls into the effect manager (passing it a
> 'registration' message basically), and the effect manager can do whatever
> it wants, from storing it, ignoring it, whatever.
> 3. As the effect manager does stuff (receives something over a http
> request, gets an interval call from the javascript setInterval, whatever),
> it calls the 'router' to send a message back to the main application, which
> the application handles via the subscription callback.
> 4. When the subscription is no longer registered in the main app the
> effect manager gets a notification of that via another message to it.
>
> Basically for a given thermometer thing, the setup should generally either
> be a task or an effect manager itself, depending on what and how much it
> does.
>
>
> On Tuesday, November 15, 2016 at 2:02:10 PM UTC-7, Guido Marucci Blas
> wrote:
>
>>
>> - Is the responsibility of the JS code that creates the subscriptions
>> to keep track of the created subscriptions and avoid creating a new one
>> if
>> a previous subscription to the same thermometer has already been created?
>>
>> Nope that is the job of the effect manager that is registered too (which
> is sometimes but not always backed by JS code).
>
> On Tuesday, November 15, 2016 at 2:02:10 PM UTC-7, Guido Marucci Blas
> wrote:
>
>>
>> - How would you terminate a subscription?
>>
>> Just quit registering to it, the effect manager backing it will tell the
> effect manager that it is no longer interested in messages.
>
> On Tuesday, November 15, 2016 at 2:02:10 PM UTC-7, Guido Marucci Blas
> wrote:
>
>>
>> - What happens if the process of establishing a subscription could
>> fail?
>>
>> You could do that via a Task, get a valid or invalid connection (then
> pass the connection to a subscription to listen to updates from it), or
> that could be handled by the effect manager itself too, it makes a
> connection when a subscription starts and so forth, it can send a failure
> message (Result or some custom union type) if it fails for example.
>
> On Tuesday, November 15, 2016 at 2:02:10 PM UTC-7, Guido Marucci Blas
> wrote:
>
>>
>> - What is the best way to handle that?
>>
>> See above.
>
> On Tuesday, November 15, 2016 at 2:02:10 PM UTC-7, Guido Marucci Blas
> wrote:
>
>>
>> - Do I need to execute a command to perform the side effect (which
>> could possible fail) that would allow to create a subscription and if and
>> only if this command is successfully executed then try to create a
>> subscription?
>>
>> Only if you want, but honestly I'd put that job in the effect manager
> itself...
>
> On Tuesday, November 15, 2016 at 2:02:10 PM UTC-7, Guido Marucci Blas
> wrote:
>
>> Sorry for the big bulk of text and thanks in advance!
>>
>
> And do note, I use Elm in a large project, but I do not do dev work on elm
> itself, my knowledge is no doubt incomplete but I have decently implemented
> the Elm API (subscriptions and all) in other languages (of which it works
> wonderfully in) so I hope my knowledge is fairly accurate. ;-)
>
--
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.
