I'm a little pressed for time, but I'll try to give a general architecture outline that works really well for us. Our primary elm SPA is a customer facing administrative control panel that communicates with a backend api server and amazon S3. The app manages authentication, authorization, subscription status, and currently has 17 'pages'. This particular app is a Static SPA (currently served from s3-cloudfront combo).
*Backend API Client* We have an api client written in elm that resides with the api server. The api-client elm module can be pulled into any elm project that needs to communicate with the backend server, and includes all http requests, model types, model json decoders, and any necessary model helpers. Importantly, this is where authorization and authentication is handled as well. A user who successfully signs-in via the api will be granted an authorization token. The authorization token must be provided with each following request to the api. example: https://gist.github.com/eriklott/812a63be9d9cfd6a949cccaa94e6790c *SPA* The folder structure for the majority of our elm SPA's end up as follows: - Component (folder) - Pages (folder) - Main.elm - Route.elm - Routing.elm .. any other app/infrastructure related modules *Route.elm* Module encapsulating functions relating to routes: https://gist.github.com/eriklott/812a63be9d9cfd6a949cccaa94e6790c#file-route-elm *Routing.elm* The routing module holds the state of the current page, and isolates logic pertaining to which page is displayed for each route https://gist.github.com/eriklott/812a63be9d9cfd6a949cccaa94e6790c#file-routing-elm *Main.elm* This is where the top level modules are wired together. It's difficult to create a generate example for this since your Main.elm will be application specific. Here is a hacked together example of a Main that you can sift through and try to understand what's going on in this specific application: https://gist.github.com/eriklott/812a63be9d9cfd6a949cccaa94e6790c#file-main-elm Some things to note: The client configuration is stored in the main model and passed down into the pages. When a page triggers a logout or login, that fact must travel back up to the main module so the client configuration state can be adjusted accordingly. If you need to know how to do this, I'm happy to explain. *Pages* Here is an example page: https://gist.github.com/eriklott/812a63be9d9cfd6a949cccaa94e6790c#file-page-apples-elm *Components* There are mostly shared headers, footers,menus, that are shared across various pages. Some have their own state, but most are simple reusable view helpers. Sorry for being short on descriptions. Hopefully the examples are enough to give you a sense of direction and organization. Happy to answer any questions. On Wednesday, April 19, 2017 at 5:11:05 AM UTC-4, Peter Damoc wrote: > > Hello community, > > Scaling Elm apps seams to be a recurring topic. > > I was wondering if maybe we could negotiate a minimal set of > functionality, something similar to ToDoMVC, that could be implemented > using different approaches to explore what could be the best way to > structure the code. > > What should this minimal example cover and what this minimal example > should be (topic)? > > I'll start the list with some bits of functionality that I would like: > > - multiple pages with common structure (sidebar/navbar) > - navigation without reloading the app (SPA routing without the hash) > - authentication > - complex widget reuse (a module/widget that generates side-effects; e.g. > a weather widget, some stock ticker, an ad provided by a third party) > - styling (CSS) > > I would also like the example to cover real world concerns of: > - using a build manager to integrate with other technologies > - development mode - deployment build > - testing > > As for topic, I was thinking about an interface to the MusicBrainz > Database (a simplified interface). > > What do you think? > What bits of functionality would you like to see exemplified? > Are you aware of any other project (in other languages) that exemplifies a > minimal set of functionality and could be used as a template? > > > -- > There is NO FATE, we are the creators. > blog: http://damoc.ro/ > -- 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.
