[elm-discuss] Re: Subscribe to a model value then call update function when condition is met

[hoangtkc95]

I'm sorry. Don't why your answer wasn't loaded that day.

Aren't "set and unset whenever processing is started/finished" 
side-effects?  We can do that easily in imperative languages but all 
functions in ELM are pure.

Vào 03:55:33 UTC+7 Thứ Ba, ngày 11 tháng 10 năm 2016, OvermindDL1 đã viết:
>
> I'd set a flag on the model for when it is 'processing' (good flag name, 
> maybe `isProcessing` or so?) and just test that in the model and set and 
> unset it whenever processing is started/finished.  :-)
>
> Just think of it as another piece of 'state'.  In fact if it can be 
> gleaned from another piece of state (such as the animationframe being 'on') 
> then check that instead, you do not want duplicate pieces in your model 
> that hold essentially the same information, only have one place per piece 
> of data.  :-)
>
>
> On Monday, October 10, 2016 at 2:07:59 PM UTC-6, hoang...@gmail.com wrote:
>>
>> The AnimationFrame works perfectly. Thank you :D 
>> I have another question came in mind. How do you think can we make the 
>> view display, for example "Thinking", while the minimax algorithm is being 
>> executed?
>>
>> Thank you a lot for your help. :D
>>
>> Vào 00:11:59 UTC+7 Thứ Ba, ngày 11 tháng 10 năm 2016, OvermindDL1 đã viết:
>>>
>>> Most callbacks in a browser, such as the timeout used for Time, is 
>>> throttled to 4ms and behaves strangely below 16ms, if you want to execute 
>>> as fast as possible then you should use an AnimationFrame subscription. 
>>>  Time subscriptions should only be used for 500ms or larger or so, any less 
>>> and it starts to act odd.
>>>
>>> You should probably still do a test to make sure it is the ai turn in 
>>> your update for `AIMove` though, the browser can cache and send events 
>>> 'later' than you expect as well.
>>>
>>> On Monday, October 10, 2016 at 11:06:07 AM UTC-6, hoang...@gmail.com 
>>> wrote:

 I just found a problem with using subscription though. I tried replace 
 second with millisecond, while the minimax was executing (about less than 
 a 
 second)  the program keep calling more AIMove.


 subscriptions model =
   if (gameIsNotFinished model && model.turn == AIToMove) then
 Time.every millisecond AIMove


 Vào 23:54:21 UTC+7 Thứ Hai, ngày 10 tháng 10 năm 2016, OvermindDL1 đã 
 viết:
>
> The example he put above is fine:  :)
> ```
> subscriptions : Model -> Sub Msg
> subscriptions model =
>   if (gameIsNotFinished model && model.turn == AIToMove) then
> Time.every second AIMove
>   else
> Sub.none
> ```
> Though if you want it in another function you can do that too (useful 
> to batch functionality together):
> ```
> subAITick : Model -> Sub Msg
> subAITick model =
>   if (gameIsNotFinished model && model.turn == AIToMove) then
> Time.every second AIMove
>   else
> Sub.none
>
> subscriptions : Model -> Sub Msg
> subscriptions model =
>   subAITick
> ```
> Or if you have other subscriptions too, batching them together:
> ```
>
> subscriptions : Model -> Sub Msg
> subscriptions model =
>   Sub.batch
> [ subAITick
> ; otherSubscriptionsHere
> ]
> ```
>
>
> On Monday, October 10, 2016 at 10:48:34 AM UTC-6, hoang...@gmail.com 
> wrote:
>>
>> Can you show code example :D I'm quite new to Elm and javascript. 
>>
>> Vào 23:45:45 UTC+7 Thứ Hai, ngày 10 tháng 10 năm 2016, OvermindDL1 đã 
>> viết:
>>>
>>> Yep, just call it from the subscriptions callback then.
>>>
>>>
>>> On Monday, October 10, 2016 at 10:36:58 AM UTC-6, hoang...@gmail.com 
>>> wrote:

 This is quite a good idea. But can we define our own function that 
 can return a Sub Msg?

 Vào 20:41:40 UTC+7 Thứ Hai, ngày 10 tháng 10 năm 2016, Wouter In t 
 Velt đã viết:
>
> (disclaimer: I am also quite new to Elm) 
> I always try to avoid creating my own Cmd: there is usually a 
> better, less bug-prone way to achieve this (e.g. with resursive 
> update 
> calls).
>
> That said: I can see the logic in having a Msg originating from a 
> "real" player, and another Msg from your AI player.
>
> What you could do, is make a subscription to Time, that is only 
> active if it is the AI's turn to move.
> That way, you get a) a delay before the AI makes a move + b) you 
> do not need to create your own command
> Whenever it is the user's turn, or as soon as the game is over, 
> the subscription is turned off.
>
> Something like this:
>
> subscriptions : Model -> Sub Msg
> subscriptions model =
>   if (gameIsNotFinished model && model.turn == AIToMove) then
> Time.every second AIMove
>   else

[elm-discuss] Re: Subscribe to a model value then call update function when condition is met

[hoangtkc95]

But if I do it this way, it's gonna return both the player's move and the 
AI's move at the same time. What I want to have is that the game displays 
the player's move THEN call minimax function on current model and THEN 
display the AI's move

