Re: [elm-discuss] Re: Separating model state structure from the view hierarchy

[Mark Hamburg]

Confluence of threads between this one and the question about subscriptions
just made me realize that passing the data model down through the view
model hierarchy on each update to the data model is not the worst thing in
the world from a performance standpoint when you consider that a
subscription-based approach would be collecting up subscriptions from all
of the parts of the view model hierarchy and that would seem like a similar
amount of work unless one cached a lot of the subscriptions in the view
model for faster return.

So, that's good. On the other hand, another thing that subscriptions are
good for that this doesn't answer is as a way of expressing interest.
Imagine a data model with a list of chats and for each chat we have a list
of messages:

chats : DataModel -> Dict ChatID String -- chat id's and names

messages : DataModel -> ChatID -> List Message

We can pass the full data model around. The chat list view can extract the
list of chats. A message view for a particular chat can extract the list of
messages.

For efficiency reasons, we may only want to stay synchronized to the cloud
on the chat list and the current chat. Knowing which chat is current,
however, is really a view-side property. For example, the above API would
be just as friendly to having views into two chats at once. We could have
data model operations to start and stop following a chat. Starting is easy.
We just send the appropriate out message when we construct the view.
Stopping, however, is harder. One of the nice things about subscriptions is
that they go away when the piece of the model doing the subscribing goes
away. The functions we probably really want are something like:

getActiveChats : ViewModel -> Set ChatID

setActiveChats : Set ChatID -> DataModel -> DataModel


We need to call the former routine whenever the view model changes and use
the results to update the data model. Since that will change the data
model, we should then pass the updated data model to the view model causing
an update to the view model thereby looping us back around. To stop the
loop, we need to recognize when something hasn't changed and break the
cycle. That's easy enough but fragile since it would use an equality test
and equality isn't safe to use on arbitrary types. Effects managers don't
have this problem because we don't update the effects manager based on the
main model but rather the effects manager sends messages back to the main
model.

(I'm thinking about this a lot right now because I'm trying to move code to
an API where we need to request rendition URLs based on asset IDs over a
web socket where we are maintaining a synchronized set of assets of
interest between the cloud and the client. Coming up with a clean way to
organize the code is resulting in lots of exploratory sketches.)

Mark

On Fri, Jul 21, 2017 at 9:43 AM, Mark Hamburg  wrote:

> One argument against the "pass the model to all view functions" approach
> is that it pretty much blows up laziness.
>
> If one ignores that, then one could do something like the following:
>
> * All view-side functions including both update and view receive a global
> context containing the data model. (First argument? Last argument? I'm not
> just throwing this out here. I'm looking for feedback on conventions
> because I've had other places where a global context parameter has come
> up.) This can be in addition to view-side model data as well such as which
> element has focus.
>
> * Commands get replaced on the view side with a construct that can embody
> both operations on the outside world (i.e., traditional Elm commands) and
> operations on the data model. The view side doesn't get write access to the
> data model. The data model is modified in an update fold just as is normal
> for Elm models.
>
> The downsides to this approach include:
>
> * It obscures the true dependencies between the data model and the views.
> The compiler will catch changes (assuming they affect type signatures) but
> the codebase may still feel hard to reason about. That said, one could
> always provide multiple modules for interpreting the data model and one
> could look at the dependices on those modules to reason about the
> relationship of the views to the data model. In other words, it seems icky
> but it might not be in practice.
>
> * The view code can't react to changes in the data model — or at least
> can't do so cheaply. This matters because the view code may want to do
> things like change what it is focused on if an item in the data model goes
> away. Or in the case of the code I'm working on, we have some expensive
> layout logic that depends on he width of the view and the list of items
> displayed in the view. We don't want to run this logic every time we render
> so we need to know when either the width (a view-side property) or the item
> list (a data-model property) changes. The non-cheap solution here is
> broadcasting the new data model (or the old and the 

Re: [elm-discuss] Passing whole state to each view function

[Raoul Duke]

if passing the whole db, i wonder if i want something like structural types
on the consuming apis to keep things more clear & safe & sane.

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

[Mark Hamburg]

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+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: Why is the signature of 'program.subs' 'model -> Sub msg' ?

[Mark Hamburg]

My understanding is that yes, Elm does this with every update and then the
effects managers have to look at the new subscriptions and compare them to
the old subscriptions. I would love to hear that my understanding is wrong
because while this isn't bad if you have just a few subscriptions, it seems
like potentially a lot of overhead if you have a lot of subscriptions.

One could envision subscriptions being implemented more like views in which
there would be a differ that would generate patches to send to the effects
managers and there would be a subscription equivalent to Html.Lazy that
would cut off a lot of the computation when nothing had changed. This would
probably make frequent update to subscriptions less scary computationally
but it isn't how things are done.

Finally, you haven't asked the other subtle question brought on by dynamic
subscriptions: if you stop returning a subscription, are you guaranteed
that you won't receive any messages targeted to that subscription or are
you only guaranteeing that no more messages will be queued or even weaker
are you only letting the effects manager know that you aren't really
interested any more?

Mark

On Fri, Jul 21, 2017 at 6:55 AM Vasily Vasilkov 
wrote:

> Does it mean that Elm runtime creates and cancels subscriptions on the fly
> (for  every model change)?
>
>
>
> On Mon, Jul 17, 2017 at 6:19 PM +0400, "Marek Fajkus"  > wrote:
>
> Sometimes you don't need subscriptions if you're in some state. For
>> instance, if you have game and subscription to say mouse position you can
>> subscribe to Mouse.position only when a user is in play state and avoid
>> subscription in game menu.
>>
>> --
>> 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.
>

-- 
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: Separating model state structure from the view hierarchy

[Mark Hamburg]

One argument against the "pass the model to all view functions" approach is
that it pretty much blows up laziness.

If one ignores that, then one could do something like the following:

* All view-side functions including both update and view receive a global
context containing the data model. (First argument? Last argument? I'm not
just throwing this out here. I'm looking for feedback on conventions
because I've had other places where a global context parameter has come
up.) This can be in addition to view-side model data as well such as which
element has focus.

* Commands get replaced on the view side with a construct that can embody
both operations on the outside world (i.e., traditional Elm commands) and
operations on the data model. The view side doesn't get write access to the
data model. The data model is modified in an update fold just as is normal
for Elm models.

The downsides to this approach include:

* It obscures the true dependencies between the data model and the views.
The compiler will catch changes (assuming they affect type signatures) but
the codebase may still feel hard to reason about. That said, one could
always provide multiple modules for interpreting the data model and one
could look at the dependices on those modules to reason about the
relationship of the views to the data model. In other words, it seems icky
but it might not be in practice.

* The view code can't react to changes in the data model — or at least
can't do so cheaply. This matters because the view code may want to do
things like change what it is focused on if an item in the data model goes
away. Or in the case of the code I'm working on, we have some expensive
layout logic that depends on he width of the view and the list of items
displayed in the view. We don't want to run this logic every time we render
so we need to know when either the width (a view-side property) or the item
list (a data-model property) changes. The non-cheap solution here is
broadcasting the new data model (or the old and the new data model) through
the view hierarchy on roughly every data model update.

Another solution would be to manage the data model via an effects manager
thereby allowing it to expose both commands for changes and subscriptions
for updates. This seems ideal for the scenario you've presented. The
problem is that effects managers cannot, AFAIK — please correct me if I'm
wrong, use other effects managers, so taking this approach cuts your data
model code off from the standard web sockets and HTTP implementations.

To get any deeper into Elm-based approaches, I think we would need to know
more about Re-Frame so any further details you can supply or point to would
be welcome.

Mark

On Fri, Jul 21, 2017 at 8:29 AM Martin Norbäck Olivers 
wrote:

> Hi!
> We discussed this on the slack the other day, right?
> Let me just get this straight, the Re-Frame solution depends on functions
> having access to a global "db" object or similar (that corresponds to the
> Elm model)?
>
> How is that conceptually different than passing the model as a parameter
> through the functions? Any function can access any part of the state by
> subscribing in Re-Frame, just as it can access any part of the state by
> accessing the passed-through model in Elm.
>
> I just want to know what more this gives than avoiding the boilerplate of
> passing the model through.
> Btw, Elm has pure functions so implementing this straight-off is not
> possible.
>
> Regards,
>
> Martin
>
> Den fredag 21 juli 2017 kl. 15:55:42 UTC+2 skrev ajs:
>>
>> I had an interesting discussion with several members on the #beginners
>> channel on Slack. It was suggested I post this out to the larger community
>> for input.
>>
>> As a quick background, I'm a professional Clojurescript developer for
>> many years, and have been through the early days of React (when it was just
>> wrapped as Om in Clojurescript), and then Reagent, and then the most
>> versatile and structured tool, Re-Frame, which has emerged as a leading
>> model of UI <-> Model interaction. I am now looking seriously at Elm on my
>> company's behalf and we are testing a prototype for a component in it.
>>
>> The Elm Architecture is often compared to Redux and Re-Frame. The overall
>> flow is similar, however there is a particular problem that plagued
>> Clojurescript's Om in the early days that was eventually worked out in
>> Re-Frame and in later versions of Om. This problem, however, does not
>> appear to have a solution in Elm, and I wish to outline it here. It is a
>> common problem that occurs in modelling a UI in a complex SPA, anything
>> truly non-trivial.
>>
>> The way the Elm Architecture works, and in the early Om, is that you have
>> a single piece of state that acts as the truth for your app, and then you
>> have view functions that receive parts of this state (or all of it), and
>> then they call children view functions and pass along parts of the state
>> they received. I have 2 

[elm-discuss] Re: Separating model state structure from the view hierarchy

[Martin Norbäck Olivers]

Hi!
We discussed this on the slack the other day, right?
Let me just get this straight, the Re-Frame solution depends on functions 
having access to a global "db" object or similar (that corresponds to the 
Elm model)?

How is that conceptually different than passing the model as a parameter 
through the functions? Any function can access any part of the state by 
subscribing in Re-Frame, just as it can access any part of the state by 
accessing the passed-through model in Elm.

I just want to know what more this gives than avoiding the boilerplate of 
passing the model through.
Btw, Elm has pure functions so implementing this straight-off is not 
possible.

Regards,

Martin

Den fredag 21 juli 2017 kl. 15:55:42 UTC+2 skrev ajs:
>
> I had an interesting discussion with several members on the #beginners 
> channel on Slack. It was suggested I post this out to the larger community 
> for input.
>
> As a quick background, I'm a professional Clojurescript developer for many 
> years, and have been through the early days of React (when it was just 
> wrapped as Om in Clojurescript), and then Reagent, and then the most 
> versatile and structured tool, Re-Frame, which has emerged as a leading 
> model of UI <-> Model interaction. I am now looking seriously at Elm on my 
> company's behalf and we are testing a prototype for a component in it.
>
> The Elm Architecture is often compared to Redux and Re-Frame. The overall 
> flow is similar, however there is a particular problem that plagued 
> Clojurescript's Om in the early days that was eventually worked out in 
> Re-Frame and in later versions of Om. This problem, however, does not 
> appear to have a solution in Elm, and I wish to outline it here. It is a 
> common problem that occurs in modelling a UI in a complex SPA, anything 
> truly non-trivial.
>
> The way the Elm Architecture works, and in the early Om, is that you have 
> a single piece of state that acts as the truth for your app, and then you 
> have view functions that receive parts of this state (or all of it), and 
> then they call children view functions and pass along parts of the state 
> they received. I have 2 Elm examples below, in a moment.
>
> The fundamental problem with this approach is that it creates a tight 
> coupling between the organization of your model data and that of your view 
> hierarachy. What the Om users realized is that a robust model should not 
> depend on the views for its structure. But the Elm Architecture kind of 
> requires that (as far as I can tell). Data models should not be structured 
> based on what works for a user interface; they need to honor the 
> requirements of the data, only. 
>
> A very large and prominent Om-based user-interface is that which CircleCI 
> uses. They wrote about this issue here:
>
> (skip to the heading "The Conundrum Of Cursors: Most Data Is Not A Tree.")
>  https://circleci.com/blog/why-we-use-om-and-why-were-excited-for-om-next/
>
> If the model does not fit the needs of the view hierarchy, then what 
> emerged in the old Om was the unfortunate side effect of passing the entire 
> model state through all view functions. I hear that this is not uncommon in 
> Elm as well.
>
> It has plagued many companies (including mine), which eventually led to a 
> much better way of data interacting with a UI in Re-Frame, which I will 
> summarize in a moment.
>
> The problem arises when a view child needs data in the central model that 
> its parent did not need or receive. The parents and ancestors should not 
> require awareness of specific model details that a distant child might 
> need. For example, a view function might have the job of displaying Screen 
> A or Screen B. It is passed a flag, perhaps, that tells it which screen to 
> build, and then it calls a view function for that screen. Simple as that; 
> it doesn't need to know that Screen B has a widget that contains a dropdown 
> menu that must show a list of items from somewhere in the central model, 
> and that it must also find and pass that list to the screen view function.  
>
> The other problem that arises is when a child requires access to more than 
> one part of the central model, and those parts are not "in the same place". 
>
> One "solution": you pass the entire model state to all view functions, 
> then each view just takes what it needs. But this is very poor for a 
> variety of reasons, not the least of which is that children now have much 
> more access than they need. And it can lead to more code as each child has 
> to go grab what it needs from a large monolithic data source before 
> operating it -- it requires children to be responsible for both the query 
> and the processing. It makes it hard to trace data access through your app 
> when all views access the same global model. And it requires more code on 
> behalf of children.
>
> Here are two Elm examples that show the problem:
>
> Line 22 on:
> https://ellie-app.com/3JbGH7v2v7ra1/1
> How to give the child 

Re: [elm-discuss] main : Program Never Model Msg -- What does it mean?

[Андрей Коппель]

This means that main returns Program type 
(http://package.elm-lang.org/packages/elm-lang/core/5.1.1/Platform#Program 
). 
It has three arguments which are flags, model and msg. Never means there will 
no always no flags. Model is your defined Model type. Msg is your defined Msg 
type.



Best,
Andrey

> On 21 Jul 2017, at 13:39, Eeek  wrote:
> 
> I am beginner in Elm, and going through elm-tutorial.org. I have problem in 
> understanding the declaration of main function in 
> https://www.elm-tutorial.org/en/02-elm-arch/02-structure.html. It says 
> 
> main : Program Never Model Msg
> 
>  What does it represent? I read under functions tutorial that, arguments are 
> separated with ->. If there are no arguments then I would expect only one 
> return. This don't belong to any of it. What is this way of declaring the 
> function types?
> 
> -- 
> 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: Unexpected compiler behaviour and message "pattern is redundant".

[Patrick Stubner]

I haven't really used Elm that much, but you may want something like this:


module Main exposing (..)

import Html exposing (Html, text, div)

type Message = Good | Bad | ManyOthers

type alias Node = { message : Message }

trymatch : Node -> Message -> Bool
*trymatch node messageParam =*
*node.message == messageParam*

evalTrue = trymatch { message = Good } Good
evalFalse = trymatch { message = Good } Bad

main : Html a
main =
div []
[ text (toString evalTrue)
, text " / "
, text (toString evalFalse)]


You can try it out in https://ellie-app.com

P@


Am Sonntag, 9. Juli 2017 22:55:27 UTC+2 schrieb jadski:
>
> Hi, I am getting a compiler error that does not make sense to me - can 
> anyone help to explain why this fails to compile?
>
> The following code:
>
> 
> type Message = Good | Bad | ManyOthers
>
> type alias Node = { message : Message }
>
> trymatch : Node -> Message -> Bool
> trymatch node messageParam =
> case node.message of
> messageParam ->
> True
> _ ->
> False
>
> evalTrue = trymatch { message = Good } Good
> evalFalse = trymatch { message = Good } Bad
> 
>
> Generates this compilation error:
>
> 
> The following pattern is redundant. Remove it.
>
> 10| _ ->
> ^
> Any value with this shape will be handled by a previous pattern.
> 
>
> However node.message and messageParam can clearly be different, as in 
> evalFalse.
>
> Hence the message "Any value with this shape will be handled by a previous 
> pattern." appears incorrect, and is confusing me.
>
> A helpful slacker suggested using "if node.message == messageParam then", 
> which compiles, but doesn't clarify what's going wrong here.
>
>

-- 
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: ADT: How to know whether two values have the same constructor?

[Gabriel Sartori]

I am not sure if this snippet would help you
 

> type ValA = A1 | A2
>
type Bla = A ValA Int | B Int 
>

valA1 = A 1 A1
> valA2 = A 2 A2
>
>
>
>

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

[ajs]

> 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] ADT: How to know whether two values have the same constructor?

