The `view` approach is perfect.
The `update` I see different
In the GrandChild:
type alias Need = Float
update : Msg -> Model -> (Model, Cmd Msg, Need)
update msg model =
case msg of
Spend howMuch ->
(model, Cmd.none, howMuch )
In the Parent you might have
update : Msg -> Model -> (Model, Cmd Msg, Child.Need)
update msg model =
case msg of
ChildMsg message ->
let
(newAnne, cmd, need) = Child.update message model.anne
in
({ model | anne = newAnne, Cmd.map ChildMsg cmd, need)
...
you can also have external operations that you can expose. For example, in
GrandChild you can have:
receiveFunds : Float -> Model -> (Model, Cmd Msg, Need)
receiveFunds amount = update (Receive amount)
and in Parent
moneyForKids : Float -> Model -> (Model, Cmd Msg, Child.Need)
moneyForKids amount = update (MoneyForKids amount)
you can use these functions to avoid exposing the messages.
On Tue, May 17, 2016 at 6:18 PM, Nandiin Bao <[email protected]> wrote:
> understand the importance of holding only one state for the entire
> application and actually I want my code to confirm to this principle.
>
> I've been trying to implement this Grandpa context but my brain is still
> messed up.
>
> For example, grandpa is the owner of the bank account, so definitely I can
> that Grandpa.Model has a field that holds BankAccount.Model. And now, Anne
> wants
> to show off her pocket money (displaying account balance via Html). But
> Anne doesn't have idea how much it is because only Grandpa.Model holds
> that value. I thought of something like this:
>
> module Anne exposing (view, foo, bar)
> -- some code
> view: Int -> Model -> Html Msg -- pass some extra data to view function
> view balance model =
> div
> []
> [ text ("I'm " ++ model.name)
> , text ("Pocket monkey: $" ++ (toString balance))
> ]
>
> Is this right?
>
> Above is for displaying ( fetching some data from super modules), and how
> updating should ( modifying that data) look like?
>
> update : Msg -> Model -> (Model, Cmd Msg)
> update msg model =
> case msg of
> Spend howMuch ->
> (model, Task.perform (\_ -> NoOp) (\_ -> NoOp) (Task.succeed
> howMuch) )
>
> I can come up with something like above, but don't know how super modules
> can react to this Cmd.
> Maybe I should fire the Cmd in other way, but this is the only one I can
> find in the documentation without writing custom effect manager whose
> documentation is incomplete
>
> Furthermore, if Anne knows (not owns) how much the balance is in real
> time (i.e. she will be notified when Bill spends certain amount of it or
> Father deposits some) she can make judgements like "I can/cannot afford it".
> This kind of judgment requires condition flow and that condition requires
> knowledge of how much the balance is. How can Anne know that ?
> Subscription ( I don't know where to subscribe) ? or simply change the
> update function to accept some extra data just like the view function
> does?
>
>
> 在 2016年5月17日星期二 UTC+8下午8:14:08，Peter Damoc写道：
>>
>> The context you described is actually a good context to explain how Elm
>> views things.
>>
>> Anne and Bill spend money from Grandpa BUT, they are not the owners of
>> that information.
>> What they should do is to request that money be delivered to their
>> interest (this is done through some kind of request data), expect back
>> either money or a refusal of money (insufficient funds or allowance
>> overdrawn) and react to this reply.
>>
>> If Father and Uncle are interposed between Anne/Bill and grandpa this
>> means that there is a very clear reason why this is. Maybe they are an
>> intermediary, maybe they are the ones who decide if the kids spent too
>> much. In any case, they receive the request returned by the kids' update
>> and maybe decide if they forward the request upwards to Grandpa or simply
>> inform the children that the request was denied.
>>
>> It is very very useful to have one state for the entire application
>> because when you do this, all the state update is predictable and clear.
>>
>> Think about a large number of objects interacting and each taking
>> decisions based on some logic, mutating each others' state. It gets crazy
>> and unpredictable very, very fast.
>> You end up in a context where you want change a piece of code and you
>> start to wonder if changing that piece of code won't have a crazy set of
>> side-effects in a different part of the program.
>>
>> Elm avoids this by being clear and explicit with the transformation of
>> state.
>> It makes the initial development maybe a little more slower BUT even a
>> medium size piece of code (few hundred lines of code) is enough to make you
>> realize the brilliance of this approach.
>>
>>
>>
>>
>>
>>
>> On Tue, May 17, 2016 at 11:08 AM, Nandiin Bao <[email protected]> wrote:
>>
>>> I see, and that's the reason why I'm thinking that I may have been
>>> trying to implement a non-FRP thoughts/design.
>>>
>>>
>>>
>>> Grandpa ----- Father ----- Anne
>>> |-- Uncle ------ Bill
>>>
>>>
>>> Assume that Grandpa has a bank account, and Father and Uncle works every
>>> hard to deposit money into it, while Anne and Bill can spend that money
>>> (What a nice family!)
>>>
>>> What would conform-to-Elm-philosophy modeling of this scenario?
>>>
>>> p.s. Anne and Bill can't be moved to second layer because sometimes this
>>> kind of constraints do exist in real projects.
>>>
>>> p.s.jnr Thank you Peter! You're always so patient to any questions.
>>>
>>> 在 2016年5月17日星期二 UTC+8下午1:51:07，Peter Damoc写道：
>>>>
>>>> Part of Elm philosophy is to get away from this kind of side-effects.
>>>>
>>>> Also, I don't think Elm has enough OOP infrastructure to implement what
>>>> you want here.
>>>>
>>>>
>>>> On Tue, May 17, 2016 at 5:28 AM, Nandiin Bao <[email protected]>
>>>> wrote:
>>>>
>>>>> Yes, exactly. And I want an elegant implementation.
>>>>>
>>>>> 在 2016年5月16日星期一 UTC+8下午2:04:58，Peter Damoc写道：
>>>>>>
>>>>>> Hi Nandiin,
>>>>>>
>>>>>> It is not clear for me what are you actually trying to accomplish
>>>>>> here.
>>>>>> I understand that you want the synchronization but it is not clear
>>>>>> what would a satisfying solution would be.
>>>>>>
>>>>>> I somehow think you might want side-effects where by side-effects I
>>>>>> mean have a piece of state (the shared state) that can be given to
>>>>>> sub-components and have the sub-components mutate it.
>>>>>> In other words, have a sub-component that directly changes something
>>>>>> outside of it.
>>>>>> This way, when one component mutates the global state, the change is
>>>>>> present in the other components that rely on that state.
>>>>>> Is this what you are ultimately trying to accomplish?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, May 16, 2016 at 5:37 AM, Nandiin Bao <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>> I'm struggling with "Model sharing(synchronizing) problem" posted at
>>>>>>> here
>>>>>>> <https://groups.google.com/forum/#!topic/elm-discuss/7xusVa-jR4c> and
>>>>>>> Peter raised some solution on it, but those needs either explicitly
>>>>>>> coding
>>>>>>> synchronization codes or some extra-knowledge of sub module. And then I
>>>>>>> found some posts (and replies on those posts) describing similar
>>>>>>> problems:
>>>>>>>
>>>>>>> Dealing with state duplication within the model (The Elm
>>>>>>> Architecture)
>>>>>>> <https://groups.google.com/forum/#!searchin/elm-discuss/subscription/elm-discuss/DPuz9Ky6EDs/4oGrJatyBAAJ>
>>>>>>>
>>>>>>>
>>>>>>> Communicating with a parent component to relay something happened in
>>>>>>> a sub component
>>>>>>> <https://groups.google.com/forum/#!searchin/elm-discuss/Sub/elm-discuss/3Ue4pAjL29E/jOPcnbaHCQAJ>
>>>>>>>
>>>>>>> Evan's answer on second post
>>>>>>> <https://groups.google.com/d/msg/elm-discuss/3Ue4pAjL29E/MWgdhfyYCQAJ>
>>>>>>> says
>>>>>>> that we can return extra data from sub module's update function for
>>>>>>> super module to notice something is happening. It really works for
>>>>>>> noticing
>>>>>>> super modules but the synchronization code is still needed.
>>>>>>>
>>>>>>> Finally, a thought that the original modeling (there is something
>>>>>>> that should be shared or synchronized) may run away from FRP thinking
>>>>>>> occurred to me. Is this true ? and what's the correct way of thinking ?
>>>>>>>
>>>>>>> --
>>>>>>> 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.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> There is NO FATE, we are the creators.
>>>>>> blog: http://damoc.ro/
>>>>>>
>>>>> --
>>>>> 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.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> There is NO FATE, we are the creators.
>>>> blog: http://damoc.ro/
>>>>
>>> --
>>> 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.
>>>
>>
>>
>>
>> --
>> There is NO FATE, we are the creators.
>> blog: http://damoc.ro/
>>
> --
> 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.
>
--
There is NO FATE, we are the creators.
blog: http://damoc.ro/
--
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.
