On Wednesday, January 25, 2017 at 3:25:56 PM UTC, Alex Barry wrote:
>
> we tried to stick to generally Module.View, Module.Update, and
> Module.Model. We had a few instances where we had to break out sub-update
> messages (ie the union type typically used in Module.Update) because we had
>
Just to pipe in with my experience, I'm working on a medium sized project
with a lot of inter-related data between my modules, which is dictated by a
database structure. We started the project as a single file elm project,
but the code was starting to get unmanageable, so we broke it out into
On Wednesday, January 25, 2017 at 12:11:46 PM UTC, Rupert Smith wrote:
>
> I think a better approach would be to put build a TEA component like this:
>
> module MyComponent exposing (Model, Msg, update, view, init,
> subscriptions) -- and perhaps also OutMsg
>
So I think I understand where the
On Tuesday, January 24, 2017 at 4:32:41 PM UTC, jphedley wrote:
>
> FYI, Kris Jenkins' approach-
> http://blog.jenkster.com/2016/04/how-i-structure-elm-apps.html
>
Part of the reason I think this design is wrong, is that when importing a
component into the top-level Main module to use it, I have
On Tuesday, January 24, 2017 at 4:32:41 PM UTC, jphedley wrote:
>
> FYI, Kris Jenkins' approach-
> http://blog.jenkster.com/2016/04/how-i-structure-elm-apps.html
>
Yes, that is what guided me to the Type/State/View structure. I forgot
about Rest, I already split Rest off into its own shared
FYI, Kris Jenkins' approach-
http://blog.jenkster.com/2016/04/how-i-structure-elm-apps.html
On Tuesday, January 24, 2017 at 7:25:01 AM UTC-8, Rupert Smith wrote:
>
> I took some advice early on that a good way to structure components in a
> nested TEA is to split each into 3 files; Types.elm,
On Tuesday, January 24, 2017 at 3:25:01 PM UTC, Rupert Smith wrote:
>
> Some candidate "rules of thumb":
>
If a group of modules are always imported together (like happens a lot with
the Type/State/View pattern), they contain highly related functionality
that would work better as a more