Re: [elm-discuss] Elm with one message

[Mark Hamburg]

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

> On Aug 27, 2017, at 1:33 AM, Vlad GURDIGA  wrote:
> 
> Hey Mark! 
> 
> Thank you for taking time to look into this! 邏
> 
>> On Thursday, August 24, 2017 at 7:18:44 PM UTC+3, Mark Hamburg wrote:
>> Ignoring the commands and subscriptions part, I think this could be 
>> summarized as being built around having any of the things that would send a 
>> message instead send a new state. This eliminates the level of indirection 
>> of wrapping the desire to change the state into a message and then 
>> unwrapping the message to actually do the state change.
> 
> I haven’t though of it in such a well-formalized manner, but yes, that sounds 
> like it: I eliminate one level of indirection. Or at least at some level, 
> because at the very top there is still a message that triggers the update, 
> even if it’s a super-generic one. 樂
>  
>> It is entirely based on data and hence should be compatible with message 
>> recording for the debugger.
> 
> This looks about right too, as I mentioned in my response to Robin, the 
> debugger does as good of a job as it can with what I’m giving it. 
>  
>> On the other hand, the messages will lack semantic information. (One could 
>> work around that by adding a logging text field that was set when building 
>> the update message but ignored when applying it.)
> 
> Yeah, that’s true. As I’ve mentioned, the reason why I haven’t sensed this 
> problem is because I’m not using the Elm Reactor, because I don’t know how to 
> get ports playing inside it. 
>  
>> Where this would seem to fall down is commands and subscriptions. Those are 
>> going to produce asynchronous results and would risk baking in a stale model 
>> state. This is particularly true for commands. Imagine, for example, wiring 
>> up a tick command that will increment a tick field in the model after five 
>> seconds. Since the command will be constructed to send the single "set the 
>> state" message and since the only model it will have access to is the one 
>> that existed when the command was constructed, it basically becomes a "reset 
>> the state to where it was five seconds ago" command. If subscriptions really 
>> do get rebuilt after every cycle of the update loop, then this isn't a 
>> problem for them but the closure construction for each subscription is an 
>> expense. If they don't get rebuilt — and the code in the initial posting 
>> suggests that instead we're caching a subscriptions value — then as with 
>> commands, it would seem easy to end up with code that resurrects stale 
>> states.
> 
> Hm… I haven’t thought about this aspect of the commands+subscriptions duo, 
> although I think I understand the mechanics. 樂
> 
> So far I think I’m in luck: I have one port (a in/out couple actually) for 
> talking to an external rich text editor, which I expect to be modal. The user 
> clicks a button, the editor opens in a modal dialog, edit-edit-edit, then 
> closes the editor and passes back to Elm, so it’s serialized which means 
> there should not be any other changes to the Elm state while the editor is 
> open. 
> 
> I’m guessing in time, there could come in more things like background sync-up 
> of some kind, and then it’ll be really good to keep in mind these things that 
> you’re mentioning about stale states. 邏
> 
> Thank you! Really good catch! 
> -- 
> 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] Elm with one message

[Peter Damoc]

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.



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

Re: [elm-discuss] Elm with one message

[Vlad GURDIGA]

Hey Michael! 

Thank you for chipping in! 邏

On Friday, August 25, 2017 at 11:42:55 AM UTC+3, Michael Jones wrote:
>
> I can second Mark's point. At my company we had a little experiment where 
> chunks of state where sent in the messages. Not the whole model but not a 
> single unit either. It seemed really promising for a moment and quite clean 
> but then we started getting bugs which were very hard to understand. Turned 
> out to be exactly what Mark suggested. Between messages and commands we'd 
> have multiple copies of the same chunk of state in flight, each based on 
> some original value but each ignorant of the changes that the other were 
> representing. The end result was to just get the last state and lose 
> anything associated with other messages or commands happening around the 
> same time.
>
> We moved back to the standard strategy and all is well. 
>

So — just to check my understanding — the standard strategy is to only send 
enough bits of data with the message to describe the change that the update 
function needed to carry on, an not the actual changed bits of state. Am I 
close? 樂

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

