Yikes, this is a frightening thread to read. I hope this response isn't too late!
I feel it will be too messy to keep all this inter-triplet logic here. Is > there a better way? Maybe something similar to pub/sub or I'm > fundamentally wrong here? Well, yes, this approach is fundamentally wrong—but please don't feel bad! This is such a common beginner mistake that Evan wrote an entire section of the official guide <https://guide.elm-lang.org/reuse/> to try and prevent this from happening. :) I know that Elm doesn't have the concept of components but *instead it has > triplets*. They should behave *similar to components*, they encapsulate > internal implementations. I use this concept in my App and I faced some > architectural questions. > Emphasis mine. Here's what the official guide <https://guide.elm-lang.org/reuse/> has to say about this: If you are coming from JavaScript, you are probably wondering “where are my reusable components?” and “how do I do parent-child communication between them?” A great deal of time and effort is spent on these questions in JavaScript, but it just works different in Elm. We do not think in terms of reusable components. Instead, we focus on reusable *functions*. It is a functional language after all! Put another way, *Elm does not have anything similar to components!* It's not about the word, it's about the concept. *Thinking in terms of "triplets" will lead to worse code!* What is the proper or better way to communicate between triplets *without > breaking encapsulation*? > Emphasis mine again. The question presumes that breaking encapsulation is a bad idea, which implies that encapsulating state is a *good* idea. The answer to this question is: *In Elm, by default encapsulating state is a cost, not a benefit.* State encapsulation is super common in object-oriented languages where state is mutable. When we can't easily grant read access to some part of our state without granting write access as well, encapsulating mutable state lets us share code safely. However, since everything is immutable in Elm, code is safe to share by default—meaning *state encapsulation has no benefit here*. It's just creating more work for us! The pursuit of state encapsulation leads us to think in terms of "parent-child communication" when we could be thinking in terms of simple function calls instead. If we adjust our default thinking from "state encapsulation is a benefit" to the correct "state encapsulation is a cost," it completely reframes how we approach these situations. The wording in the official guide <https://guide.elm-lang.org/reuse/> was chosen very deliberately: *“how do I do parent-child communication between them?” A great deal of time and effort is spent on these questions in JavaScript, but it just works different in Elm. * If we are asking about how to do "parent-child communication" (again—between "triplets" or "components" or "widgets" or whatever term you choose), we are heading down the wrong road! The answer is not "here is how to do this in Elm," the answer is "we should not do this in Elm." :) Okay, so what should we do instead? For example, let say I have two "widgets", UserInfo and Ratings. > In main "update" function I have this > > I have a button "Login" in the UserInfo widget. It will call backend API > and return the user state. > Then I want to load and update the Rating widget. > How and where do this? > Let's take a step back. I'd like to know more. 1. Where does this Login button get reused in the application? Is it always in the same place in the header? Is it scattered throughout every page? 2. Is this a single-page application with multiple routes? These questions matter to figuring out how best to make it reusable. :) -- 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.
