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

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,

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

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

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

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

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

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

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

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

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

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)

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

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

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

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?

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

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

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

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

[elm-discuss] Partially applied record updates?

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

[elm-discuss] Re: Elm shell aliases

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

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

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

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

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

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

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

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

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

[elm-discuss] Re: Elm Package Skimmer

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

[elm-discuss] Re: Elm Package Skimmer

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

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:

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

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 >

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

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

Re: [elm-discuss] Elm shell aliases

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

Re: [elm-discuss] Elm shell aliases

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

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

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

Re: [elm-discuss] A more concrete question about API design

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