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.
