Re: [elm-discuss] Re: Design of Large Elm apps

[Mark Hamburg]

More specifically:

(:>) (model, Batchable op)
-> (model -> (model, Batchable op))
-> (model, Batchable op)
(:>) (oldModel, oldOps) update =
let
(newModel, newOps) = update oldModel
in
(newModel, Batchable.batch [oldOps, newOps])


On Sun, Aug 28, 2016 at 9:55 PM, Mark Hamburg  wrote:

> I have started thinking about whether there would be a useful refactoring
> of Cmd and Sub to support some shared structure that could also work with
> the sort of emulations that I've been building. It's not that the
> emulations are hard — writing batch, map, and none just aren't that much
> code — but rather that I'd like to write a standard operator to do the
> following:
>
> (:>) (model, Batchable ops)
> -> (model -> (model, Batchable ops))
> -> (model, Batchable ops)
>
>
> Where Batchable would cover Cmd and my Cmd emulations. This then allows
> update sequences to look like:
>
> (model, Batchable.none)
> :> firstUpdate
> :> secondUpdate
>
>
> This would make the generalization of the Elm architecture that keeps the
> "command pattern" but doesn't use the "Cmd type" fit in perfectly well
> with the simpler Cmd patterns.
>
> Mark
>
>
> On Sun, Aug 28, 2016 at 9:33 PM, Mark Hamburg 
> wrote:
>
>> Why does Elm work in terms of commands rather than tasks? That's somewhat
>> rhetorical, but in the case of effect managers it allows an effect manager
>> to do things like maintain additional state, batch together operations, etc.
>>
>> In the case of this system, this allows for the API service provider to
>> again do caching and batching, to manage login status, etc.. It also allows
>> for more general translation of the way the UI interacts with the backend
>> service. For example, the cloud service might just communicate via a web
>> socket connection spewing out notifications across all of the forums for
>> which the user was a member. This isn't going to map directly to the
>> activity that the UI is currently interested in displaying.
>>
>> The "problem" with commands and subscriptions is that the mapping really
>> only applies to the tagging that happens on the way back down from the
>> cloud (or wherever) and can't alter the commands and subscriptions on the
>> way up to address any mismatch between the needs of the UI and the
>> facilities provided by the backend service.
>>
>> Mark
>>
>> On Sun, Aug 28, 2016 at 7:52 PM, Erik Lott  wrote:
>>
>>> Mark, tell me about this code:
>>>
>>> type APICommand msg
>>> = AddForum (Error -> msg) (ForumID -> msg) String
>>> | DeleteForum (Error -> msg) (() -> msg) ForumID
>>> | PostMessage (Error -> msg) (() -> msg) ForumID String
>>>
>>>
>>> type APISubscription msg
>>> = ForumList (List (ForumID, String) -> msg)
>>> | MessageList (Array.Array String -> msg) ForumID
>>>
>>>
>>> Conceptually, I appreciate what you're trying to do here (create a
>>> simple system driven by domain messages - AddForum, DeleteForum, etc) , but
>>> the actual implementation worries me. I'm wondering why you're not simply
>>> creating an API module instead:
>>>
>>> module API exposing(addForum, deleteForum, postMessage)
>>>
>>> addForum: String -> Task Http.Error Forum
>>> // code here...
>>>
>>> deleteForum: String -> Task Http.Error Never
>>> // code here
>>>
>>> etc
>>>
>>>
>>> I know that you mentioned that you have some additional complexity (task
>>> queue, websockets,etc), but I haven't actually seen anything that would
>>> cause me to abandon the built-in command/subscriptions system. What if you
>>> need to do something in the page that is not necessarily domain related,
>>> but requires a task/command - e.g. generate a random number? Are these
>>> types of situations factored into your design?
>>>
>>>
>>>
>>>
>>> On Saturday, August 27, 2016 at 6:14:41 PM UTC-4, Mark Hamburg wrote:
>>>
 I'm working on some example code. I'm varying between a moderately
 fleshed out example of the plumbing but with little backing it up and a
 fully worked but trivial to the point of not being interesting example. The
 general model, however, works as follows:

 • We have a service model and a client model. The idea is that after
 agreeing on an API, these can then undergo independent development.
 Furthermore, we should be able to do things like mock the service rapidly
 and then fill it in with a version that talks to the web service or
 whatever is needed. Similarly, we could mock the client side quickly if we
 just wanted to test the service APIs.

 • The API is represented by a union type: APICommand clientMsg. A
 typical entry would be something like:

 | PostMessage (Error -> clientMsg) (() -> clientMsg) ForumId String



 • APICommand clientMsg is wrapped up inside a ClientCommand clientMsg type
 that provides standard Cmd-style functionality (batch, map). It also
 provides a way to embed non-API 

Re: [elm-discuss] Partially applied record updates?

[Joey Eremondi]

>
> treating the fields in a record like this tends to encourage imperative
> thinking


On the contrary, turning this into a function, that can be passed around,
composed, and such, is in some sense, the essence of functional thinking.

This could have great advantages for accessing deep within nested
structures, dealing with Maybes in nested records, etc. It's just a
function, which you can use "map" or << or any other wonderful functional
tools that make Elm useful.

It's also worth mentioning also that functions like this are well studied
in Haskell, and give way to things like Lenses. So having these isn't
frowned upon in the functional community in general.

On Sun, Aug 28, 2016 at 9:46 PM, Mark Hamburg  wrote:

