I 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 ("Pocket monkey: $" ++ (toString balance)) ]
Is this right?
Above is for displaying ( fetching some data from super modules), 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". at
This kind of judgment requires condition flow and that condition requires
knowledge of how much the balance is. Should I change update function to
accept some extra data just like the view function above 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 <nandi...@gmail.com
> <javascript:>> 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 <nandi...@gmail.com> 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 <nandi...@gmail.com>
>>>>> 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 elm-discuss...@googlegroups.com.
>>>>>> 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 elm-discuss...@googlegroups.com.
>>>> 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 elm-discuss...@googlegroups.com <javascript:>.
>> 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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
