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 [email protected]. For more options, visit https://groups.google.com/d/optout.