Vào 06:41:14 UTC+7 Thứ Tư, ngày 12 tháng 10 năm 2016, Luke Westby đã viết:
>
> It's a common misunderstanding that every discrete change to a model must 
> originate from a different message. In general messages are for expressing 
> what is allowed to happen in your application as a result of outside 
> behavior like user input and server responses, whereas you want to run your 
> AI as a direct, immediate result of your user making a move. What you 
> should do instead is write two functions, toggleAtIndex : Int -> Model -> 
> Model which handles the model changes under Toggle indexToToggle, and runAi 
> : Model -> Model, which handles the call to miniMax. Then in your single 
> Toggle message branch, call them both in the right order:
>
>
> toggleAtIndex indexToToggle model =
>   { model | board = move indexToToggle model.turn model.board }
>
> runAi model =
>   fst (miniMax model 0)
>
> update msg model =
>   case msg of
> Toggle indexToToggle ->
>   ( model
>   |> toggleAtIndex indexToToggle
>   |> runAi
>   , Cmd.none
>   )
>
>
> On Monday, October 10, 2016 at 2:23:51 AM UTC-5, hoang...@gmail.com wrote:
>>
>> I wrote an TicTacToe AI game. I published it here. 
>> https://tronyeu0802.github.io/TicTacToe-elm/
>>
>> Currently, when you make a move, the game will calculate an AI move then 
>> the browser will display both your move and the AI move at the same time. I 
>> did this by create and perform a task that always succeeds with the AIMove 
>>   message. 
>>
>> update msg model =
>>
>> case msg of
>>
>> Toggle indexToToggle ->
>>
>> ( { model
>>
>> | board = move indexToToggle model.turn model.board
>>
>>   }
>>
>> , Task.perform (\_ -> Debug.crash "This failure cannot 
>> happen.") identity (Task.succeed AIMove)
>>
>>   --Cmd.Extra.message AIMove
>>
>> )
>>
>>
>> AIMove ->
>>
>> ( fst (miniMax model 0)
>>
>> , Cmd.none
>>
>> )
>>
>>
>>  How can I display the player's move, then the AI's move after that?
>>
>> I'm thinking that this could be done by subscribing to the number of 
>> available moves left. If this is even then do an AI move else do nothing.
>>
>> I'm very new to ELM , I hope you teach better ways to achieve this. :D 
>> Thank you
>>
>>

-- 
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: Subscribe to a model value then call update function when condition is met

[Luke Westby]

It's a common misunderstanding that every discrete change to a model must 
originate from a different message. In general messages are for expressing 
what is allowed to happen in your application as a result of outside 
behavior like user input and server responses, whereas you want to run your 
AI as a direct, immediate result of your user making a move. What you 
should do instead is write two functions, toggleAtIndex : Int -> Model -> 
Model which handles the model changes under Toggle indexToToggle, and runAi 
: Model -> Model, which handles the call to miniMax. Then in your single 
Toggle message branch, call them both in the right order:


toggleAtIndex indexToToggle model =
  { model | board = move indexToToggle model.turn model.board }

runAi model =
  fst (miniMax model 0)

update msg model =
  case msg of
Toggle indexToToggle ->
  ( model
  |> toggleAtIndex indexToToggle
  |> runAi
  , Cmd.none
  )


On Monday, October 10, 2016 at 2:23:51 AM UTC-5, hoang...@gmail.com wrote:
>
> I wrote an TicTacToe AI game. I published it here. 
> https://tronyeu0802.github.io/TicTacToe-elm/
>
> Currently, when you make a move, the game will calculate an AI move then 
> the browser will display both your move and the AI move at the same time. I 
> did this by create and perform a task that always succeeds with the AIMove 
>   message. 
>
> update msg model =
>
> case msg of
>
> Toggle indexToToggle ->
>
> ( { model
>
> | board = move indexToToggle model.turn model.board
>
>   }
>
> , Task.perform (\_ -> Debug.crash "This failure cannot 
> happen.") identity (Task.succeed AIMove)
>
>   --Cmd.Extra.message AIMove
>
> )
>
>
> AIMove ->
>
> ( fst (miniMax model 0)
>
> , Cmd.none
>
> )
>
>
>  How can I display the player's move, then the AI's move after that?
>
> I'm thinking that this could be done by subscribing to the number of 
> available moves left. If this is even then do an AI move else do nothing.
>
> I'm very new to ELM , I hope you teach better ways to achieve this. :D 
> Thank you
>
>

-- 
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: Pure Elm contenteditable rich text editor

[Luke Westby]

Everything you need to do this should be available with the notable 
exception of the Selection API 
(https://developer.mozilla.org/en-US/docs/Web/API/Window/getSelection), 
which would allow you to manipulate the cursor and selected text 
programatically.

-- 
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: Another documentation item I think is needed

[J. E. Marca]

Thanks for the reply...

On Tuesday, October 11, 2016 at 4:36:47 AM UTC-7, Wouter In t Velt wrote:
>
> The comparison page you refer to is more a high-level comparison between 
> javascript and elm syntax.
> It does not look like it is intended to be in-depth.
>
> I agree it would be useful to have some docs at some time summing up the 
> pros and cons of List vs Array vs Set vs Dict.
> But I am not sure that the "From javascript" place would be the right 
> place.
>
>
I agree that "javascript" is probably not the best place.  However, as a 
newcomer, it is a place I studied a lot to get a feel for how to translate 
idioms I know from JS into Elm.

 

> PS: Getting an item from index in a List in Elm is quite straightforward
>
> getFromList : Int -> List a -> Maybe a
> getFromList index someList =
>   List.head <| List.drop index someList
>
> The main consideration vs Array or Dict (I think) is performance when the 
> lists get larger.
>
>

Thanks, that is cool.  And clearly "straightforward" is in the eye of the 
beholder.  On first read I laughed out loud --- I don't know what <| does, 
and it seems a random application of head and drop.  Reading closer, it 
*is* straightforward as you say... drop first n items (one based count), 
then get the next one (via List.head) and return that (which ends up being 
the traditional zero based index count).  Clever, but not something I can 
come up with on my own.  

Regardless, I wanted to *assign* to that element in the update loop, so 
Array works better for me.  This is what I'm doing.  My view has a bunch of 
buttons that onClick send a message and an index.  (The index value is 
built into the html element via  Array.indexedMap).  The update gets the 
index as so:


DetectorPlotVars ->
let
pvars = Array.get index model.detectorPlotVars
in
case pvars of
Just pvars ->
let
toggle = {pvars | on = not pvars.on}
newArr =  Array.set index toggle model.detectorPlotVars
in
({model | detectorPlotVars = newArr}
, getColorJson {model | detectorPlotVars = newArr})
_ -> (model, Cmd.none)



Please note that this will return a Maybe type (same as Array, and Dict BTW)
>

-- 
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] Pattern matching on aliased types

[Duane Johnson]

On Tue, Oct 11, 2016 at 7:36 AM, Ethan Martin 
wrote:

> How does one check against a List containing a certain type? For instance,
> I only want to map all elements of a string through the toString function
> if that list does not already contain strings. The end result would be a
> string resulting from a join.


toString is a bit magical in Elm, and can convert any type to a string. So
you can write your function this way:

import String

anyListToString list = List.map toString list |> String.join ""

-- 
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] Elm GUI component library

[Casper Bollen]

I would love to use ELM as my client side language. However, a show stopper 
at the moment is the lack of a decent ELM GUI component library. 

Currently I am using webix  an extremely simple to use 
library to create a complex one page application. I think it would be a 
great boost to the ELM usage if a library like that would be natively 
available. I also, tried to lure 
 the webix 
developers into looking at ELM.

If you, from ELM were to cooperate in implementing a sort of 'ELM webix' 
with the webix developers, this could be a very interesting project. I 
personally don't have the time and the skill to do this.

Just fishing here;-)