> The Elm equivalent if it existed would probably be:
>
> .name= : String -> Person -> Person
>
>
> I have certainly written plenty of code where I would have appreciated
> this but I do also worry that treating the fields in a record like this
> tends to encourage imperative thinking and discourage thinking about the
> validity of the record as a whole.
>
> Mark
>
> On Sun, Aug 28, 2016 at 4:32 PM, John Mayer  wrote:
>
>> For the purpose of comparison, this reminds me of a feature of case
>> classes in Scala. Case classes are somewhat similar to records in that they
>> can be succinctly defined as just some named fields. By default, they have
>> a copy method which each field can be provided optionally and override the
>> value of the input.
>>
>> One cool idea would be to have a sort of copy keyword which takes two
>> records where one is a field-unifiable-subset of the other. However this
>> probably can't be defined generally in plain Elm because the type system
>> doesn't support this notion of subsets.
>>
>> Maybe you could write a preprocessor which expanded the keyword into a
>> lambda by inspecting the input and update records. This approach could even
>> delegate the type checking to the type checker and just rely on the syntax
>> tree.
>>
>> You could write a code generator which created methods which act like
>> copy, one for each field, or one big one where each field was a Maybe type.
>>
>> On Aug 28, 2016 6:50 PM, "Joey Eremondi"  wrote:
>>
>>> There have been requests for this before. I personally think they'd be
>>> great, but there's not a current way to do it other than lambda.
>>> On Aug 28, 2016 2:42 PM, "Esad Hajdarevic"  wrote:
>>>
 Hi,

 with the current Elm syntax, is there a way to partially apply a record
 update? Something like

 type alias Person = { name: String, age: Int }

 p = { name: "Joe", age: 32 }

 p.name= :: String -> Person

 or

 { p | name = } :: String -> Person

 or even

 { p | name =, age = 30} :: String ->  Person

 I'm asking because I'd like to update a record in a pipeline. Wrapping
 in a lambda \x -> { p | name = x } works, but I was wondering if there
 could be a more compact way of doing this.




 --
 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.
>>
>
> --
> 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] Partially applied record updates?

[Mark Hamburg]

The Elm equivalent if it existed would probably be:

.name= : String -> Person -> Person


I have certainly written plenty of code where I would have appreciated this
but I do also worry that treating the fields in a record like this tends to
encourage imperative thinking and discourage thinking about the validity of
the record as a whole.

Mark

On Sun, Aug 28, 2016 at 4:32 PM, John Mayer  wrote:

> For the purpose of comparison, this reminds me of a feature of case
> classes in Scala. Case classes are somewhat similar to records in that they
> can be succinctly defined as just some named fields. By default, they have
> a copy method which each field can be provided optionally and override the
> value of the input.
>
> One cool idea would be to have a sort of copy keyword which takes two
> records where one is a field-unifiable-subset of the other. However this
> probably can't be defined generally in plain Elm because the type system
> doesn't support this notion of subsets.
>
> Maybe you could write a preprocessor which expanded the keyword into a
> lambda by inspecting the input and update records. This approach could even
> delegate the type checking to the type checker and just rely on the syntax
> tree.
>
> You could write a code generator which created methods which act like
> copy, one for each field, or one big one where each field was a Maybe type.
>
> On Aug 28, 2016 6:50 PM, "Joey Eremondi"  wrote:
>
>> There have been requests for this before. I personally think they'd be
>> great, but there's not a current way to do it other than lambda.
>> On Aug 28, 2016 2:42 PM, "Esad Hajdarevic"  wrote:
>>
>>> Hi,
>>>
>>> with the current Elm syntax, is there a way to partially apply a record
>>> update? Something like
>>>
>>> type alias Person = { name: String, age: Int }
>>>
>>> p = { name: "Joe", age: 32 }
>>>
>>> p.name= :: String -> Person
>>>
>>> or
>>>
>>> { p | name = } :: String -> Person
>>>
>>> or even
>>>
>>> { p | name =, age = 30} :: String ->  Person
>>>
>>> I'm asking because I'd like to update a record in a pipeline. Wrapping
>>> in a lambda \x -> { p | name = x } works, but I was wondering if there
>>> could be a more compact way of doing this.
>>>
>>>
>>>
>>>
>>> --
>>> 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.
>

-- 
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: Design of Large Elm apps

[Mark Hamburg]

Why does Elm work in terms of commands rather than tasks? That's somewhat
rhetorical, but in the case of effect managers it allows an effect manager
to do things like maintain additional state, batch together operations, etc.

In the case of this system, this allows for the API service provider to
again do caching and batching, to manage login status, etc.. It also allows
for more general translation of the way the UI interacts with the backend
service. For example, the cloud service might just communicate via a web
socket connection spewing out notifications across all of the forums for
which the user was a member. This isn't going to map directly to the
activity that the UI is currently interested in displaying.

The "problem" with commands and subscriptions is that the mapping really
only applies to the tagging that happens on the way back down from the
cloud (or wherever) and can't alter the commands and subscriptions on the
way up to address any mismatch between the needs of the UI and the
facilities provided by the backend service.

Mark

On Sun, Aug 28, 2016 at 7:52 PM, Erik Lott  wrote:

