On Saturday, September 10, 2016 at 2:29:10 AM UTC-5, Mark Hamburg wrote:
>
> As for my Elm experience, I've built a moderately large project in Elm
> working with other developers. We've tried it the giant model way and the
> codebase became tricky to sustain multiple developers working at once and
> the ability to reason about it declined. Just relying on the type checker
> for refactoring was a lot like refactoring in C++ by changing a header file
> and fixing compiler errors until it built again which was arguably better
> than the experience in untyped languages but not in and of itself
> miraculous. We then did more to break the app into pieces and that worked
> but the plumbing often felt ugly, so the question has been whether
> there's a better way to decompose and structure large apps and what
> guidelines should be in place for structuring code when scaling up a team.
>
So this right here indicated to me a real, concrete example that we could
all kibitz on. Can you provide an example of the before/after the
plumbing? Maybe the path you took to solve breaking it into pieces was
ovezealous. I see a lot of people bring up this problem and I've built a
lot of elm code and just don't have it, so it always confuses me.
What I often see is what Evan refers to in the reuse section of the guide
now. A jump-too-far when running into a particular issue.
For instance, I've seen people introduce a ton of state and independent
updates when all I would have done in that situation is break out a new
module to handle the complexity of a given view. You had a giant flat
model (I think this is wise as a starting point in Elm) and then you wanted
to tweak it. There are typically a few reasons for this:
1. The views are becoming confusing because they are forced to drill
into nested portions of the model. I've seen people do crazy things here
where they could have just passed in a particular field to that view or
destructured in the function head (the former is better but sometimes you
aren't well-factored and you need more than just the piece of the model you
should really care about).
2. The update is becoming overwhelmingly complicated. When this comes
up I've seen people do what I (again) consider to be crazy, when really
they could just tag a portion of their model in the top level Msg,
introduce a UserMsg' or something similar, and break out all the
user-related pieces into an `updateUser` function they call from the top
level model. This isn't bad at all either. Html.App.map, Cmd.map, and
Sub.map are perfect for this exact use case.
1. If you are in a situation where you can't easily just
"Html.App.map" a subset, just use function composition. I have a
top-level
Msg that's "NavigateTo Route.Location" and I want to be able to send that
out from any of my children, so I can either Html.App.map the
'sub-view-functions' inside those child views or I can just compose the
taggers in-place and refactor it whenever I feel it's gotten too
bothersome.
You don't really have to go whole-hog to solve those problems. Most of the
times I've dug into someone's problems of this nature, once we had a
concrete discussion of their concerns and actual code, we were able to find
a solution for them. I dislike contrived examples specifically because
they ask for a general solution where I just think you likely shouldn't.
There are 5 or 6 patterns to solve different levels of this 'problem'. In
my opinion the proper way to learn Elm is to gradually improve the dumb/bad
code until it's amazing. I've *literally only seen this issue come up* when
people wanted to "solve all the future issues at once" rather than just
incrementally making a codebase better.
Would you be willing to paste some example code so we can see the problem
you faced and the way you solved it? If so, maybe we could find that if
you'd made one small tweak to your solution then you never would have
achieved this level of frustration.
The point
My core point - every time we've had a discussion about concrete code that
wasn't a contrived example, I've seen good things happen. For contrived
examples, there's too much "I want to take as an axiom that I should do
something that seems unreasonable to people that have built large things in
Elm successfully - now let's talk about how to make that unreasonable thing
nicer."
Sidebar
The elm-mdl/elm-parts issue is in my opinion entirely coincidental (though
related) to this discussion. I'd love to have a discussion about it but I
think this thread isn't the place. I think it'd be fun to have some people
try their hand at using the non-elm-parts style of elm-mdl and see how
usable they can make it / get a list of what those solutions look like. If
someone's interested in talking about elm-mdl/elm-parts, does starting a
thread with that explicit goal seem interesting to you?
--
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.