P.s. To get a gist of the kind of application I am working on see: 
http://github.com/halcwb/GenPDMS.git. Look at the latest commits in the 
client folder.

-- 
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: Pure Elm contenteditable rich text editor

[OvermindDL1]

This is also what I do for a CMS'ish style of interface in something at 
work, using elm-markdown to render a real-time view of what is being 
created.

Even pre-markdown back in decades past I still opted two have two panes, 
one where (at the time) html was put in, and the other showing the rendered 
html (in pseudo-realtime at the time, a refreshing frame, bleh).  You have 
no sudden jerks or disconnects or something unexpected unlike a WYSIWYG 
style (which I utterly *abhor* due to how many issues pretty much all of 
them have).


On Tuesday, October 11, 2016 at 1:49:53 PM UTC-6, Rolf Sievers wrote:
>
> If your users understand markdown, you could use markdown input and maybe 
> even render a preview.
>
> This is what I am doing for a project of mine. (This of course circumvents 
> the problem of writing a rich text editor but might help with your original 
> problem.)
>
> Am Montag, 10. Oktober 2016 22:42:49 UTC+2 schrieb Bulat Shamsutdinov:
>>
>> Hello!
>>
>> I have aside project which I really want to write in Elm. That project 
>> needs rich text edit (nothing fancy, just bullets and text styles).
>>
>> To my knowledge there is no solution to that task in Elm (which is a 
>> bummer). And even ports require nasty hacks (according to previous 
>> discussions here)
>>
>> Is there a way to implement that basic functionality using only Elm? 
>>
>>- Is it technically possible at the moment?
>>- What approach would you suggest?
>>
>>

-- 
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] Re: Html.Keyed

[OvermindDL1]

Eh, not really, it is precisely the same issues as you would have with, for 
example, React, or any of the other JS libraries that use virtual-doms. 
 Just an aspect of how web browser DOM's are made due to backwards 
compatibility with a lot of old sites over a period of many many decades. 
 Have to know about the platform that is being programmed for is all, this 
is not Elm specific.  :-)

Remember, it is just a diffing algorithm, when it gets to that point of 
your vdom and it compares an old vdom node of, for example:
```
  checkbox [ onClick (CheckToggle 42) ] [ text "Something" ]
```
and compares it to the new of:
```
  checkbox [ onClick (CheckToggle 43) ] [ text "Another thing" ]
```
It sees that there are two changes (well potentially 1 due to lack of keyed 
event handlers, but we'll say 2 for this example), thus it accesses the 
checkbox at the index that it is at here (say, 14 or so) by just something 
like `var node = curNode.children[14];` then just applies the two changes 
`node.removeEventHandler("click", 
oldEvent); node.addEventHandler("click", newEvent); 
node.children[0].nodeValue = "Another thing";`, which was just removing the 
old event handler, adding the new, and mutating the text.  Notice that it 
did not set the checked value because you never said what the checked value 
should be (thus meaning there was no difference in your defined checked 
state, thus it just leaves it at whatever it was since it sees no change to 
apply).

By making it keyed then it is like "oh, these do not match at all, probably 
a major structural change, kill the old, create the new".

If instead it did, as you imply, the deleting of the checkbox and 
recreating it so it has a consistent state regardless, then that would be 
an absolutely monstrous amount of DOM manipulating for, say, just a tiny 
text change, thus entirely defeating the point of a differencing system 
like a virtual dom (of which the sole purpose of is for speed), while also 
causing things like the checkbox to uncheck any time anything near its 
point on the DOM changed even by a single character in a text node.  :-)