> Mark, tell me about this code:
>
> type APICommand msg
> = AddForum (Error -> msg) (ForumID -> msg) String
> | DeleteForum (Error -> msg) (() -> msg) ForumID
> | PostMessage (Error -> msg) (() -> msg) ForumID String
>
>
> type APISubscription msg
> = ForumList (List (ForumID, String) -> msg)
> | MessageList (Array.Array String -> msg) ForumID
>
>
> Conceptually, I appreciate what you're trying to do here (create a simple
> system driven by domain messages - AddForum, DeleteForum, etc) , but the
> actual implementation worries me. I'm wondering why you're not simply
> creating an API module instead:
>
> module API exposing(addForum, deleteForum, postMessage)
>
> addForum: String -> Task Http.Error Forum
> // code here...
>
> deleteForum: String -> Task Http.Error Never
> // code here
>
> etc
>
>
> I know that you mentioned that you have some additional complexity (task
> queue, websockets,etc), but I haven't actually seen anything that would
> cause me to abandon the built-in command/subscriptions system. What if you
> need to do something in the page that is not necessarily domain related,
> but requires a task/command - e.g. generate a random number? Are these
> types of situations factored into your design?
>
>
>
>
> On Saturday, August 27, 2016 at 6:14:41 PM UTC-4, Mark Hamburg wrote:
>
>> I'm working on some example code. I'm varying between a moderately
>> fleshed out example of the plumbing but with little backing it up and a
>> fully worked but trivial to the point of not being interesting example. The
>> general model, however, works as follows:
>>
>> • We have a service model and a client model. The idea is that after
>> agreeing on an API, these can then undergo independent development.
>> Furthermore, we should be able to do things like mock the service rapidly
>> and then fill it in with a version that talks to the web service or
>> whatever is needed. Similarly, we could mock the client side quickly if we
>> just wanted to test the service APIs.
>>
>> • The API is represented by a union type: APICommand clientMsg. A
>> typical entry would be something like:
>>
>> | PostMessage (Error -> clientMsg) (() -> clientMsg) ForumId String
>>
>>
>>
>> • APICommand clientMsg is wrapped up inside a ClientCommand clientMsg type
>> that provides standard Cmd-style functionality (batch, map). It also
>> provides a way to embed non-API commands of type Cmd clientMsg. I would
>> have liked to just use a different type of message within Cmd to do this
>> rather than reconstructing map and batch — trivial though they may be —
>> but mapping for platform commands is built around tagging results as they
>> come back and we need to adjust the tagging functions on API commands
>> before they get to the service.
>>
>> • The update function for the client has the signature:
>>
>> clientMsg -> clientModel -> (clientModel, ClientCommand clientMsg)
>>
>> This gets applied at the "root" level when processing messages destined
>> for the client. On the way back, it can turn the client commands into
>> platform commands of type Cmd (RootMsg serviceMsg clientMsg) where the
>> RootMsg type provides for messages bound for the client, messages bound
>> for the service, and API commands bound for the service.
>>
>> • The service processes both its own messages and API commands (in
>> separate update functions in my latest code). Service updates return 
>> (serviceModel,
>> ServiceCommand serviceMsg clientMsg) where ServiceCommand again mirrors
>> Cmd in terms of providing batch and map support. (This could actually be
>> represented as a Cmd (Either serviceMsg clientMsg) but I'm not sure that
>> leveraging Cmd in that case provides more clarity.)
>>
>> • The root update function again maps the service commands appropriately
>> to generate commands of type Cmd (RootMsg serviceMsg clientMsg) 

[elm-discuss] Re: Do the counters in the Guide teach us a wrong scaling approach?

[Erik Lott]

>
> It's like I keep falling whenever I try to ride this new elm-bike. 
> And I keep hearing from others that they just get up and go and don't fall,
> so I should also just go and don't fall, or be very specific at which 
> point in my process I fall off my bike.
> (Sorry if the analogy is somewhat far fetched).


That's an honest reply. I certainly did not have this effortless learning 
experience. I've been programming applications for a long time, and Elm 
made me feel like a noob again. Very very humbling. 

Back in the days, when I learned react, I found this page 
> 
>  very 
> helpful. It explains how to structure in react. What state is, and where to 
> put it.
> Maybe a similar "thinking in elm" page will 
> a) help folks like me learn how to structure their apps in elm and 
> b) reduce unwanted/ vague questions about components on this forum.


+10 agree. I think at this point, its becoming obvious that there needs to 
be a more thorough "on-ramp" post(s) to ease folks' minds' into "thinking 
in elm". Without that, it's like the wild west - everyone is trying to 
figure out how to structure an app, and the only thing they can reach for 
is previous mental models - React folks try to apply react ideas to elm; 
Angular people try to apply angular ideas to elm, etc.. 

On Sunday, August 28, 2016 at 5:43:11 PM UTC-4, Wouter In t Velt wrote:
>
> Thanks for the feedback folks. Really helpful and got me thinking. Will 
> definitely dive into the links @NickH shared.
> And @ErikLott's example of a multi-page SPA (forgive the oxymoron) was 
> also helpful. This is one of the places I run into issues: my top level 
> update is already huge and growing.
>
> Also, I take the advice to heart to share/ ask questions on concrete and 
> practical cases.
>
> That said, for me, scaling Elm remains a struggle, and I find it hard to 
> pinpoint specific use cases to share here as a question.
>
> I really believe it when more experienced people say that elm scales, I am 
> just struggling with the "how".
>
> It's like I keep falling whenever I try to ride this new elm-bike. 
> And I keep hearing from others that they just get up and go and don't fall,
> so I should also just go and don't fall, or be very specific at which 
> point in my process I fall off my bike.
> (Sorry if the analogy is somewhat far fetched).
>
> This was different when I learned react some years ago.
> And I was just wondering why it was such a different experience.
>
> And it occurred to me that some of the "why does everyone insist on asking 
> about components"-meme may have been triggered because the counter example 
> is a very prominent (if not the most prominent) example in the Guide.
>
> I agree with Nick H that adding more examples is probably more helpful 
> than rewriting existing ones. 
>
> Back in the days, when I learned react, I found this page 
>  very 
> helpful. It explains how to structure in react. What state is, and where to 
> put it.
> Maybe a similar "thinking in elm" page will 
> a) help folks like me learn how to structure their apps in elm and 
> b) reduce unwanted/ vague questions about components on this forum.
>

-- 
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: Design of Large Elm apps

[Erik Lott]

Mark, tell me about this code:

type APICommand msg
= AddForum (Error -> msg) (ForumID -> msg) String
| DeleteForum (Error -> msg) (() -> msg) ForumID
| PostMessage (Error -> msg) (() -> msg) ForumID String


type APISubscription msg
= ForumList (List (ForumID, String) -> msg)
| MessageList (Array.Array String -> msg) ForumID


Conceptually, I appreciate what you're trying to do here (create a simple 
system driven by domain messages - AddForum, DeleteForum, etc) , but the 
actual implementation worries me. I'm wondering why you're not simply 
creating an API module instead:

