Hey Peter! 👋 Thank you for looking into this thing! 🤓
On Thursday, August 24, 2017 at 10:47:24 AM UTC+3, Peter Damoc wrote: > > On of the key recommendations of Elm Architecture is to have your messages > be just data. > > Your approach is somewhat similar to the approach of elm-sortable-table > (except for the Cmds and Subs). > > Without using Cmds and/or Subs it is an interesting approach if you use > it for managing very small bits of state (the open/close status of a > dropdown) but I'm afraid that it might bring performance problems if you > use it for the entirety of the app. > Regarding “very small bits” — I think this idea was one of the goals of going this way: any module represents one domain concept, and its view’s callback function deals with a value of that domain concept’s type. If a module refers to another domain concept, that concept has its separate module with its type, and view, and callback function that only knows about itself. (Well, ideally at least, for the most part, you know… 😉) > You basically have to computer all the possible future states of the app. > Not sure what you mean here. Could you please expand, or maybe point to an example in the code? 🤔 -- 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.