[Allan Clark]

If you want to have the compiler complain when you add a new constructor then:

haveSameConstructor : Bla -> Bla -> Bool
haveSameConstructor first second =
case (first, second) of
(A _, A _) -> True
(A _, _) -> False

(B _, B _) -> True
(B _, _) -> False

On 17 July 2017 at 08:34, Birowsky  wrote:
> That's not so bad. But the compiler wouldn't be able to nudge me to add a
> new comparison when I add a new constructor in the Bla union.
>
> Thanx anyways.
>
> --
> 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] any editor supports elm simple whole-buffer reformat?

[Wendel Wang]

For me the LightTable elm-light plugin works well.
You install it with the plugin manager and then set up the keymapping 
depending on you rpreferences.
An example setup is given in the elm-light docu that you can just cut and 
paste into you user-settings file.

I have set up elm-format on save.

Some other functions are also useful and in-editor linting works as well.

You mentioned you faced difficulties using LightTable. What was the problem?

-- 
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] Separating model state structure from the view hierarchy

[ajs]

I had an interesting discussion with several members on the #beginners 
channel on Slack. It was suggested I post this out to the larger community 
for input.

As a quick background, I'm a professional Clojurescript developer for many 
years, and have been through the early days of React (when it was just 
wrapped as Om in Clojurescript), and then Reagent, and then the most 
versatile and structured tool, Re-Frame, which has emerged as a leading 
model of UI <-> Model interaction. I am now looking seriously at Elm on my 
company's behalf and we are testing a prototype for a component in it.

