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.