If, however, you defined what the checked state should be in the vdom, then 
it would see that the old was checked, and the new was not, and would 
remove that property of it.  :-)


And as for cocoa, unlike the DOM anytime something like, say a checkbox is 
checked, cocoa sends a message to the application to handle the change, if 
unhandled then no update would happen... and the app would be frozen as the 
event loop would not be processing, unlike the DOM in a browser that would 
just keep on puttering along even if no handlers for any events were 
registered in javascript at all.  They are entirely different programming 
domains.

Some setups, like Angular 1, used two-way binding to overcome these issues, 
so the DOM could be reflected back in to the data model, however that is 
both hard to model and incurs significant speed hits based on access 
patterns (hence why Angular 2 got rid of it as I recall, though not messed 
with it to know for sure).


On Tuesday, October 11, 2016 at 1:33:38 PM UTC-6, Mark Hamburg wrote:
>
> I haven't yet dug into the actual example code, but this response goes 
> straight to the issue of continuity of identity that makes things like web 
> components an interesting problem for a functional virtual DOM.
>
> Mark
>
> P.S. I prototyped a system a few years ago on Cocoa in which view creation 
> was explicit — thereby providing identity — but property updates after 
> creation all came from reactive signals. It worked pretty well but took 
> more thought to use than does Elm's "just re-render the tree as you want 
> it" approach. What we're seeing here is that without identity — or with 
> erroneous identity — the diff the vdoms approach can have its own serious 
> surprises.
>
> On Oct 11, 2016, at 10:11 AM, OvermindDL1  > wrote:
>
> The ticked checkbox is because the user ticked it, it is some of the 
> implicit DOM state.  When the view changed to remove a checkbox but it 
> still had another one after, since they were not keyed it just did a 'diff' 
> between states.  The vdom has no information on any implicit state in the 
> actual DOM, in fact it does not access the actual DOM at all except to 
> apply patches, thus when it saw from its point of view that the checkbox 
> label had its name changed but nothing else different about it then it sent 
> a patch to change the text and that is all.  By changing the 'key' of it 
> then it knows that it is an entire tree change and will not even attempt a 
> patch but will instead rather re-generate the entire tree.
>
> Basically if a tree were to be regenerated just because some text changed 
> than that would make a virtual-dom extremely slow, its whole point is only 
> to generate a set of differences between two virtual-doms and apply those 
> differences to the real dom without ever reading anything from the real 

[elm-discuss] Re: Pure Elm contenteditable rich text editor

['Rolf Sievers' via Elm Discuss]

If your users understand markdown, you could use markdown input and maybe 
even render a preview.

This is what I am doing for a project of mine. (This of course circumvents 
the problem of writing a rich text editor but might help with your original 
problem.)

Am Montag, 10. Oktober 2016 22:42:49 UTC+2 schrieb Bulat Shamsutdinov:
>
> Hello!
>
> I have aside project which I really want to write in Elm. That project 
> needs rich text edit (nothing fancy, just bullets and text styles).
>
> To my knowledge there is no solution to that task in Elm (which is a 
> bummer). And even ports require nasty hacks (according to previous 
> discussions here)
>
> Is there a way to implement that basic functionality using only Elm? 
>
>- Is it technically possible at the moment?
>- What approach would you suggest?
>
>

-- 
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] Re: Html.Keyed

[Mark Hamburg]

I haven't yet dug into the actual example code, but this response goes straight 
to the issue of continuity of identity that makes things like web components an 
interesting problem for a functional virtual DOM.

Mark

P.S. I prototyped a system a few years ago on Cocoa in which view creation was 
explicit — thereby providing identity — but property updates after creation all 
came from reactive signals. It worked pretty well but took more thought to use 
than does Elm's "just re-render the tree as you want it" approach. What we're 
seeing here is that without identity — or with erroneous identity — the diff 
the vdoms approach can have its own serious surprises.

