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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
