I feel like I just wrote you a vague response - something I try to avoid. If you have a specific question about how to build or structure something in Elm, don't hesitate to ask.
On Wednesday, August 17, 2016 at 12:19:21 PM UTC-4, Oliver Searle-Barnes wrote: > > I've been using Elm for about 4 weeks now and having generally been loving > it. An area that I'm really having trouble with though is architecture. The > basic TEA is a fantastic foundation but the guidelines are really very > limited with regards to requirements of a typical SPA. > > * Components - the best advice I've heard is to extract view/model/update > separately, as we've seen with elm-mdl this only goes so far though. In the > end every large application is going to end up with it's own framework > similar to elm-mdl so this seems to be an issue that needs to be resolved > somehow. > * Separation between view model(component state) and application model > (records from the server) - previously I've always had these two separated > which has meant that I can have multiple views updating the same server > records. > * Services - when I've had cross-cutting concerns I would typically manage > them in a service tier, e.g. I'm using websockets and want to update the > view optimistically. Managing the optimistic vs confirmed state isn't > something that I'd expect to have abstracted away from the view. > > I'm not really looking to resolve these issues here but I do feel like the > community is going in circles. Every day we hear the same questions like > "how does parent-child communication work?" but the advice that is given is > different depending who you ask (and always feels unresolved). > > A general concern I have is that the impression that's given is that > abstraction is treated as something which should be avoided. This seems > unworkable for large SPAs. It gives the impression that perhaps no one in > the Elm community is really building large applications. > > > These are my concerns and issues, what I'm really looking for though is an > approach to move things forward. Given that there are existing frameworks > with well understood architectures I wonder if we should work on guides of > the form Elm for React users or Elm for Ember users and try to translate > the concepts from those frameworks into practical solutions within Elm. I > think this would help clarify the advice and perhaps uncover areas where we > need to give some more thought. > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