> On Oct 11, 2016, at 10:11 AM, OvermindDL1  wrote:
> 
> The ticked checkbox is because the user ticked it, it is some of the implicit 
> DOM state.  When the view changed to remove a checkbox but it still had 
> another one after, since they were not keyed it just did a 'diff' between 
> states.  The vdom has no information on any implicit state in the actual DOM, 
> in fact it does not access the actual DOM at all except to apply patches, 
> thus when it saw from its point of view that the checkbox label had its name 
> changed but nothing else different about it then it sent a patch to change 
> the text and that is all.  By changing the 'key' of it then it knows that it 
> is an entire tree change and will not even attempt a patch but will instead 
> rather re-generate the entire tree.
> 
> Basically if a tree were to be regenerated just because some text changed 
> than that would make a virtual-dom extremely slow, its whole point is only to 
> generate a set of differences between two virtual-doms and apply those 
> differences to the real dom without ever reading anything from the real dom 
> (as that is very slow).
> 
> It would indeed be preferable for checked-state to be controlled exclusively 
> via the model and view, however only an event is sent for those changes and 
> there is no way for the vdom to update its internal information otherwise, 
> and registering an event everywhere, even bubbled events, would again make 
> the vdom very slow and force the user to have to handle a lot of extra cases 
> (imagine checked state, text values, even focus and all being controlled like 
> this).
> 
> 
>> On Tuesday, October 11, 2016 at 11:01:57 AM UTC-6, Max Froumentin wrote:
>> Hi there,
>> 
>> Today I raised https://github.com/elm-lang/virtual-dom/issues/37
>> Given there's no consensus on whether it's a bug, I'm bringing the 
>> discussion here.
>> 
>> The reason why I think it's a bug is that the second time the view function 
>> runs it generates a ticked checkbox, although nowhere in the view function 
>> is there any indication that a ticked checkbox should be generated.
>> 
>> The alternative view is that the checkbox that's been clicked on has only 
>> been mutated with new data. That's why it remains ticked. You need to use 
>> Html.Keyed to tell elm that it is an entirely new checkbox.
>> 
>> I must say I'm not convinced why the view function should generate Html that 
>> depends on the previous state of the model.
>> 
>> Thanks for any insight.
> 
> -- 
> 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.

Re: [elm-discuss] Re: How important is Html.Lazy to performance?

[OvermindDL1]

Specifically the server sent a list of records over websocket one at a time 
(at times a *lot* of records), those were stored pretty much verbatim in 
the model.
I had a field on the model that was just an Int, started at 0, the view 
rendered the list of those records (just one part of the interface, though 
the largest, and just read-only) behind a lazy call that was just passed 
that integer, so the first render rendered it empty (technically a 
'loading' indicator if the integer was 0) and I received the records from 
the server until it stopped, once I got the last record then I just 
incremented it to 1 (I put it behind another message so I could just send 
that one message from anywhere to update that view).  Any time the server 
pushed a record update (remove/add/etc..) then I just kept incrementing the 
integer.  It was a perfectly suited method for my use-case, though it would 
be harder to do if it handled any user inputs and such (though still 
doable).

I had a similar setup in another elm app later but instead of using lazy I 
made my ProgramEx library, which added a `filter` callback so that I can 
just outright turn off view updating entirely for certain messages (as well 
as transforming messages, update other TEA things, etc..., filter was 
useful) and I just never ended up using lazy as keyed was perfect enough 
for most efficiency reasons (lazy could still be useful if the list got 
utterly huge though, but not for the new case).


On Tuesday, October 11, 2016 at 11:52:35 AM UTC-6, Mark Hamburg wrote:
>
> Interesting. I can understand using a sentinel to force re-rendering but 
> I'm curious as to how your model or view was structured such that it could 
> inhibit re-rendering via laziness.
>
> Mark
>
> On Oct 11, 2016, at 8:42 AM, OvermindDL1  
> wrote:
>
> Personally I've known it to help very little (keyed is usually more 
> appropriate), but there have been a few times where it saves significant 
> processing, but at those places I ended up setting it up with a 'sentry' 
> value in a model (just an integer) that I incremented every time I wanted 
> that lazy view to be re-rendered.  This was highly useful when I was 
> getting streamed a *ton* of data from a server over websocket that was 
> being placed all kinds of randomly into a keyed list (see keyed!), but this 
> was causing significant flickering and such until it was done, so I just 
> basically 'turned off' the rendering with lazy via the sentinel until I got 
> the last message.  That kept the model flat and lets my finely control when 
> I want the view to update.  I've not heard of others using it like this yet 
> and I'm unsure if it is well accepted, but I do not really use it for 
> 'optimization' per-say (the vdom is really plenty fast, and again use keyed 
> nodes when possible), but rather I used it as a better method of 
> controlling when the view is actually updated.
>
>
> On Tuesday, October 11, 2016 at 9:07:02 AM UTC-6, Mark Hamburg wrote:
>>
>> I was looking back at our first "big" (as in not the tiniest of toys) Elm 
>> app and at its tendency to factor the model based on the view hierarchy. 
>> This had struck me as a dubious pattern at the time and there is a strong 
>> argument voiced by some that one should just stay flat as long as possible. 
>> But why had we done it this way? Some of it certainly stemmed from the 
>> emphasis in the TEA documentation at the time on how one can nest 
>> model-update-view-message quads. But another part stemmed from wanting to 
>> use Html.Lazy fairly aggressively. That desire also led to more logic that 
>> tried to avoid generating new values when existing values would do. 
>>
>> So, my question in retrospect is: How important is using Html.Lazy to 
>> performance? Is it something one should put in at obvious break points 
>> where there are expected to be large subtrees? Is it something that should 
>> be used close to the leaves with the internal tree largely left non-lazy? 
>> Is it something that you ignore until it seems like things aren't fast 
>> enough and then start trying to contort your model and view to make lazy 
>> work? 
>>
>> My expectation from years of development is that on performance issues, 
>> one shouldn't go putting in more complicated code for problems that aren't 
>> yet known to exist — e.g., just sprinkling in laziness everywhere — but one 
>> should plan for what one would do if performance became a problem — e.g., 
>> if this were an issue, we could make it lazy right here. Lots of people 
>> adhere to the first principle citing concerns over "premature optimization" 
>> but the second principle tends to get less attention thereby leading to 
>> "sand in the gears" that can never be adequately addressed. 
>>
>> So, how import is lazy HTML and how does one best plan for its 
>> introduction where it proves necessary? 
>>
>> Mark 
>>
>> -- 
> You received this message because you are subscribed to the Google Groups 
> 

