[elm-discuss] Re: elm-seeds rocks!

[David Legard]

Many thanks for the link - those are terrific videos

-- 
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.

Re: [elm-discuss] Elm with one message

[Mark Hamburg]

Your previous update structure was essentially (ignoring commands and
subscriptions)

type Msg
= Set Model

update : Msg -> Model -> Model
update (Set newModel) model =
newModel


used as something like:

... onClick (Set { model | counter = model.counter + 1 }) ...


The revised approach looks like:

type Msg
= Apply (Model -> Model)

update : Msg -> Model -> Model
update (Apply fn) model =
fn model


used as:

... onClick (Apply (\model -> { model | counter = model.counter + 1 })) ...


The point is that we avoid capturing the model value in the message being
routed around so that we can interleave this message with other
asynchronous responses.

Again, as noted in my earlier message, this is not the Elm way and will be
unfriendly to tools like the debugger but it is valid Elm. It is somewhat
more complicated than the original version but still avoids the level of
indirection associated with messages. It is also more efficient than the
original form in that it at most constructs new function closures rather
than constructing entire new model values for each possible action in the
UX.

Mark

P.S. I was tempted to also include this form in the example:

... onClick (Apply incrementCounter) ...

incrementCounter : Model -> Model
incrementCounter model =
{ model | counter = model.counter + 1 }

But if one did that, one might as well have an IncrementCounter message and
handle it in the update function.



On Thu, Aug 31, 2017 at 11:57 AM, Vlad GURDIGA  wrote:

>
> On Monday, August 28, 2017 at 4:01:20 AM UTC+3, Mark Hamburg wrote:
>>
>> One other note: If you don't care about Reactor and the Debugger but do
>> care about async problems, you could get almost the same structure by
>> passing back Model -> Model functions instead of Model values.
>>
>
> Sorry Mark, this sounds cool, but I’m kind of a slow thinker (generally) —
> could you give some pseudo-code to show an example of what you mean? 
>
>
>> Doing so may cause you to receive a visit from the Elm thought police but
>> it is entirely semantically viable within Elm (and it's what I could
>> imagine a lot of other functional languages doing by default).
>>
>> Mark
>>
> --
> 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.
>

-- 
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.

[elm-discuss] Re: Elm with one message

[Vlad GURDIGA]

This would probably come in handy later, but for now I really enjoy having 
elm-make as my only build step. 邏

On Monday, August 28, 2017 at 4:28:03 PM UTC+3, Robin Heggelund Hansen 
wrote:
>
> You can use the Elm debugger just fine with, say, webpack. Just pass in 
> the `debugger: true` flag and you're good to go.
>

-- 
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.

Re: [elm-discuss] Elm with one message

[Vlad GURDIGA]

On Monday, August 28, 2017 at 4:01:20 AM UTC+3, Mark Hamburg wrote:
>
> One other note: If you don't care about Reactor and the Debugger but do 
> care about async problems, you could get almost the same structure by 
> passing back Model -> Model functions instead of Model values.
>

Sorry Mark, this sounds cool, but I’m kind of a slow thinker (generally) — 
could you give some pseudo-code to show an example of what you mean? 
 

> Doing so may cause you to receive a visit from the Elm thought police but 
> it is entirely semantically viable within Elm (and it's what I could 
> imagine a lot of other functional languages doing by default).
>
> Mark
>

-- 
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.

Re: [elm-discuss] Elm with one message

[Vlad GURDIGA]

Ooooh! …now I understand. 樂

There was this question looping into the back of my mind regarding onClick 
callbacks: “How do I get a zero-argument function in Elm?” and your 
explanation clarifies it — there can’t be a zero-argument function in Elm! 
Right? 

I’m surely curious about the philosophical implication of this, but even 
without them I’m happy to have this clarified. 邏

Thank you!

On Sunday, August 27, 2017 at 7:13:18 PM UTC+3, Peter Damoc wrote:
>
>
>
> On Sun, Aug 27, 2017 at 11:15 AM, Vlad GURDIGA  > wrote:
>>
>> You basically have to computer all the possible future states of the app.
>>>
>>
>> Not sure what you mean here. Could you please expand, or maybe point to 
>> an example in the code? 樂 
>>
>
> Let's simply the problem space and imagine that you have 3 buttons that 
> when clicked do some serious computation on the model. 
>
> With a traditional approach you have the message sent by one of the 
> buttons and the specific computation done in response to the message. 
>
> With this approach, you would have to compute all 3 heavy computation and 
> send the new state with the message.  If your main message is: 
>
> type Msg
> = Update Model
>
> then the 3 messages you will have to use on `onClick` would be equivalent 
> to:
>
> div []
> [ button [onClick (Update (doTheUpdateForMessageOne oldModel))] [text 
> "Do First Thing"] 
> , button [onClick (Update (doTheUpdateForMessageTwo oldModel))] [text 
> "Do Second Thing"] 
> , button [onClick (Update (doTheUpdateForMessageThree oldModel))] 
> [text "Do Third Thing"] 
> ]
>
> Or, more realistically, inside a child component with its own `update`, 
> have something like: 
>
> view onUpdate model = 
> let 
> toMsg msg = onUpdate (update msg model) 
> in 
> div []
> [ button [onClick (toMsg First)] [text "Do First Thing"] 
> , button [onClick (toMsg Second)] [text "Do Second Thing"] 
> , button [onClick (toMsg Third)] [text "Do Third Thing"] 
> ]
>
> this means that by the time the view is rendered, all 3 future states of 
> the that component have been computed.
> This is not a big issue if computing all future states is trivial (e.g. 
> one toggle state of some drawer) so it's fine for small widgets but if you 
> scale this to the level of the entire app, you might run into performance 
> issues. 
>
 

-- 
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.

Re: [elm-discuss] Javascript interop width timing

[Peter Damoc]

Here is the watch example modified to have an effect in a place of the DOM
that's outside of Elm's control:
https://ellie-app.com/4b3rFVGCK32a1/0



On Wed, Aug 30, 2017 at 10:57 PM,  wrote:

> Hello guys,
> I'm involved in developing a interactive animation for children.
>
> I'm wondering if it is possible to control dom elements properties (build
> with Tumult Hype, specifically the position of that elements) via
> javascript ports on a timing base, like the watch hands of the example in
> elm-guide.
>
> If yes, where please can I find a skeleton suitable for this purpose?
>
> Many thanks,
> Rosario
>
> --
> 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.
>



-- 
There is NO FATE, we are the creators.
blog: http://damoc.ro/

-- 
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.