>
> 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 <mreri...@gmail.com <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
> elm-discuss...@googlegroups.com <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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
