In my app, my elm code was structured like this (note that this is an SPA with no server integration ...)
/Master.elm <-- SPA host. Hosts a header, drawer, login dialog and view stack /Account/Login.elm <-- Login dialog /Account/WorkoutEditor.elm <-- Views that can be accessed only by logging in /Account/Share.elm ... /Header/Header.elm <-- Header renderer /Splash/Welcome.elm <-- Default view /ShowCard/Search.elm <-- Views that can be accessed without logging in /ShowCard/SearchResult.elm ... /ShowCard/WorkoutInfo.elm ... /ShowCard/WorkoutView.elm ... It might seem like you'd need a big update function but I composed a bunch of small ones with http://package.elm-lang.org/packages/prozacchiwawa/effmodel/2.0.0/ like this: Happily, if you do this, you can write tests that ensure that each sub-update implements the right state transitions. effModelUpdate : Action -> EffModel Model Action -> EffModel Model Action effModelUpdate action effmodel = effmodel |> handleMDL action |> handleSlugUpdate action |> handlePageAnimation action |> handlePurposeSet action ... -- Snipped |> handleFacebook action |> handleSlugArgs action |> serializeTimer action |> handleLoginAction action |> handleLoginProcessAction action Each of these functions conceptually handles a self contained set of messages related to one feature. Connecting the subcomponents via ports would be an option, but this worked ok. I wrote about the way these are composed here: https://medium.com/@prozacchiwawa/the-i-m-stupid-elm-language-nugget-6-48229076c88e#.2fgf44mx3 For each subcomponent I had a small test main that set up some test data and ran the component on its own. That's one reason I think that splitting up views into modules is a good idea. On Thursday, August 4, 2016 at 3:15:53 PM UTC-7, Ryan Erb wrote: > > Got a few questions regarding the best way, or what options there are for > scaling up to a large site. > If i have a site with lots of features what is the best way to orgainze > everything? > > *One Elm page to rule them all?* With this approach you only have to deal > with one update happening, you can separate code into different modules, > but the update function would be HUGE. Guess this would be the same as a > single page application? > > *One Elm page per HTML page?* This way every page deals with only what it > is used for. You can write common things in reusable modules. One problem > might be switching to other elm pages. The only really good way right now > that i have is using a port to "window.locaion.href" to another elm page. > Then pulling all the data it requires from the server using more ports. > > *One Elm page per feature?* This way you can write separate apps for each > part of your page. One for the header menu bar, one for a sidebar, and one > for each main feature. This way you can mix and match and piece together > for a full page. BUT you might have to do a lot of port talking between > each section. > > *Some other way?*????? > > Been searching around a cant seem to find any blogs or topics on this > subject. Our stack is Elm/Phoenix/Elixir/Postgres. > > If anyone has created a large application using Elm would happy to have > your input on what worked/ didn't work for you. > > Thanks, > > -- 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.