Hey Mark! 

Thank you for taking time to look into this! 邏

On Thursday, August 24, 2017 at 7:18:44 PM UTC+3, Mark Hamburg wrote:
>
> Ignoring the commands and subscriptions part, I think this could be 
> summarized as being built around having any of the things that would send a 
> message instead send a new state. This eliminates the level of indirection 
> of wrapping the desire to change the state into a message and then 
> unwrapping the message to actually do the state change.
>

I haven’t though of it in such a well-formalized manner, but yes, that 
sounds like it: I eliminate one level of indirection. Or at least at some 
level, because at the very top there is still a message that triggers the 
update, even if it’s a super-generic one. 樂
 

> It is entirely based on data and hence should be compatible with message 
> recording for the debugger.
>

This looks about right too, as I mentioned in my response to Robin 
, the 
debugger does as good of a job as it can with what I’m giving it. 
 

> On the other hand, the messages will lack semantic information. (One could 
> work around that by adding a logging text field that was set when building 
> the update message but ignored when applying it.)
>

Yeah, that’s true. As I’ve mentioned 
, the 
reason why I haven’t sensed this problem is because I’m not using the Elm 
Reactor, because I don’t know how to get ports playing inside it. 
 

> Where this would seem to fall down is commands and subscriptions. Those 
> are going to produce asynchronous results and would risk baking in a stale 
> model state. This is particularly true for commands. Imagine, for example, 
> wiring up a tick command that will increment a tick field in the model 
> after five seconds. Since the command will be constructed to send the 
> single "set the state" message and since the only model it will have access 
> to is the one that existed when the command was constructed, it basically 
> becomes a "reset the state to where it was five seconds ago" command. If 
> subscriptions really do get rebuilt after every cycle of the update loop, 
> then this isn't a problem for them but the closure construction for each 
> subscription is an expense. If they don't get rebuilt — and the code in the 
> initial posting suggests that instead we're caching a subscriptions value — 
> then as with commands, it would seem easy to end up with code that 
> resurrects stale states.
>

Hm… I haven’t thought about this aspect of the commands+subscriptions duo, 
although I think I understand the mechanics. 樂

So far I think I’m in luck: I have one port (a in/out couple actually) for 
talking to an external rich text editor, which I expect to be modal. The 
user clicks a button, the editor opens in a modal dialog, edit-edit-edit, 
then closes the editor and passes back to Elm, so it’s serialized which 
means there should not be any other changes to the Elm state while the 
editor is open. 

I’m guessing in time, there could come in more things like background 
sync-up of some kind, and then it’ll be really good to keep in mind these 
things that you’re mentioning about stale states. 邏

Thank you! Really good catch! 

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

Hey Robin! 

Thank you for checking and thinking about my exploration here! 

On Thursday, August 24, 2017 at 11:31:20 AM UTC+3, Robin Heggelund Hansen 
wrote:
>
> Won't this break the reactor/debugger? You can't really tell what sort of 
> messages is being passed around in your application with this model, if you 
> want to export message history, it would fail as well I believe.
>

If by “break” you mean that I won’t be able to tell by looking at the 
message history in the Debugger window, then you’re right: there is only 
one kind of message, and you can’t really tell much just by looking at 
that. 

The reason it wasn’t an issue for me is that I didn’t use the Debugger and 
stopped using the Reactor as soon as I brought in ports. I don’t know how 
to plug in the JS that I call through ports, without having a separate 
index.html 

 
in which I plug the external library 

, the bundle coming out of Elm 
,
 
and then the bits of glue code 

 
to tie them together. 

I’m wondering if anyone has experience with having ports working with the 
Elm Reactor. 樂
 

> I think a better way would be to not have nested components. Keep your 
> entire message hierarchy, and model structure, flat.
>

Yeah, this is the default recommendation that I hear in the Elm community. 
I’ve heard Richard Feldman mentioning that they also have a flat structure 
for their production app at NoRedInk, but I think I just can’t imagine how 
would that look like, and then, as I guess every other mortal, I fallback 
to ways that I know. 

