> > > If you have time, would you mind describing how the app works? >
This is a fairly high view of our app and how it's architected but hopefully it's a useful level of detail (I've mentioned it a couple of times already but here's a rough gist of the folder/file structure we use https://gist.github.com/opsb/d0977bcb30b42302f3f2dc3daf0befec). To give you a bit of our context our product is an embeddable web app that adds discussion rooms and news feeds to your website. We have Phoenix on the backend and we're using elm-phoenix for integration in the client. As well as providing a fully integrated UI which includes all of the features, we will also allow individual features to be embedded within particular pages e.g. an article might have a discussion embedded at the end, but that same discussion mini-app is also included in a view more closely resembling Slack with a sidenav etc. These requirements led us to an architecture where we have a single Store which handles data synchronisation and then several mini-apps which use this Store. The Store responsibilities include: subscribing to data feeds from the backend, caching results, mutating data in the backend and latency compensation (otherwise known as optimistic UI). At the top level these mini-apps are organised into complete pages. The pages themselves don't do much, they're mapped to urls and combine a set of mini-apps. Each mini-app is then responsible for it's own lifecycle (e.g. Loading/Loaded/Error). While the requirements have forced have led us towards the mini-apps design we've found that they're a great way to organise the codebase, developers can concentrate on a particular mini-app and get up to speed very quickly. -- 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.
