I'm unsure if this is Elm'y, but it is built on prior experiences with other languages.
I currently have a javascript app that I am slowly converting to Elm as parts gets replaced, so I am using a lot of little embedded Elm apps (in a single file so as to not duplicate the standard large library). Each one has a main section that calls to and builds up other areas. I have a singular Helper that can dispatch around that I implement in each of my main apps like (which I understand is similar to debois/elm-parts though I think is more generic?) ```elm type alias Model = { helpers : HelpersModel Msg | others... init : ProgramFlags -> Result String Location -> ( Model, Cmd Msg ) init programFlags locResult = let model' : Model model' = { helpers = Helpers.helpers_init Helpers , etc... type Msg = Helpers (HelpersMsg Msg) | etc... update : Msg -> Model -> ( Model, Cmd Msg ) update msg model = case msg of Helpers helpersMsg -> let ( helpersModel, helpersCmd ) = Helpers.helpers_update Helpers helpersMsg model.helpers in ( { model | helpers = helpersModel } , helpersCmd ) subscriptions : Model -> Sub Msg subscriptions model = Sub.batch [ helpers_subscriptions Helpers model.helpers , etc... ``` I should probably switch to debois/elm-parts as it is an actually released library and so wrap my helpers into it for my project, but as it stands I can make new components (many counters if I want!), wrappers for a ton of port functionality (How about focus an element after the next rendered frame? Sure! `cmd_onNextFrame Helpers <| focusElem Helpers input_selector`), etc... On Thursday, August 4, 2016 at 4:15:53 PM UTC-6, 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.