module API exposing(addForum, deleteForum, postMessage)

addForum: String -> Task Http.Error Forum
// code here...

deleteForum: String -> Task Http.Error Never
// code here

etc
 

I know that you mentioned that you have some additional complexity (task 
queue, websockets,etc), but I haven't actually seen anything that would 
cause me to abandon the built-in command/subscriptions system. What if you 
need to do something in the page that is not necessarily domain related, 
but requires a task/command - e.g. generate a random number? Are these 
types of situations factored into your design?




On Saturday, August 27, 2016 at 6:14:41 PM UTC-4, Mark Hamburg wrote:
>
> I'm working on some example code. I'm varying between a moderately fleshed 
> out example of the plumbing but with little backing it up and a fully 
> worked but trivial to the point of not being interesting example. The 
> general model, however, works as follows:
>
> • We have a service model and a client model. The idea is that after 
> agreeing on an API, these can then undergo independent development. 
> Furthermore, we should be able to do things like mock the service rapidly 
> and then fill it in with a version that talks to the web service or 
> whatever is needed. Similarly, we could mock the client side quickly if we 
> just wanted to test the service APIs.
>
> • The API is represented by a union type: APICommand clientMsg. A typical 
> entry would be something like:
>
> | PostMessage (Error -> clientMsg) (() -> clientMsg) ForumId String
>
>
>
> • APICommand clientMsg is wrapped up inside a ClientCommand clientMsg type 
> that provides standard Cmd-style functionality (batch, map). It also 
> provides a way to embed non-API commands of type Cmd clientMsg. I would 
> have liked to just use a different type of message within Cmd to do this 
> rather than reconstructing map and batch — trivial though they may be — 
> but mapping for platform commands is built around tagging results as they 
> come back and we need to adjust the tagging functions on API commands 
> before they get to the service.
>
> • The update function for the client has the signature:
>
> clientMsg -> clientModel -> (clientModel, ClientCommand clientMsg) 
>
> This gets applied at the "root" level when processing messages destined 
> for the client. On the way back, it can turn the client commands into 
> platform commands of type Cmd (RootMsg serviceMsg clientMsg) where the 
> RootMsg type provides for messages bound for the client, messages bound 
> for the service, and API commands bound for the service.
>
> • The service processes both its own messages and API commands (in 
> separate update functions in my latest code). Service updates return 
> (serviceModel, 
> ServiceCommand serviceMsg clientMsg) where ServiceCommand again mirrors 
> Cmd in terms of providing batch and map support. (This could actually be 
> represented as a Cmd (Either serviceMsg clientMsg) but I'm not sure that 
> leveraging Cmd in that case provides more clarity.)
>
> • The root update function again maps the service commands appropriately 
> to generate commands of type Cmd (RootMsg serviceMsg clientMsg) which 
> route to the service and client as appropriate.
>
> The amount of code is actually pretty small and as discussed above, it 
> provides a very nice separation of concerns between the client side and the 
> server side and allows each to be coded following standard Elm architecture 
> patterns with the caveat that one doesn't actually use Cmd during 
> propagation.
>
> So, with that, I would be happy were it not for the fact that it's dawned 
> on me that subscriptions are going to be more difficult because I can't 
> simply wait for the runtime to ask the root model for subscriptions and 
> then plumb it appropriately. This is because the service model will almost 
> certainly need to adjust its state based on the client subscription 
> requests — see some effects managers for examples — and when asked for 
> subscriptions we can't update the root model. So, I will need to perform an 
> internal subscription update after every client model update. This isn't 
> fatal but I could imagine it being inefficient. I could also send a strobe 
> to do this but that might introduce more delay than I'd like. That said, 
> I've wondered whether subscriptions need lazy support akin to what we have 
> 

Re: [elm-discuss] Partially applied record updates?

[John Mayer]

For the purpose of comparison, this reminds me of a feature of case classes
in Scala. Case classes are somewhat similar to records in that they can be
succinctly defined as just some named fields. By default, they have a copy
method which each field can be provided optionally and override the value
of the input.

One cool idea would be to have a sort of copy keyword which takes two
records where one is a field-unifiable-subset of the other. However this
probably can't be defined generally in plain Elm because the type system
doesn't support this notion of subsets.

Maybe you could write a preprocessor which expanded the keyword into a
lambda by inspecting the input and update records. This approach could even
delegate the type checking to the type checker and just rely on the syntax
tree.

You could write a code generator which created methods which act like copy,
one for each field, or one big one where each field was a Maybe type.

On Aug 28, 2016 6:50 PM, "Joey Eremondi"  wrote:

> There have been requests for this before. I personally think they'd be
> great, but there's not a current way to do it other than lambda.
> On Aug 28, 2016 2:42 PM, "Esad Hajdarevic"  wrote:
>
>> Hi,
>>
>> with the current Elm syntax, is there a way to partially apply a record
>> update? Something like
>>
>> type alias Person = { name: String, age: Int }
>>
>> p = { name: "Joe", age: 32 }
>>
>> p.name= :: String -> Person
>>
>> or
>>
>> { p | name = } :: String -> Person
>>
>> or even
>>
>> { p | name =, age = 30} :: String ->  Person
>>
>> I'm asking because I'd like to update a record in a pipeline. Wrapping in
>> a lambda \x -> { p | name = x } works, but I was wondering if there could
>> be a more compact way of doing this.
>>
>>
>>
>>
>> --
>> 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] Partially applied record updates?

[Joey Eremondi]

There have been requests for this before. I personally think they'd be
great, but there's not a current way to do it other than lambda.
On Aug 28, 2016 2:42 PM, "Esad Hajdarevic"  wrote:

> Hi,
>
> with the current Elm syntax, is there a way to partially apply a record
> update? Something like
>
> type alias Person = { name: String, age: Int }
>
> p = { name: "Joe", age: 32 }
>
> p.name= :: String -> Person
>
> or
>
> { p | name = } :: String -> Person
>
> or even
>
> { p | name =, age = 30} :: String ->  Person
>
> I'm asking because I'd like to update a record in a pipeline. Wrapping in
> a lambda \x -> { p | name = x } works, but I was wondering if there could
> be a more compact way of doing this.
>
>
>
>
> --
> 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: Do the counters in the Guide teach us a wrong scaling approach?

[Mark Hamburg]

One thing that might help in a Thinking in Elm context would be to put more 
emphasis on hierarchical model construction and hierarchical view construction 
as separate ideas. The latter is mostly about breaking things down via 
functions. The former is about defining data types and functions on those types 
and then combining those types to form larger types.

I don't know how well this would work if then followed with a building an Elm 
Architecture app where we then need to wire the pieces together with messages 
and an update function, but it might make the stay flat approach easier to 
sustain if it were focused on messages and the update function.

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] Re: Do the counters in the Guide teach us a wrong scaling approach?

[Wouter In t Velt]

Thanks for the feedback folks. Really helpful and got me thinking. Will 
definitely dive into the links @NickH shared.
And @ErikLott's example of a multi-page SPA (forgive the oxymoron) was also 
helpful. This is one of the places I run into issues: my top level update 
is already huge and growing.

Also, I take the advice to heart to share/ ask questions on concrete and 
practical cases.

That said, for me, scaling Elm remains a struggle, and I find it hard to 
pinpoint specific use cases to share here as a question.

I really believe it when more experienced people say that elm scales, I am 
just struggling with the "how".

It's like I keep falling whenever I try to ride this new elm-bike. 
And I keep hearing from others that they just get up and go and don't fall,
so I should also just go and don't fall, or be very specific at which point 
in my process I fall off my bike.
(Sorry if the analogy is somewhat far fetched).

This was different when I learned react some years ago.
And I was just wondering why it was such a different experience.

And it occurred to me that some of the "why does everyone insist on asking 
about components"-meme may have been triggered because the counter example 
is a very prominent (if not the most prominent) example in the Guide.

I agree with Nick H that adding more examples is probably more helpful than 
rewriting existing ones. 

Back in the days, when I learned react, I found this page 
 very 
helpful. It explains how to structure in react. What state is, and where to 
put it.
Maybe a similar "thinking in elm" page will 
a) help folks like me learn how to structure their apps in elm and 
b) reduce unwanted/ vague questions about components on this forum.

-- 
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] Partially applied record updates?

[Esad Hajdarevic]

Hi,

with the current Elm syntax, is there a way to partially apply a record 
update? Something like

type alias Person = { name: String, age: Int }

p = { name: "Joe", age: 32 }

p.name= :: String -> Person

or

{ p | name = } :: String -> Person

or even

{ p | name =, age = 30} :: String ->  Person

I'm asking because I'd like to update a record in a pipeline. Wrapping in a 
lambda \x -> { p | name = x } works, but I was wondering if there could be 
a more compact way of doing this.




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

[John Bugner]

I have these for git too, but what kinds of ones do you have for git? Just 
spelling shortenings, like 's' for 'status', or also semantic shortenings, 
like 'unstage' for 'reset HEAD --'?

On Friday, August 26, 2016 at 12:51:20 PM UTC-5, Max Goldstein wrote:
>
> Oh man, I've got like 20 of these for git. It never thought to do them for 
> Elm!
>
> I'd add a --yes to elm-package (and elm-make?). 
>
>

-- 
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: Do the counters in the Guide teach us a wrong scaling approach?

[Erik Lott]

Folks, Elm scales just fine. We're at the tail-end of a large SPA front-end 
build in Elm... lots of complexity, and it's been wonderful.

The counter examples, sortable table, and autocomplete are fine examples of 
how to modularize elm code. They don't lead you down the wrong path, nor do 
they disagree with Richards advice to start simple (model/update/view). If 
you find this confusing, it just means you need to lay down a little more 
code first, and really internalize the simplicity of Elm... ultimately, 
regardless of how many modules you have, it's just functions all the way 
down, and a *single* state tree.

You won't build a large multipage app in a single module, nor does Richard 
ever promote that idea. You DO need to create modules to separate your app 
into pieces of functionality, and I'm not talking about Model, Update 
andView module (although you might decide to do this). The Counter module 
is a good example of a concept that has been pulled into a module - the 
fact that it is nested or not doesn't matter - it's just a module with an 
API, nothing more.

Here is a very basic primer showing how you might structure an imaginary 
SPA app:

Top Level

Page 1
Page 2 
Page 3
Page 4


Top Level
- Model hold the business/domain data tree for the entire app, the 
'currentPage', and the 'currentUser' (if you have to deal with auth).
- View uses the "currentPage" state to decide which page to display. 
- View passes slices of domain/business data to the Page.view function 
(Page models do not hold business/domain data)

Page Level
- Model hold page related state (this page section is open, this page 
section is closed, this form is submitting, etc).
- Page may provide an api, so that specific events that occur inside the 
page can be responded by outside code (The top level might take some action 
when the form on a Page has been submitted).

In all honesty, our app is not exactly arranged like this, but this 
imaginary example should be enough for people to ask questions about. How 
do I build this? How do I build that? Specific questions like this are so 
much easier to answer than "Does elm scale".


 


