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.
