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

Would it be possible in your architecture to perform server requests at the highest level of your application? You would then send a a->Msg to each sub component. That way server requests would only be performed in one place where you could fine-tune how you want them performed. This comes from

[elm-discuss] Elm shell aliases

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 t

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

> > Keeping code to the same code flow keeps different programmers from > finding different ways to update the priority queue in the root model with > their request. > Almost forgot to mention: I think the best way to accomplish this is with opaque types. You make a module that holds the "enqu

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

> > AppCommand seems like overkill. We need to prioritize our HTTP requests. > Do we really need a drop-in replacement an entire foundational core library > to do that? Why not just say "we have a business need to do HTTP requests > in a certain way, so everybody on the team, use this way inste

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

On Aug 26, 2016, at 3:34 PM, Richard Feldman wrote: > > AppCommand seems like overkill. We need to prioritize our HTTP requests. Do > we really need a drop-in replacement an entire foundational core library to > do that? Why not just say "we have a business need to do HTTP requests in a > cer

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 into

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 the hard part. I know yo

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 secti

[elm-discuss] Re: Should I have a CSS file for my made-with-Elm web app?

On Friday, August 26, 2016 at 5:10:30 PM UTC+1, Thibaut Assus wrote: > > I think css stylesheets are useless in Elm. Inline styles are a lot better > imo for reactive procramming. I plan to write a blogpost on that soon. An > exemple of my ideas in a repo : > https://github.com/tibastral/elm-cre

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

> > I'm trying to rebuild the successor to some past systems in Elm and one > thing we learned on those systems was that to get good performance it was > critical that we prioritize HTTP fetches so that we didn't ask for the low > priority items at the same time as the high priority items. From

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

I guess the way I've been building my main project, I do end up emulating the command architecture further down. It works pretty well so far! I am not using the Cmd type, but I think that is a good thing, because my internal APIs have nothing to do with Elm's platform API. If you used the platform

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

> > We could probably emulate the whole of the command architecture adding > batch, none, and map functionality to QNQ. This would allow the code to > look much the same as before but would force the widespread replacement of > Cmd with our new QNQCmd. That's feasible but what if we have more than

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

Thanks, Josh, That seems to confirm my impression that the answer may be "don't use commands for subcomponents". Use command-like things in similar patterns, but don't use commands. And I'd be fine with that if that were generally embraced. But then we also wouldn't need Cmd.map since commands woul

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

I've already hit the problems. I'm trying to rebuild the successor to some past systems in Elm and one thing we learned on those systems was that to get good performance it was critical that we prioritize HTTP fetches so that we didn't ask for the low priority items at the same time as the high pr

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

I'm not annoyed at you, Nick. I'm sorry if I came across that way. The queue logic is attractive because it's straightforward but it's also contrived so seeing the discussion veer toward how to write the queue feels like looking for ones keys under the streetlight because that's where the light is.

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

On Friday, August 26, 2016 at 1:24:15 PM UTC-5, Mark Hamburg wrote: > > People create layer cake designs because they help manage systems > complexity. What I'm hearing here is that Elm should only be considered for > the very topmost layer. If it can't reach deeper, then it needs to compete > w

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

> > you seem insistent that the right approach to Elm is to write relatively > monolithic pieces of code and then try to tease them apart if they become > too complex. > Yes, exactly! Considering this is the most consistently successful approach to scaling in the entire history of software, I

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

> > I now need knowledge of the sequencer to flow through the program in a way > that effects managers avoid. > I disagree with this statement. I was hoping that by iterating through this solution, we would eventually come to an agreement re: the claim quoted above. But you are annoyed at me for t

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

I've been determined to try to use Elm as a solution for building potentially large applications. Maybe I should just be taking what you are saying as an indication that it's not useful for that and I should go back to looking at JavaScript. I'd hate to do that because I like the typed, pure functi

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

As I said, I know how to write the queue if that's what I really want. My problem is that when a module uses the WebSocket.send function to create a command, I don't have to do anything special in my program to arrange for that command to make its way to the web socket effects manager. I just need

[elm-discuss] Elm shell aliases

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

[elm-discuss] Re: reactor with actual application urls?

Check out elm-live - its --pushstate flag is for exactly this use case! :) -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group an

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

> > I'm going to try to take the large app design questions and focus them on > a more narrow and *admittedly contrived example*. > > From what I understand of effect managers, we could write an effect > manager to do this but *the documentation around effect managers > discourages reaching for

[elm-discuss] Elm shell aliases

Anyone else too lazy to type the Elm shell commands out? Here's what I use: ``` alias er="elm-reactor" alias em="elm-make" alias ep="elm-package" ``` https://cldup.com/9ghxfO9Xwt.png -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscri

[elm-discuss] Re: Should I have a CSS file for my made-with-Elm web app?

On Friday, August 26, 2016 at 12:10:30 PM UTC-4, Thibaut Assus wrote: > > I think css stylesheets are useless in Elm. Inline styles are a lot better > imo for reactive procramming. I plan to write a blogpost on that soon. An > exemple of my ideas in a repo : > https://github.com/tibastral/elm-

[elm-discuss] Re: Old browsers

On Thursday, August 25, 2016 at 3:14:17 PM UTC-4, Luke Westby wrote: > > You're welcome! I apologize for the terseness of my previous comments, was > in a hurry and let that get in the way of friendliness. > Sir, no need to apologize! Your posts are always extremely friendly and helpful :) I'm

[elm-discuss] Should I have a CSS file for my made-with-Elm web app?

I think css stylesheets are useless in Elm. Inline styles are a lot better imo for reactive procramming. I plan to write a blogpost on that soon. An exemple of my ideas in a repo : https://github.com/tibastral/elm-credit-card. Look at the style part. Have a good day ! -- You received this mess

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 >> > > OP said "If i have a si

Re: [elm-discuss] Question about pure functions

I would only introduce something like the createModelWithProp1Something function if I had the desire (or reason to believe that that desire might later arise) to apply it to something else than defaultModel at some point. If I knew I would only ever be going to apply createModelWithProp1Something t

Re: [elm-discuss] Question about pure functions

Hi Janis, Thanks for the explanation. Would you do something like that or you'd rather pass the defaultModel into the function? createModelWithProp1Something model: Model createModelWithProp1Something = { model | prop1 = "Something" } -- Somewhere else let myModelWithSomething = createMode

Re: [elm-discuss] Question about pure functions

What you are doing there is absolutely fine. Functional programming is about values and functions. In your example you define some values based on other values (without modifying the original values, of course). No reason to feel “that it goes against pure functions”. It does not. ​ 2016-08-26 8:5