On Sunday, August 28, 2016 at 7:02:04 AM UTC-4, Wouter In t Velt wrote:
>
> Something I have been struggling with for quite some time (coming from 
> React and Flux) is how to scale. There are various posts on this forum 
> related to the topic, e.g. Design of large elm apps 
> , parent 
> child communication 
> ,
>  
> components 
> 
> .
>
> On structuring apps, I found the elm-sortable-table and the autocomplete 
> video - shared by Peter Damoc in this thread 
>  - 
> to be very helpful, as well as advice here 
> .
>
> My summary of the advice is more or less:
>
>- Forget about about "components": the term is very confusing, means 
>very different things in different contexts.
>- Start to build with 1 Model, 1 Msg, 1 update, 1 view
>- As soon as one these becomes too big, seperate that one out to a 
>view-helper, or update-helper etc
>
> This very much feels like a "top-down"  approach: the module you start 
> with remains on top. Put everything in there, and split out if needed.
> I keep reminding myself to stop trying to keep pieces of each of the 4 
> building blocks (Model, Msg, update, view) bundled as I separate out. That 
> it is fine to e.g. just put a piece of view code in a separate place - 
> *without 
> trying to bundle it with corresponding pieces of Model, Msg, and update.*
>
> Now I am not sure that my take on "how to do stuff"  is the right way, but 
> it does seem that the *multiple-counters example in the guide teach us 
> exactly the opposite pattern*. 
> *Do the multiple counter examples in the guide put us on the wrong foot?*
>
> We start out with one counter being the top module, and then we add a 
> wrapper *on top* to handle multiple instances of this counter.
> To make matters worse: the multiple counter examples introduces the kind 
> of opaque nesting and messaging structure that is being discouraged here:
> The parent does not know anything about each child counter, parent has its 
> own Msg structure etc.
> After scaling, the counter now has in effect become something that looks 
> and smells very much like a component.
>
> Just the other day I realized that much of my struggle with scaling came 
> from stuff I picked up on day 1 of learning Elm, with sinful thoughts such 
> as:
> "Hey, this counter thing in Elm is just like a reusable UI element. Just 
> like a react component, with state and all. 

Re: [elm-discuss] Re: Design of Large Elm apps

[Richard Feldman]

Here's a primer on Elm modules:
https://dennisreimann.de/articles/elm-modules-import.html

Indeed, "component" and "child" are not first-class constructs in Elm, and
so can mean different things to different people. Sorry for the confusion!

I'm going to make a point to start discussing things using terms that have
first-class language support, and see how that goes. :)

On Sun, Aug 28, 2016, 11:58 AM Nick H  wrote:

> Well, "module" is a keyword in Elm, so I really hope everybody who knows
> Elm knows exactly what this is!
>
> On Sun, Aug 28, 2016 at 11:23 AM, Rex van der Spuy 
> wrote:
>
>>
>>
>> On Sunday, August 28, 2016 at 4:14:43 AM UTC-4, Richard Feldman wrote:
>>>
>>>
 I gather that this is has to do with an interaction between two update
>>> functions...is there some way to rephrase it in terms of how those two
>>> update functions interact?
>>>
>>
>> Richard, this has been a huge area of confusion for me in the
>> child-parent discussions that I've been following over the past few months!
>> What's a "module", what's a "child", what's a "component"? Everyone seems
>> to have different mental models for what these things are include me :)
>> ... resulting in some muddy and inconclusive discussions.
>>
>> ... just a observation from someone in the Peanut Gallery.
>> Carry on! This is a fun thread :)
>>
> --
>>
> 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 a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/elm-discuss/_cfOu88oCx4/unsubscribe.
> To unsubscribe from this group and all its topics, 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: Design of Large Elm apps

[Nick H]

Well, "module" is a keyword in Elm, so I really hope everybody who knows
Elm knows exactly what this is!

On Sun, Aug 28, 2016 at 11:23 AM, Rex van der Spuy 
wrote:

>
>
> On Sunday, August 28, 2016 at 4:14:43 AM UTC-4, Richard Feldman wrote:
>>
>>
>>> I gather that this is has to do with an interaction between two update
>> functions...is there some way to rephrase it in terms of how those two
>> update functions interact?
>>
>
> Richard, this has been a huge area of confusion for me in the child-parent
> discussions that I've been following over the past few months! What's a
> "module", what's a "child", what's a "component"? Everyone seems to have
> different mental models for what these things are include me :) ...
> resulting in some muddy and inconclusive discussions.
>
> ... just a observation from someone in the Peanut Gallery.
> Carry on! This is a fun thread :)
>
> --
> 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: Do the counters in the Guide teach us a wrong scaling approach?

[Eric G]

On Sunday, August 28, 2016 at 7:02:04 AM UTC-4, Wouter In t Velt wrote:
>
>
>- Forget about about "components": the term is very confusing, means 
>very different things in different contexts.
>- Start to build with 1 Model, 1 Msg, 1 update, 1 view
>- As soon as one these becomes too big, seperate that one out to a 
>view-helper, or update-helper etc
>
> This very much feels like a "top-down"  approach: the module you start 
> with remains on top. Put everything in there, and split out if needed.
>
>  
On the question about starting from one module and how to split it out, 
etc., I entirely agree with Richard's practical advice on this. But I am 
curious about people's Elm habits on a more micro level. When you say you 
feel it's "top down" to start with one module at the top, it got me 
thinking about this. 

Until recently, I found I had a tendency to want to build from the top, and 
got stuck on things like "I can't start until I figure out client-side 
routing [sic]". And when working on any particular piece of the app, I 
wanted to completely implement it down through all the descendants. And I 
did it in a particular order: Model and update, make sure that compiles, 
and then view, and then updates involving side effects, and associated view 
changes. I started to notice this approach was causing extra work. By the 
time I got to the view, inevitably I would have forgotten a particular 
update, or needed some state I hadn't accounted for, or realized it was 
better to split the state between modules differently, etc. And that would 
set off another round of changes, all before I even had something to play 
around with in the browser. It was taking way too long to get visual 
feedback. 

It seems obvious in retrospect, but I have switched to a "bottom-up" style 
that prioritizes getting visual feedback: (1) build only the piece of my 
app I need feedback on; (2) don't implement every view and action from the 
start, leave placeholders, especially for pieces of the UI that may be 
variants of each other; (3) start from the view and work up to the model 
and update based on what you need at that particular stage; (4) hard code 
external data and bring it in through `Task.succeed`, `Task.fromMaybe "not 
found" Dict.get` and similar; (5) style it initially in the browser.