Re: [elm-discuss] Re: How important is Html.Lazy to performance?

[Mark Hamburg]

Interesting. I can understand using a sentinel to force re-rendering but I'm 
curious as to how your model or view was structured such that it could inhibit 
re-rendering via laziness.

Mark

> On Oct 11, 2016, at 8:42 AM, OvermindDL1  wrote:
> 
> Personally I've known it to help very little (keyed is usually more 
> appropriate), but there have been a few times where it saves significant 
> processing, but at those places I ended up setting it up with a 'sentry' 
> value in a model (just an integer) that I incremented every time I wanted 
> that lazy view to be re-rendered.  This was highly useful when I was getting 
> streamed a *ton* of data from a server over websocket that was being placed 
> all kinds of randomly into a keyed list (see keyed!), but this was causing 
> significant flickering and such until it was done, so I just basically 
> 'turned off' the rendering with lazy via the sentinel until I got the last 
> message.  That kept the model flat and lets my finely control when I want the 
> view to update.  I've not heard of others using it like this yet and I'm 
> unsure if it is well accepted, but I do not really use it for 'optimization' 
> per-say (the vdom is really plenty fast, and again use keyed nodes when 
> possible), but rather I used it as a better method of controlling when the 
> view is actually updated.
> 
> 
>> On Tuesday, October 11, 2016 at 9:07:02 AM UTC-6, Mark Hamburg wrote:
>> I was looking back at our first "big" (as in not the tiniest of toys) Elm 
>> app and at its tendency to factor the model based on the view hierarchy. 
>> This had struck me as a dubious pattern at the time and there is a strong 
>> argument voiced by some that one should just stay flat as long as possible. 
>> But why had we done it this way? Some of it certainly stemmed from the 
>> emphasis in the TEA documentation at the time on how one can nest 
>> model-update-view-message quads. But another part stemmed from wanting to 
>> use Html.Lazy fairly aggressively. That desire also led to more logic that 
>> tried to avoid generating new values when existing values would do. 
>> 
>> So, my question in retrospect is: How important is using Html.Lazy to 
>> performance? Is it something one should put in at obvious break points where 
>> there are expected to be large subtrees? Is it something that should be used 
>> close to the leaves with the internal tree largely left non-lazy? Is it 
>> something that you ignore until it seems like things aren't fast enough and 
>> then start trying to contort your model and view to make lazy work? 
>> 
>> My expectation from years of development is that on performance issues, one 
>> shouldn't go putting in more complicated code for problems that aren't yet 
>> known to exist — e.g., just sprinkling in laziness everywhere — but one 
>> should plan for what one would do if performance became a problem — e.g., if 
>> this were an issue, we could make it lazy right here. Lots of people adhere 
>> to the first principle citing concerns over "premature optimization" but the 
>> second principle tends to get less attention thereby leading to "sand in the 
>> gears" that can never be adequately addressed. 
>> 
>> So, how import is lazy HTML and how does one best plan for its introduction 
>> where it proves necessary? 
>> 
>> 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: Html.Keyed

[OvermindDL1]

The ticked checkbox is because the user ticked it, it is some of the 
implicit DOM state.  When the view changed to remove a checkbox but it 
still had another one after, since they were not keyed it just did a 'diff' 
between states.  The vdom has no information on any implicit state in the 
actual DOM, in fact it does not access the actual DOM at all except to 
apply patches, thus when it saw from its point of view that the checkbox 
label had its name changed but nothing else different about it then it sent 
a patch to change the text and that is all.  By changing the 'key' of it 
then it knows that it is an entire tree change and will not even attempt a 
patch but will instead rather re-generate the entire tree.

Basically if a tree were to be regenerated just because some text changed 
than that would make a virtual-dom extremely slow, its whole point is only 
to generate a set of differences between two virtual-doms and apply those 
differences to the real dom without ever reading anything from the real dom 
(as that is very slow).

It would indeed be preferable for checked-state to be controlled 
exclusively via the model and view, however only an event is sent for those 
changes and there is no way for the vdom to update its internal information 
otherwise, and registering an event everywhere, even bubbled events, would 
again make the vdom very slow and force the user to have to handle a lot of 
extra cases (imagine checked state, text values, even focus and all being 
controlled like this).


On Tuesday, October 11, 2016 at 11:01:57 AM UTC-6, Max Froumentin wrote:
>
> Hi there,
>
> Today I raised https://github.com/elm-lang/virtual-dom/issues/37
> Given there's no consensus on whether it's a bug, I'm bringing the 
> discussion here.
>
> The reason why I think it's a bug is that the second time the view 
> function runs it generates a ticked checkbox, although nowhere in the view 
> function is there any indication that a ticked checkbox should be generated.
>
> The alternative view is that the checkbox that's been clicked on has only 
> been mutated with new data. That's why it remains ticked. You need to use 
> Html.Keyed to tell elm that it is an entirely new checkbox.
>
> I must say I'm not convinced why the view function should generate Html 
> that depends on the previous state of the model.
>
> Thanks for any insight.
>
>

-- 
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] Html.Keyed