The Elm Architecture is often compared to Redux and Re-Frame. The overall 
flow is similar, however there is a particular problem that plagued 
Clojurescript's Om in the early days that was eventually worked out in 
Re-Frame and in later versions of Om. This problem, however, does not 
appear to have a solution in Elm, and I wish to outline it here. It is a 
common problem that occurs in modelling a UI in a complex SPA, anything 
truly non-trivial.

The way the Elm Architecture works, and in the early Om, is that you have a 
single piece of state that acts as the truth for your app, and then you 
have view functions that receive parts of this state (or all of it), and 
then they call children view functions and pass along parts of the state 
they received. I have 2 Elm examples below, in a moment.

The fundamental problem with this approach is that it creates a tight 
coupling between the organization of your model data and that of your view 
hierarachy. What the Om users realized is that a robust model should not 
depend on the views for its structure. But the Elm Architecture kind of 
requires that (as far as I can tell). Data models should not be structured 
based on what works for a user interface; they need to honor the 
requirements of the data, only. 

A very large and prominent Om-based user-interface is that which CircleCI 
uses. They wrote about this issue here:

(skip to the heading "The Conundrum Of Cursors: Most Data Is Not A Tree.")
 https://circleci.com/blog/why-we-use-om-and-why-were-excited-for-om-next/

