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 [email protected].
For more options, visit https://groups.google.com/d/optout.
