&gt; There are all sorts of transient states that a parent&#x27;s component shouldn&#x27;t have to care about.<p>The problem with this way of thinking is that there are invariably things that you initially believe will be of no concern to the parent that later become concerns of the parent. It&#x27;s tempting at that point to graft on some event system so the parent can watch the things that it now cares about, and then maybe you add some hooks to allow the parent to preempt or change certain behaviors. This evolution requires careful thinking every time, and it&#x27;s easy to make mistakes.<p>The great thing about the elm architecture is that from the very beginning, it gives the parent all the hooks it will ever need to observe and modify the behavior of children. In the beginning, when the parent doesn&#x27;t care, it just passes the actions up and passes the model back down without having to look at them. That might feel a little bit boilerplate-y at the beginning when you don&#x27;t need it, but it&#x27;s the same everywhere, so it isn&#x27;t difficult at all. And once you&#x27;ve done this, evolution of the components requires much less thinking about architecture, and leaves much less room for mistakes.