One other reason why I went hierarchical is that I’m used to seeing domain 
models as hierarchies, and in My Ideal World®✨ the code follows the domain 
as close as possible. 

I’m definitely open to hearing, or — even better — *seeing* examples of 
large apps that use a flat structure. 邏

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

Hey Peter! 

Thank you for looking into this thing! 邏

On Thursday, August 24, 2017 at 10:47:24 AM UTC+3, Peter Damoc wrote:
>
> On of the key recommendations of Elm Architecture is to have your messages 
> be just data. 
>
> Your approach is somewhat similar to the approach of elm-sortable-table 
> (except for the Cmds and Subs). 
>
> Without  using Cmds and/or Subs it is an interesting approach if you use 
> it for managing very small bits of state (the open/close status of a 
> dropdown) but I'm afraid that it might bring performance problems if you 
> use it for the entirety of the app. 
>

Regarding “very small bits” — I think this idea was one of the goals of 
going this way: any module represents one domain concept, and its view’s 
callback function deals with a value of that domain concept’s type. If a 
module refers to another domain concept, that concept has its separate 
module with its type, and view, and callback function that only knows about 
itself. (Well, ideally at least, for the most part, you know… )
 

> 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? 樂 

-- 
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] Passing whole state to each view function

[Simon]

Just bumping this to the top as it has the best discussion of html lazy 
that I know of in this mailing list and Evan's latest talk (React Rally) 
emphasised lazy there is such a way that I think I had better start using 
it better

On Wednesday, 2 August 2017 05:17:01 UTC+2, ajs wrote:
>
> Hi Mark, feel free to hit me up on Slack sometime to discuss further. My 
> last two messages to this list have had more than one week delay in posting 
> (ignore the timestamp, I'm posting this on Friday July 21), so that might 
> be easier. 
>
> I discussed these ideas quite a bit with @ilias and he made a rather 
> interesting example of doing some things relating to state access: 
> https://github.com/zwilias/elm-disco
>
> I'm a firm believer that view functions should only receive data that they 
> directly interact with, and nothing more. I've just found that to be a much 
> better way to reason about interfaces.
>
> On 21 Jul 2017, at 19:04, Mark Hamburg  
> wrote:
>
> Per the other thread discussing this this morning, I don't know that 
> passing the whole data model to all of the view-side functions is that 
> horrendous. (We pass around a UXConfig structure in all of our views to 
> provide access to translation functions amongst other things and the 
> biggest pain is that I'm not certain that making it he first parameter by 
> convention was the right choice.) Passing the whole data model feels icky, 
> but you can document the dependencies using different modules to access 
> different parts of the data model and you can still keep data model 
> mutation out of the views by emulating the command mechanism.
>
> That said, there are, definitely friction points where being able to 
> subscribe to pieces of the data model would be a significant improvement. 
> See my other message for some examples of these. But the friction is not in 
> needing to pass the whole data model through the rendering process.
>
> Mark
>
> On Fri, Jul 21, 2017 at 6:55 AM ajs  
> wrote:
>
>> > However, the downside of doing passing the entire model everywhere is 
>> that you have to keep the entire model in your head when looking at any of 
>> your view functions.
>>
>> This is correct, but how can you avoid passing the whole model to all 
>> views if the data model isn't structured similarly to your view hierarchy? 
>> The idea of doing pre-processing on your data into a view-friendly 
>> structure seems to add overhead and complexity, while also more or less 
>> duplicating your view structure in two places: the view stack, and the view 
>> data.
>>
>> We have found that as apps grow in size, it is unreasonable to couple a 
>> data model's internal structure to the requirements of a UI, and thus 
>> passing The whole model is the only valid option for most view functions. 
>> The exception are leaf nodes down the line that have few or no children, in 
>> which case they can receive focused inputs only.
>>
>> --
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
> -- 
> You received this message because you are subscribed to a topic in the 
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/elm-discuss/F5pdcsls1Zc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> elm-discuss...@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.