There is not much documentation on it on purpose. ^.^
Best way to learn it is to read how it is implemented in the core
libraries. :-)
As a comparison, if you are try to implement TEA in Swift, I managed to
make subscriptions in mine via startup/shutdown callbacks and a back-end
differ, quite easy to make then. :-)
On Tuesday, November 15, 2016 at 2:35:20 PM UTC-7, Guido Marucci Blas wrote:
>
> 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.