If the model does not fit the needs of the view hierarchy, then what 
emerged in the old Om was the unfortunate side effect of passing the entire 
model state through all view functions. I hear that this is not uncommon in 
Elm as well.

It has plagued many companies (including mine), which eventually led to a 
much better way of data interacting with a UI in Re-Frame, which I will 
summarize in a moment.

The problem arises when a view child needs data in the central model that 
its parent did not need or receive. The parents and ancestors should not 
require awareness of specific model details that a distant child might 
need. For example, a view function might have the job of displaying Screen 
A or Screen B. It is passed a flag, perhaps, that tells it which screen to 
build, and then it calls a view function for that screen. Simple as that; 
it doesn't need to know that Screen B has a widget that contains a dropdown 
menu that must show a list of items from somewhere in the central model, 
and that it must also find and pass that list to the screen view function.  

The other problem that arises is when a child requires access to more than 
one part of the central model, and those parts are not "in the same place". 

One "solution": you pass the entire model state to all view functions, then 
each view just takes what it needs. But this is very poor for a variety of 
reasons, not the least of which is that children now have much more access 
than they need. And it can lead to more code as each child has to go grab 
what it needs from a large monolithic data source before operating it -- it 
requires children to be responsible for both the query and the processing. 
It makes it hard to trace data access through your app when all views 
access the same global model. And it requires more code on behalf of 
children.