I usually have a very basic Main that inits the piece of the app I'm 
working on, and I serve that up fullscreen on a "demo page", to fiddle with 
and eventually to show stakeholders. So far it's working well for me, as 
long as I stay focused on getting something up ASAP, however incomplete.

Curious what other people's practices are like.

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

[Matthew Griffith]

Thanks!

Good catch.  It should be updated now :)  (it was only looking at the 
github summary but not the elm-package description)

On Sunday, August 28, 2016 at 1:32:35 PM UTC-4, Max Goldstein wrote:
>
> Wow, this is amazing!
>
> Quick bug report: elm-check says that it's deprecated but isn't marked as 
> such.
>

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

[Max Goldstein]

Wow, this is amazing!

Quick bug report: elm-check says that it's deprecated but isn't marked as 
such.

-- 
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: Server Side Rendering with Node

[Matthew Griffith]

Hi Robert,

Check out: https://github.com/eeue56/elm-static-site

Also, it looks like server side rendering is on the docket for the next 
major revision of elm, 0.18 - 
https://groups.google.com/forum/#!topic/elm-dev/u66_K3AbqIM




On Sunday, August 28, 2016 at 1:09:46 PM UTC-4, Robert S wrote:
>
> Hey, I'm going to move my 23KLOC (Coffeescript) angular 1.5 SPA 
> application to... primarily React+Redux, but I found elm and I'm reviewing 
> if it fits my requirements.
>
> *My first concern is Server Side Rendering (SSR) for SEO and fast page 
> loading. *
> I found https://github.com/NoRedInk/take-home but as I see it is approach 
> to replace PHP with ELM, than to provide SSR for single page app. 
> Also there is 
> http://blog.overstuffedgorilla.com/server-side-elm-with-phoenix/ with 
> source at https://github.com/hassox/phoenix_elm
> but I can't get it to work and evaluate with Windows 10... What's more I 
> completely don't understand what's going on there... Elixir is a black 
> magic for me :/
>
> Is there any way for production application to render with Node? The best 
> would be with precompiled elm? Without this I'll have to drop ELM and go 
> with React :(
>

-- 
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: Do the counters in the Guide teach us a wrong scaling approach?

[Dmitry Utkin]

Hi

On Sunday, August 28, 2016 at 2:02:04 PM UTC+3, Wouter In t Velt wrote:
>
> Something I have been struggling with for quite some time (coming from 
> React and Flux) is how to scale. There are various posts on this forum 
> related to the topic, e.g. Design of large elm apps 
> , parent 
> child communication 
> ,
>  
> components 
> 
> .
>

I'm struggling with this also, like most of us does. All of the approaches 
I've stumbled upon so far have their issues unfortunately.


> On structuring apps, I found the elm-sortable-table and the autocomplete 
> video - shared by Peter Damoc in this thread 
>  - 
> to be very helpful, as well as advice here 
> .
>
> My summary of the advice is more or less:
>
>- Forget about about "components": the term is very confusing, means 
>very different things in different contexts.
>- Start to build with 1 Model, 1 Msg, 1 update, 1 view
>- As soon as one these becomes too big, seperate that one out to a 
>view-helper, or update-helper etc
>
> This very much feels like a "top-down"  approach: the module you start 
> with remains on top. Put everything in there, and split out if needed.
> I keep reminding myself to stop trying to keep pieces of each of the 4 
> building blocks (Model, Msg, update, view) bundled as I separate out. That 
> it is fine to e.g. just put a piece of view code in a separate place - 
> *without 
> trying to bundle it with corresponding pieces of Model, Msg, and update.*
>

I'm not sure why all this `let's not call components "components"` thing 
started recently. I thinks it's perfectly fine to think in the terms of 
`components`, `widgets`, parent-, child- and all that stuff. Almost 
anything on a webpage can be named as a component, having child components 
and a parent component. It's natural to group and name those things this 
way, imho. Context matters, of course and it's OK.

The issue we have with terminology is `stateful components`(in OOP terms) 
vs `stateless components`. In React world, this is an issue since React 
components implemented as classes can contain state.
Elm nature tells us that there's not such thing as a `stateful Elm 
component`. So we always use this term without being misinterpreted - great!

So in the Elm world, component is a piece of code that
1) takes some props\params\input
2) generates html as a visible output to the input given
3) pipes the user-generated events up to the appropriate handler

In pre-0.17 world we had an easy way to pass the handler(signal address) 
down by providing some context to the `view` like this 

 
The simplest thing, like passing a callback in JS.
But nowadays(if we're going the fully-featured component path), we need to 
handle all of the events by generating a Msg, handling that Msg inside the 
`update` function of the component and then just return some kind of 
`OutMsg`(or `Dispatch` or `Whatever`) up to the parent.
If parent is not interested in this kind of event, but knows that his 
parent IS, it has to still has to convert it to some `ParentOutMsg` and 
bubble up the event to it's parent. Now *this* is the real issue that 
brings ideas like `stay flat for as long as you can` to life, imho.
 

>
> Now I am not sure that my take on "how to do stuff"  is the right way, but 
> it does seem that the *multiple-counters example in the guide teach us 
> exactly the opposite pattern*. 
> *Do the multiple counter examples in the guide put us on the wrong foot?*
>

Still waiting on this page 
 of the guide 
to update. Maybe Evan will come up with a nicer way to handle the wiring 
and Elm apps could be claimed to scale up easily.
I don't think the examples are bad because I'm not sold on the `stay flat` 
or `start flat` and the best argument against that idea is how clear and 
self-contained Conter.elm 

 is, 
and how easily it's being reused in two different apps in the `/nesting` 
folder.
 

>
> We start out with one counter being the top module, and then we add a 
> wrapper *on top* to handle multiple instances of this counter.
> To make matters worse: the multiple counter examples introduces the kind 
> of opaque nesting and messaging structure that is being discouraged here:
> The parent does not know anything about each child counter, parent has its 
> own Msg structure etc.
> After 

[elm-discuss] Re: Do the counters in the Guide teach us a wrong scaling approach?

[Eric G]

My take on it is - the standard "counter" examples are used not just in Elm 
but in lots of virtual-dom-based frameworks, I used to hate them as well 
but now I see their usefulness as a "Short, Self Contained, Correct 
Example" in which the domain has been reduced to the bare minimum. And I 
have to say I found the progression from counter -> pair of counters -> 
list of counters was instructive and sticks with me -- even if it wasn't 
the only way I learned Elm.  But beyond the basic mechanics of updating 
nested state, it doesn't get you very far.  

Part of the challenge with tutorials built around "realistic examples" I 
think is that people look at the final code and are tempted to think that's 
a model for how to start out, when of course it's a whole organic process 
with many many decisions behind how the code got to that point, and what 
makes sense in that case may not in another.

I am very glad we have the videos (and code) from those code sessions now 
to study, but my understanding is they are focused on building reusable 
components and specifically on the interface between those components and 
your app (have not looked at them yet myself so I could be wrong). This 
seems different to me from structuring your app's modules.  

In your app, any given parent references child Model, init, update, view, 
and sometimes Msg directly, and there are well-worn paths for doing this, 
made quite easy with Html.App.map, as well as emerging conventions for 
passing back messages to the parent from the child (OutMsg, etc.). 

For components on the other hand, the interface has to be worked out in 
terms of what the component hides from your app, and there are different 
approaches.  So I don't see the process of app development as aiming at 
'decoupling' your whole app into components, that seems to add complexity 
where it's not needed.

(That said, there are times when I have done things like what you suggest 
with the counter subviews -- parameterized them by passing in msg or msg 
constructors -- when I have two variants that are otherwise identical. I 
always feel dirty doing that though and try to keep that to a private view 
function close to where it's called. )


On Sunday, August 28, 2016 at 7:02:04 AM UTC-4, Wouter In t Velt wrote:
>
> Something I have been struggling with for quite some time (coming from 
> React and Flux) is how to scale. There are various posts on this forum 
> related to the topic, e.g. Design of large elm apps 
> , parent 
> child communication 
> ,
>  
> components 
> 
> .
>
> On structuring apps, I found the elm-sortable-table and the autocomplete 
> video - shared by Peter Damoc in this thread 
>  - 
> to be very helpful, as well as advice here 
> .
>
> My summary of the advice is more or less:
>
>- Forget about about "components": the term is very confusing, means 
>very different things in different contexts.
>- Start to build with 1 Model, 1 Msg, 1 update, 1 view
>- As soon as one these becomes too big, seperate that one out to a 
>view-helper, or update-helper etc
>
> This very much feels like a "top-down"  approach: the module you start 
> with remains on top. Put everything in there, and split out if needed.
> I keep reminding myself to stop trying to keep pieces of each of the 4 
> building blocks (Model, Msg, update, view) bundled as I separate out. That 
> it is fine to e.g. just put a piece of view code in a separate place - 
> *without 
> trying to bundle it with corresponding pieces of Model, Msg, and update.*
>
> Now I am not sure that my take on "how to do stuff"  is the right way, but 
> it does seem that the *multiple-counters example in the guide teach us 
> exactly the opposite pattern*. 
> *Do the multiple counter examples in the guide put us on the wrong foot?*
>
> We start out with one counter being the top module, and then we add a 
> wrapper *on top* to handle multiple instances of this counter.
> To make matters worse: the multiple counter examples introduces the kind 
> of opaque nesting and messaging structure that is being discouraged here:
> The parent does not know anything about each child counter, parent has its 
> own Msg structure etc.
> After scaling, the counter now has in effect become something that looks 
> and smells very much like a component.
>
> Just the other day I realized that much of my struggle with scaling came 
> from stuff I picked up on day 1 of learning Elm, with sinful thoughts such 
> as:
> "Hey, this counter thing in Elm is just like a reusable UI 

Re: [elm-discuss] Elm shell aliases

[Max Goldstein]

Sorry, I was unclear. The --yes flag is already accepted (don't prompt to 
download packages) and you can consider adding it to the aliases. 

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

[Zachary Kessin]

I just have all my normal commands in a makefile. That makefile also builds
some Erlang and a few other things

Zach
ᐧ

On Sat, Aug 27, 2016 at 3:58 AM, suttlecommakevin <
suttlecommake...@gmail.com> wrote:

> What would it do? I know it accepts all the default input params for
> things like `npm init`. Would it do the same?
>
> --
> 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.
>



-- 
Zach Kessin
SquareTarget 
Twitter: @zkessin 
Skype: zachkessin

-- 
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: Design of Large Elm apps

[Richard Feldman]

>
> Components should only update their own private non-shared state that 
> other components don't need. Shared states such as your server queue are 
> updated at the highest level and each sub component merely receives a 
> function to run the update.
>

Apologies, but I have read and re-read this and I'm still not sure what 
it's saying. :x

That's totally on me, but I'm quickly becoming convinced that Evan's view 
of the term "components" 
 
is dead-on: our speaking in terms of "components" seems to result in way 
more confusion than positive outcomes. I'm on board with the idea that we 
should stop using it to describe portions of Elm programs, and instead 
focus discussions on terms whose definitions are clearly applicable: 
modules, functions, data, and the first-class Elm Architecture building 
blocks of Model, Msg, update, and view.

I gather that this is has to do with an interaction between two update 
functions...is there some way to rephrase it in terms of how those two 
update functions interact?

-- 
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] A more concrete question about API design

[Richard Feldman]

Totally agree with Nick's advice 
. 
Well said! :)

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