Oliver, We have the Store abstraction that I mentioned for data synchronisation
Sure. I'm sure this isn't too different - conceptually - from what we're doing. Although our app manages some complicated processes, the communication with the backend server is as simple as it gets - json gets and posts. > > We have two different top level modules depending on whether or not you're > logged in (AppState) It's interesting that you mention that, because we also experimented with separating our Auth and Public sides of the app via the type system. I can't remember why we chose to flatten the app instead... but we did. We split our larger pages into sections which function as separate mini > apps Yeah, we do the same when necessary, although we use different naming. A "Page" in our applications always represent a single onscreen page - so routes and pages are always mapped one to one. When we have multiple components/widgets on a page, those are broken into separate modules (mini-apps as you say) and likely stored in the components/widget folder, or broken out into a standalone package. I've found myself thinking in terms of mini apps a lot lately. Each Page > and each page Section functions as a separate mini app, notably they don't > interact with each other, the only communication between them is via data > in the Store which they all share. Exactly. On Wednesday, April 19, 2017 at 12:52:11 PM UTC-4, Oliver Searle-Barnes wrote: > > That appears to have much in common with our app. It seems useful to > compare what people building SPAs are currently doing so here's a rough > gist of the folder/file structure that we're using > https://gist.github.com/opsb/d0977bcb30b42302f3f2dc3daf0befec. There's a > few differences worth pulling out > > 1) We have the Store abstraction that I mentioned for data synchronisation > 2) We have two different top level modules depending on whether or not > you're logged in (AppState) > 3) We split our larger pages into sections which function as separate mini > apps > > I've found myself thinking in terms of mini apps a lot lately. Each Page > and each page Section functions as a separate mini app, notably they don't > interact with each other, the only communication between them is via data > in the Store which they all share. > > > > On Wednesday, 19 April 2017 17:57:28 UTC+2, Erik Lott wrote: >> >> 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.
