>
> The problem i see with this approach is that in hierarchy of deeply nested
> components, the whole ancestry would need to know about the intention of
> the leaf.
Sort of. Each module only needs to consider it's direct child/children. So,
to use a module, you have to use it's API.
I understand your concern, from a theoretical standpoint, but having a
large complex elm spa ourselves, this just isn't an issue. Depending on how
you choose to build your application (I assume you're building an SPA), it
is very likely that *every* main architectural module (page modules) will
have a nicely developed API that allows the enclosing module (main module)
to "hook-in" to events that are happening internally to it. It's actually
very pleasant to manage once you get used to it.
For example, here is an imaginary module:
MyModule.elm
type Model =
Model {..}
type alias Config msg =
{ onClick : msg }
view : Config msg -> Model -> Html msg
view config model =
button [onClick config.onClick] [text "Submit"]
The view function allows parent modules to configure the view to return
parent messages. Here is an example of a parent hooking into the view
function
Parent.elm
type alias Model =
{ myModuleModel : MyModule.Model }
type Msg
= ChildClicked
view : Model -> Html Msg
view model =
MyModule.view myModuleConfig model.myModuleModel
myModuleConfig : MyModule.Config Msg
myModuleConfig =
{onClick -> ChildClicked}
Forgive any mistakes - I'm coding this quickly. So, that is just a tiny
example. You can do the same thing with your update functions (passing in
an update config) but the arrangement is a little different. Does that help?
On Friday, December 2, 2016 at 9:25:48 AM UTC-5, Birowsky wrote:
>
> The problem i see with this approach is that in hierarchy of deeply nested
> components, the whole ancestry would need to know about the intention of
> the leaf. I was hoping towards more of a command-like approach.
>
>
> On Dec 2, 2016, at 14:45, Erik Lott <[email protected] <javascript:>>
> wrote:
>
> Birowsky, your leaf component will need return messages to the parent, and
> the parent can act on those messages to update it's state. There's no magic
> to it unfortunately. Do you have a specific problem you're trying to solve?
>
> On Wednesday, November 30, 2016 at 12:04:08 PM UTC-5, Birowsky wrote:
>>
>> Hey Eric, please elaborate on this one. How do you envision leaf
>> component triggering global state update?
>>
>>
>>> The second problem becomes: *how do we load this global state/business
>>> data into the application and cache it?* This requirement is now fairly
>>> easy to wire-up in elm since the http requests and data cache all live at
>>> the same level of the application (the top level). If anyone wants more
>>> details on how to do this, let me know.
>>>
>>
>>
>>
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/elm-discuss/j-Wa6NGiYUM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> [email protected] <javascript:>.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
--
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.