[Max Froumentin]

Hi there,

Today I raised https://github.com/elm-lang/virtual-dom/issues/37
Given there's no consensus on whether it's a bug, I'm bringing the 
discussion here.

The reason why I think it's a bug is that the second time the view function 
runs it generates a ticked checkbox, although nowhere in the view function 
is there any indication that a ticked checkbox should be generated.

The alternative view is that the checkbox that's been clicked on has only 
been mutated with new data. That's why it remains ticked. You need to use 
Html.Keyed to tell elm that it is an entirely new checkbox.

I must say I'm not convinced why the view function should generate Html 
that depends on the previous state of the model.

Thanks for any insight.

-- 
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: How important is Html.Lazy to performance?

[OvermindDL1]

Personally I've known it to help very little (keyed is usually more 
appropriate), but there have been a few times where it saves significant 
processing, but at those places I ended up setting it up with a 'sentry' 
value in a model (just an integer) that I incremented every time I wanted 
that lazy view to be re-rendered.  This was highly useful when I was 
getting streamed a *ton* of data from a server over websocket that was 
being placed all kinds of randomly into a keyed list (see keyed!), but this 
was causing significant flickering and such until it was done, so I just 
basically 'turned off' the rendering with lazy via the sentinel until I got 
the last message.  That kept the model flat and lets my finely control when 
I want the view to update.  I've not heard of others using it like this yet 
and I'm unsure if it is well accepted, but I do not really use it for 
'optimization' per-say (the vdom is really plenty fast, and again use keyed 
nodes when possible), but rather I used it as a better method of 
controlling when the view is actually updated.


On Tuesday, October 11, 2016 at 9:07:02 AM UTC-6, Mark Hamburg wrote:
>
> I was looking back at our first "big" (as in not the tiniest of toys) Elm 
> app and at its tendency to factor the model based on the view hierarchy. 
> This had struck me as a dubious pattern at the time and there is a strong 
> argument voiced by some that one should just stay flat as long as possible. 
> But why had we done it this way? Some of it certainly stemmed from the 
> emphasis in the TEA documentation at the time on how one can nest 
> model-update-view-message quads. But another part stemmed from wanting to 
> use Html.Lazy fairly aggressively. That desire also led to more logic that 
> tried to avoid generating new values when existing values would do. 
>
> So, my question in retrospect is: How important is using Html.Lazy to 
> performance? Is it something one should put in at obvious break points 
> where there are expected to be large subtrees? Is it something that should 
> be used close to the leaves with the internal tree largely left non-lazy? 
> Is it something that you ignore until it seems like things aren't fast 
> enough and then start trying to contort your model and view to make lazy 
> work? 
>
> My expectation from years of development is that on performance issues, 
> one shouldn't go putting in more complicated code for problems that aren't 
> yet known to exist — e.g., just sprinkling in laziness everywhere — but one 
> should plan for what one would do if performance became a problem — e.g., 
> if this were an issue, we could make it lazy right here. Lots of people 
> adhere to the first principle citing concerns over "premature optimization" 
> but the second principle tends to get less attention thereby leading to 
> "sand in the gears" that can never be adequately addressed. 
>
> So, how import is lazy HTML and how does one best plan for its 
> introduction where it proves necessary? 
>
> 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.

[elm-discuss] How important is Html.Lazy to performance?

[Mark Hamburg]

I was looking back at our first "big" (as in not the tiniest of toys) Elm app 
and at its tendency to factor the model based on the view hierarchy. This had 
struck me as a dubious pattern at the time and there is a strong argument 
voiced by some that one should just stay flat as long as possible. But why had 
we done it this way? Some of it certainly stemmed from the emphasis in the TEA 
documentation at the time on how one can nest model-update-view-message quads. 
But another part stemmed from wanting to use Html.Lazy fairly aggressively. 
That desire also led to more logic that tried to avoid generating new values 
when existing values would do.

So, my question in retrospect is: How important is using Html.Lazy to 
performance? Is it something one should put in at obvious break points where 
there are expected to be large subtrees? Is it something that should be used 
close to the leaves with the internal tree largely left non-lazy? Is it 
something that you ignore until it seems like things aren't fast enough and 
then start trying to contort your model and view to make lazy work?

My expectation from years of development is that on performance issues, one 
shouldn't go putting in more complicated code for problems that aren't yet 
known to exist — e.g., just sprinkling in laziness everywhere — but one should 
plan for what one would do if performance became a problem — e.g., if this were 
an issue, we could make it lazy right here. Lots of people adhere to the first 
principle citing concerns over "premature optimization" but the second 
principle tends to get less attention thereby leading to "sand in the gears" 
that can never be adequately addressed.

So, how import is lazy HTML and how does one best plan for its introduction 
where it proves necessary?

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] beginner question - updating property on child of model

[Chad Deutmeyer]

That worked great, Thanks for the help!

-- 
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: Another documentation item I think is needed

[Wouter In t Velt]

The comparison page you refer to is more a high-level comparison between 
javascript and elm syntax.
It does not look like it is intended to be in-depth.

I agree it would be useful to have some docs at some time summing up the 
pros and cons of List vs Array vs Set vs Dict.
But I am not sure that the "From javascript" place would be the right place.

PS: Getting an item from index in a List in Elm is quite straightforward

getFromList : Int -> List a -> Maybe a
getFromList index someList =
  List.head <| List.drop index someList