Here are two Elm examples that show the problem:

Line 22 on:
https://ellie-app.com/3JbGH7v2v7ra1/1
How to give the child data that its parent didn't need or receive? Here, 
I've hard-coded it to 0 because there is no other obvious way to access 
what the child needs.

Another attempt:
https://ellie-app.com/3JbNQk26qNRa1/0
On Line 32, an ancestor is still having to hunt down data that a 
potentially very distant child would need, and actually handle the building 
of that child.

We have an app with hundreds, perhaps over a thousand, independent view 
components, in a hierarchy about a hundred levels deep. This relationship 
between data and components breaks down at that scale (and actually at 
scales far smaller than ours) -- unless you can provide me with a technique 
I haven't considered. It either leads to a lot of spaghetti code where 
things have access to data they shouldn't and where components are handling 
lots of intermediate data they don't directly use, or, it leads to 

[elm-discuss] Re: Elm.fullscreen is not a function

[Denis Kolodin]

Another reason for 0.18: I take `Elm.MyApp.fullscreen is not a function` 
when I forget to add `main` (which calls `Html.program`) function to MyApp 
module.

On Wednesday, June 29, 2016 at 12:29:24 PM UTC+3, Stuart Axon wrote:
>
> I've been getting started with elm using the environment described here  
> https://boonofcode.svbtle.com/setting-up-an-atom-elm-dev-environment   I 
> have an index.html as below, but am getting -
>
> TypeError: Elm.fullscreen is not a function
>
> Any idea what I need to change ?
>
>
> 
>> 
>> 
>> 
>> My App
>> 
>> 
>> 
>> 
>> 
>> Elm.fullscreen(Elm.Main);
>> 
>> 
>> 
>>
>
>
>

-- 
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] Leaking event handlers with Elm SPA

[Deedostar]

Hi everyone,

I have recently thought about how there is a chance in Elm to leak event 
handlers if they are not cleaned up properly. A basic scenario where this 
can happen is this:

Assume an SPA made of React with some embedded Elm parts which uses 
subscriptions.
Now navigate to a page, which has an elm part, it will set the 
subscription. Now navigate away, the subscription will stay. Now navigate 
back to it and the component will create a new Elm app with yet another 
subscription. Repeat these steps and end up with very many leaked event 
handlers.

