Brilliant! Thanks a lot!
To summarise what I understood:
- A component should only update its internal states
- All updates of shared states should be done at a higher level
which could be further summarised in:
A state should only be updated by its owner (i.e. the highest component
where that s
This suggests a generalization to the Elm update/view architecture pattern.
The functions stay the same but the signatures change:
module Component exposing (InternalState, ExternalState, InternalMsg, init,
update, view)
type InternalState = ... -- the purely internal information for the
compo
Thanks! So let's start by talking about Slider for a sec.
SliderMsg (Slider.ChangeValue newSpeed) ->
{ model | profile = newInternal, shared = Trip.setAverageSpeed model
.shared newSpeed }
Because this code compiles, and it only covers the ChangeValue constructor,
then assuming spe
The profile widget contains one slider and several date-time pickers
wrapped in a WaypointConf component.
For Profile.update, I start by updating the internal model with the exposed
model (possibly creating a fresh internal model if the selected route has
changed):
internalUpdate : Msg -> Inter
Follow up questions: What do Profile.update and Profile.Msg look like?
Also, what kinds of different places do different profiles get updated?
On Wed, Aug 24, 2016, 11:11 PM Charles-Edouard Cady <
charlesedouardc...@gmail.com> wrote:
> I have just one more tiny question: if the Profile module onl
I have just one more tiny question: if the Profile module only has a view
function, how do you handle Profile.Internal's update? More specifically,
in the profile widget, each waypoint (there can be any number of them per
route) has its own date picker which has an internal state (opened/closed,
Awesome! Best of luck with it! <3
On Wed, Aug 24, 2016 at 1:43 PM Charles-Edouard Cady <
charlesedouardc...@gmail.com> wrote:
> Thanks a lot, Richard, it makes much more sense now!
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Elm Discuss" group.
Thanks a lot, Richard, it makes much more sense now!
--
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, v
typo: should have written "i.e.its return type needs to be Html msg instead
of Html Msg"
--
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...@
>
> While I understand that not breaking things up too often is sound advice
> in elm, I still think this doesn't answer my question
Here is concretely what I'd do:
type alias Model =
{ routes : List Route
, hovered : Maybe Int
, selected : Maybe Int
, map : Map.InternalModel
, tabl
>
> Just break it into modules so your similar functions are grouped together
> in files. Use them just like you already are.
>
The part I don't understand is: how do you create UI components that
maintain their internal state without nesting them as child components?
--
You received this
Just break it into modules so your similar functions are grouped together
in files. Use them just like you already are. We did a bit of this
here:
https://www.dailydrip.com/blog/elm-pair-programming-josh-adams-and-luke-westby-pairing-on-colluder
On Tuesday, August 23, 2016 at 11:29:31 PM UTC-
On Wed, Aug 24, 2016 at 12:30 AM, Richard Feldman <
richard.t.feld...@gmail.com> wrote:
> At work we have 36,000 LoC of production Elm. One of our most complicated
> pages has a Model with 55 fields in it, and a Msg with 40 type
> constructors, and it feels *nice to maintain*. A year ago it was a
While I understand that not breaking things up too often is sound advice in
elm, I still think this doesn't answer my question: you're basically saying
"you're doing it way too often" but you're not saying "don't do it at all" so I
do need to find a scalable way of doing it a bit. The problem I
For sure! :D
On Tue, Aug 23, 2016, 2:51 PM OvermindDL1 wrote:
> That is quite true, taking only the parts the function needs via matching
> out `{ parts, of, a, model }` is quite nice and extendable as needed. :-)
>
>
> On Tuesday, August 23, 2016 at 3:30:46 PM UTC-6, Richard Feldman wrote:
>>
That is quite true, taking only the parts the function needs via matching
out `{ parts, of, a, model }` is quite nice and extendable as needed. :-)
On Tuesday, August 23, 2016 at 3:30:46 PM UTC-6, Richard Feldman wrote:
>
>
>
> On Tuesday, August 23, 2016 at 11:43:49 AM UTC-7, OvermindDL1 wrote:
On Tuesday, August 23, 2016 at 11:43:49 AM UTC-7, OvermindDL1 wrote:
>
> On Tuesday, August 23, 2016 at 11:24:22 AM UTC-6, Richard Feldman wrote:
>>
>> You are on the road to #2, so my macro-level suggestion would be to go
>> back to #1. :)
>>
>
> #1 also ends up making utterly *huge* model and
On Tuesday, August 23, 2016 at 11:24:22 AM UTC-6, Richard Feldman wrote:
>
> You are on the road to #2, so my macro-level suggestion would be to go
> back to #1. :)
>
#1 also ends up making utterly *huge* model and message unions though, with
extremely non-reusable parts. :-)
But yes, for a ge
> I'm building an application to help ship captains create routes. My
> question is about the organization of the model of this application.
>
> The application *currently has one page* containing *three widgets*
>
Sorry to ramble on about this, but it's been a thorn in my side for a long
> ti
19 matches
Mail list logo
