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

One nice thing that comes out of this architecture is that if one could run pieces on separate threads, it would split very naturally between the service side and the client side. The only ugly part is that in addition to moving data over whatever bridge we're using, we also need to move tagger

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

I re-read your message, Erik, and my reply and realized that I hadn't answered all of the questions. The routing I've been working with handles both commands created by the client side and handled by the service side and commands created by the client and handled by "normal" external means. This

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

On Sunday, August 28, 2016 at 10:14:43 AM UTC+2, Richard Feldman wrote: > > 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

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

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

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

Not using Cmd does make (!) far less useful. Mark On Sat, Aug 27, 2016 at 3:14 PM, 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

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

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

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

> > I know you just like to let stuff accumulate in one monolithic piece, but > if you wanted to subdivide some of the major sections into sub-modules Just to be clear, at work we split things up into *modules* at the drop of a hat. If a particular file is too long, pulling some of it out

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

Oops. Typo. That should be | Queued Int (Cmd msg) On Fri, Aug 26, 2016 at 3:03 PM, Mark Hamburg wrote: > Thanks, Richard. That all works if everything is essentially sitting > together at the top level and talk to the model. As I said, writing the > queue isn't really

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

Thanks, Richard. That all works if everything is essentially sitting together at the top level and talk to the model. As I said, writing the queue isn't really the hard part. I know you just like to let stuff accumulate in one monolithic piece, but if you wanted to subdivide some of the major

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

> > Before committing to a new framework like Elm, one would first like to > know that it can be scaled, how it can be, what will be necessary to > refactor code to make it scalable and what pitfalls one could have avoided > in the first place that may become big problems later. I feel more

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

On Friday, August 26, 2016 at 12:53:01 AM UTC+1, Mark Hamburg wrote: > > On Aug 25, 2016, at 2:51 PM, Richard Feldman > wrote: > > Richard's definition of large application (36,000 lines) and my definition >> (Photoshop, Lightroom, ...) are rather different in scale >> >

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

And when we go to four programmers, we use mob programming... :-P On Thu, Aug 25, 2016 at 5:22 PM, Nick H wrote: > some scaling issues arrive the moment you would like to have two people >> work on something > > > Well, those two people are going to be pair

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

> > some scaling issues arrive the moment you would like to have two people > work on something Well, those two people are going to be pair programming, right? ;-P On Thu, Aug 25, 2016 at 4:52 PM, Mark Hamburg wrote: > On Aug 25, 2016, at 2:51 PM, Richard Feldman

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

> > some scaling issues arrive the moment you would like to have two people > work on something. At that point, they can generally both be more > productive if you can subdivide the work, put an API in place in between, > and then let each proceed in a separate file. > I understand this

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

On Aug 25, 2016, at 2:51 PM, Richard Feldman wrote: >> Richard's definition of large application (36,000 lines) and my definition >> (Photoshop, Lightroom, ...) are rather different in scale > > OP said "If i have a site with lots of features what is the best way

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

Richard's definition of large application (36,000 lines) and my definition (Photoshop, Lightroom, ...) are rather different in scale, so maybe that's part of the difference in perspective and my sense that one needs to find good ways to carve things apart. With that in mind, let me put an

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

> > I have similar concerns about how deep down the stack Elm can go. At some > point, it seems like a good thing to separate business logic concerns from > UX logic concerns. This can already be done today, using plain old modules and organizing your data structures in a way that makes

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

On Aug 17, 2016, at 4:25 AM, Oliver Searle-Barnes wrote: > > e.g. I'm using websockets to communicate with the server, in my previous > experience I would have implemented a Store of some sort which took care of > communication with the server and allowed the view layer to

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

On Wednesday, August 17, 2016 at 5:25:45 AM UTC-6, Oliver Searle-Barnes wrote: > See elm-mdl for example, what are your thoughts on the elm-parts approach? > I quite like the elm-mdl/elm-parts approach, very extensible. Do note that elm-mdl only uses elm-parts for parts that hold any kind of

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

Thanks, this is really practical advice. The first three things you should reach for are, in no particular order: > >1. Splitting view into smaller functions (without reorganizing Model >or update) > > >1. Splitting Model into smaller values (without reorganizing view or >

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

Thanks so much Richard, that's absolutely fascinating! The way that I've been building my current generation of Elm apps has been modelled on the Counter/Pair example. So it's not uncommon for me to have apps with nested M/V/U models 3 levels deep (For example, a "page" containing a "panel"

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

> > Are you suggesting that each self-contained Elm "app" ("page", "game" > etc.) should only have one Model/View/Update and avoid using nested modules > for sub-components? Yeah - do you mean that something like the nested counter example from the Elm > Archtecture guide is a bad idea?

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

> > How big do the case statements in your update functions get? Or are your > pages just not that complex? > > I tend to like to keep modules in any language to a size that can be > reasonably read and comprehended. That doesn't always happen. I've written > some behemoths. But I tend to feel

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

How big do the case statements in your update functions get? Or are your pages just not that complex? I tend to like to keep modules in any language to a size that can be reasonably read and comprehended. That doesn't always happen. I've written some behemoths. But I tend to feel guilty when

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

> > Haha yeah I get your point, but when you talk about the large redink code > base (no doubt it's huge), I'm curious of the granularity of your > production Elm apps. Is your code base generally organized as one/a few > large single page applications (routing handled client side - data via

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

Haha yeah I get your point, but when you talk about the large redink code base (no doubt it's huge), I'm curious of the granularity of your production Elm apps. Is your code base generally organized as one/a few large single page applications (routing handled client side - data via api) or is

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

Generate updates as commands, in structs. Add them to a list during the current frame. Current state remains immutable. At the end of the frame apply all commands to generate next world. Next step starts with new world, old one is discarded. Lather rinse repeat burmashave -- You received

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

Thank you Peter for sharing the sortable table and especially the video link! Video has a somewhat long winded exploration in accessibility in the early part, but I found it most helpful. The thoughts on config and even updateConfig were really helpful. Also the idea to have an update take in 1

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

thank you Peter, I will try this approach and see how it works for my app. On Tuesday, August 9, 2016 at 11:57:22 AM UTC+2, Peter Damoc wrote: > > Hi Robert, > > To better understand the whole "state ownership" situation, take a look at > the implementation of elm-sortable-table >

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

Hi Robert, To better understand the whole "state ownership" situation, take a look at the implementation of elm-sortable-table https://github.com/evancz/elm-sortable-table and if you have the time/patience, watch this api design session https://www.youtube.com/watch?v=KSuCYUqY058 What I can

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

That gist is old. For current Elm Architecture, please refer to the guide. http://guide.elm-lang.org/ I don't know about "the best way" but I can share how my App is structured. I have two types of pages in my app: Interactive and Informational. The informational pages are typically generated

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

That is the approach I would take. Don't forget that the elm website and package manager are written in elm, and they are open source! Recommended reading ;-) > On Aug 4, 2016, at 6:45 PM, Ryan Erb wrote: > > Well after a bit more searching found this > >