I created an example here: https://ellie-app.com/3LHDqnYqD4za1/10
(I am simulating navigating away and back with ReactDOM.render and 
unmountComponentAtNode)

As Elm becomes more and more popular and is increasingly used in SPAs this 
can become a problem with performance over a long page lifetime and also 
lead to hard-to-debug-behavior, so I think it would be really important to 
have some way to "clean up" after Elm with something like `app.kill()`.
Worth noting that the leaky behavior is not that problematic for non-SPAs 
because a page reload will always clean up everything.

Does anybody have any thoughts to share about this topic. Having similar 
issues or just realized that there might be some when reading this? Would 
love to collect some thoughts.

PS: I know one could work around this issue my using ports and shutting 
down the subscriptions manually, but I believe that there should a way to 
shut the app down from the outside and also that workaround does not work 
for the Navigation.program.

-- 
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] Leaking event handlers with Elm SPA

[Deedostar]

Hi everyone,

I have recently thought about how there is a chance in Elm to leak event 
handlers if they are not cleaned up properly. A basic scenario where this 
can happen is this:

Assume an SPA made of React with some embedded Elm parts which uses 
subscriptions.
Now navigate to a page, which has an elm part, it will set the 
subscription. Now navigate away, the subscription will stay. Now navigate 
back to it and the component will create a new Elm app with yet another 
subscription. Repeat these steps and end up with very many leaked event 
handlers.

I created an example here: https://ellie-app.com/3LHDqnYqD4za1/10 
(I am simulating navigating away and back with ReactDOM.render and 
umountComponentAtNode)

As Elm becomes more and more popular and is increasingly used in SPAs this 
can become a problem with performance over a long page lifetime and also 
lead to hard-to-debug-behavior, so I think it would be really important to 
have some way to "clean up" after Elm with something like `app.kill()`.
Worth noting that the leaky behavior is not that problematic for non-SPAs 
because a page reload will always clean up everything.

Does anybody have any thoughts to share about this topic. Having similar 
issues or just realized that there might be some when reading this? Would 
love to collect some thoughts.

PS: I know one could work around this issue by using ports and shutting 
down the subscriptions manually, but I believe that there should a way to 
shut the app down from the outside and also that workaround does not work 
for the Navigation.program.

-- 
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: Why is the signature of 'program.subs' 'model -> Sub msg' ?

[Vasily Vasilkov]

Does it mean that Elm runtime creates and cancels subscriptions 
on the fly (for  every model change)?






On Mon, Jul 17, 2017 at 6:19 PM +0400, "Marek Fajkus"  
wrote:










Sometimes you don't need subscriptions if you're in some state. For instance, 
if you have game and subscription to say mouse position you can subscribe to 
Mouse.position only when a user is in play state and avoid subscription in game 
menu.





-- 

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] main : Program Never Model Msg -- What does it mean?

[Peter Damoc]

The main is a *value* of type `Program Never Model Msg`, it is not a
function.

The 3 types after Program, (Never, Model and Msg) are the arguments of the
type in the same way that String is an argument for List in `List String`

You can read that as "a Program that does not take any flags (Never) has
the type `Model` as it's main data type and `Msg` as the main type of
messages flowing through the app", that's the actual, full type.

You can also thing of the `Program` as a container type for the 3 types
that follow it, the same way List is a container type or Maybe is a
container type.



On Fri, Jul 21, 2017 at 8:39 AM, Eeek  wrote:

> I am beginner in Elm, and going through elm-tutorial.org. I have problem
> in understanding the declaration of main function in
> https://www.elm-tutorial.org/en/02-elm-arch/02-structure.html. It says
>
> main : Program Never Model Msg
>
>  What does it represent? I read under functions tutorial that, arguments
> are separated with ->. If there are no arguments then I would expect only
> one return. This don't belong to any of it. What is this way of declaring
> the function types?
>
> --
> 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.