The main consideration vs Array or Dict (I think) is performance when the 
lists get larger.

Please note that this will return a Maybe type (same as Array, and Dict BTW)

-- 
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: Subscribe to a model value then call update function when condition is met

[Wouter In t Velt]

PS: The subscription to time is useful if you want some sort of timeout or 
delay between the user move and the AI move.
If you want to do the AI move immediately after the user move (without 
delay), 
a pattern with a recursive update call (and without subscription) is 
probably more suited.

Like so:

update msg model =
  case msg of
Toggle indexToToggle ->
  let
modelAfterUserMove =
  { model
  | board = move indexToToggle model.turn model.board
  }
  in
update AIMove modelAfterUserMove  -- here you do a recursive update 
call without any delay

AIMove ->
  ( fst (miniMax model 0)
  , Cmd.none
  )


-- 
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: list of types is missing from docs page at http://elm-lang.org/docs

[Wouter In t Velt]

In the standard docs, there is some explanation of types here 
. But no exhaustive 
list.

In practice, I found that I did not need to learn any of the standard 
types. 
In contrast to any other language I know, Elm's compiler is really helpful 
in providing you with info about your types.
If you do not provide a type signature for you functions, the compiler will 
give you a suggestion, which in 90%+ cases you can simply copy to your code.

-- 
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] Svg.map?

[Jeff Russell]

Great, thanks. 

-- 
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] Re: Integrating Elm with Web Components / Polymer

['Rupert Smith' via Elm Discuss]

On Monday, October 10, 2016 at 11:01:54 PM UTC+1, Richard Feldman wrote:
>
> Has anyone gotten anything doing really complicated DOM stuff (in 
> particular Google Maps comes to mind) working in Elm via web components?
>
> In theory it would Just Work, but in practice I always wonder... ;)
>

I have not yet encountered any scenarios yet where Elm updates to the DOM 
destroy the state of the component. I have been slightly surprised by this, 
given previous discussion around Html.Keyed and where it is sometimes 
needed. I guess Elm mostly is doing a good job of only making changes to 
the DOM that it really needs to. The actual complexity of the compnent 
should not be an issue, it is a 'shadow' encapsulated piece of the DOM 
after all.

I'm interested in expanding on the counter example to add more complexity - 
and I have a component in mind that will be useful to me - the listbox that 
I was working with previously.

The areas to add more complexity to are:

More complex data on initialization - for example, passing a list of items 
to init the list box with. This will be a List (String, String) in the Elm 
application -> json array of string, string -> List (String, String) in the 
Elm component. That is, just needs encoder/decoder written to handle it.

More complex data on update - same as above really, provide a list of 
selected items every time it changes.

More complex internal state on the component - more options on the 
component for things like max items to display before adding a scroll bar, 
the scroll bar and scroll state itself. Ability to fetch the list of items 
from the server, so I can configure a listbox like this , and have the component manage the 
request/response lifecycle itself.

It looks doable and should add up to a meatier example than the counter.

-- 
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] Re: Integrating Elm with Web Components / Polymer

['Rupert Smith' via Elm Discuss]

On Monday, October 10, 2016 at 10:40:25 PM UTC+1, Peter Damoc wrote:
>
> Now, the next challenge is to figure a way to declare all this in Elm and 
> automate as much as possible the process of creating the custom components. 
> :) 
>

I think rolling these Elm web components by hand should continue for a 
while until issues are ironed out and the pattern becomes well established. 
I do think we could get to a point where a web component is just a bit of 
boiler plate around an Elm program, at this point a tool could be written 
to automate the generation of the boilerplate - or perhaps something added 
to the compiler to provide a way of indicating that a module defines a 
webcomponent and should be compiled as such. Perhaps a little to early to 
start down that route?

-- 
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: How to insert an object into a list from a form

[Wouter In t Velt]

Op dinsdag 11 oktober 2016 09:45:57 UTC+2 schreef Did:
>
> Thanks for your reply! Is there a better way to do this or this is a 
> common solution in elm?
>

Well, this is the best way I can think of :)

But seriously, as soon as your app grows, some functions in this setup may 
become big and bloated, with lots of unnecessarily repeated code. Then (and 
only then) you may want to separate out some functions to separate files.
That would very much depend on the direction in which your app will grow 
first, e.g.:

   - If your article gets 20 fields instead of , you could put all fields 
   in a Dict, and have a generic update function that takes a key, and updates 
   the field in the Dict.
   - If you get extensive validation on fields, you may have separate 
   validation on fields before updating model.
   - If your ID will be provided by a server, rather than your client, that 
   bit of code may change.
   - If IDs are generated in the client in lots of other places, you could 
   have a separate ID generator helper.
   - If you want to allow editing of an existing single line, you will need 
   to need a modify (instead of add) function
   - If you want to allow editing multiple lines at once, ..
   - Etcetera

-- 
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] beginner question - updating property on child of model

[Duane Johnson]

On Mon, Oct 10, 2016 at 9:43 AM, Chad Deutmeyer 
wrote:

> { model | someOtherProperty = item }


I think you're looking for this:

let c = model.child in { model | child = { c | currentItem = item } }

-- 
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: list of types is missing from docs page at http://elm-lang.org/docs

[Nathan Eldridge]

Can you provide an example of the code? I am still fairly new myself, but I 
often find that I get errors when I get a little too loose with my type 
annotations.

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