# Modifying "parent state" from child page in an elm-spa-example-like architecture

**URL:** <https://discourse.elm-lang.org/t/modifying-parent-state-from-child-page-in-an-elm-spa-example-like-architecture/2437>\
**Category:** Learn\
**Created:** [November 3, 2018, 11:02pm UTC](https://discourse.elm-lang.org/t/modifying-parent-state-from-child-page-in-an-elm-spa-example-like-architecture/2437 "2018-11-03T23:02:21Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![glennsl](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/glennsl/32/1496_2.png) [@glennsl](https://discourse.elm-lang.org/u/glennsl)\
**Post date:** [November 3, 2018, 11:02pm UTC](https://discourse.elm-lang.org/t/modifying-parent-state-from-child-page-in-an-elm-spa-example-like-architecture/2437/1 "2018-11-03T23:02:21Z")

</div>

Like any good (or so I assume) Elmer I’ve followed the architecture of [elm-spa-example](https://github.com/rtfeldman/elm-spa-example) with separate page modules that are `Cmd`/`Html.map`ed in `Main`. I’ll assume most of you are familiar with this.

Let’s say I have a ‘LoginPage’ module with its own `Model`, `Msg`, `update` and `view`, and then `Main` looking something like this:

```
type Page
    = LoginPage
    | ...

type alias Model =
    { user : Maybe User
    , page : Page
    }

type Msg =
    = LoginMsg LoginPage.Msg
    | ...

update msg model =
    ...

view model =
    ...

```

The question essentially is: **How do I change `Main.Model.user` from `LoginPage`?**

It so happens that `elm-spa-example` also basically does this, but it does so by storing the user in `localStorage` and using flags and ports and such to get at it from the root, which I think is kinda cheaty.

An approach that does work, and that I currently use, is to expose `LoginPage.Msg(..)` and match on that in `Main.update`, but that’s a bit leaky and messy since I have to exhaustively handle it in both `update` functions.

I could pass the `LoginMsg` constructor to `LoginPage.view` and wrap all the messages manually instead of using `Cmd`/`Html.map`, which would allow me to emit `Main.Msg` from `LoginPage.view` directly, but that would cause a dependency cycle between `Main` and `LoginPage` and resolving that just causes an even bigger mess.

So what do? Is there a cheat code that doesn’t involve FFI? IDCLIP?

---

<div class="post-metadata">

**Author:** ![malaire](https://avatars.discourse-cdn.com/v4/letter/m/b782af/32.png) [@malaire](https://discourse.elm-lang.org/u/malaire)\
**Post date:** [November 4, 2018, 1:07am UTC](https://discourse.elm-lang.org/t/modifying-parent-state-from-child-page-in-an-elm-spa-example-like-architecture/2437/2 "2018-11-04T01:07:15Z")

</div>

I havn’t needed such messages yet so I don’t have personal experience about this, but I found this to be interesting: [The Translator Pattern: a model for Child-to-Parent Communication in Elm](https://medium.com/@alex.lew/the-translator-pattern-a-model-for-child-to-parent-communication-in-elm-f4bfaa1d3f98)

---

<div class="post-metadata">

**Author:** ![norpan](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/norpan/32/548_2.png) [@norpan](https://discourse.elm-lang.org/u/norpan)\
**Post date:** [November 4, 2018, 7:20am UTC](https://discourse.elm-lang.org/t/modifying-parent-state-from-child-page-in-an-elm-spa-example-like-architecture/2437/3 "2018-11-04T07:20:32Z")

</div>

A pattern we use in this situation is to pass message constructors to the child’s update function, like this:

```auto
LoginPage.update { onMsg = LoginMsg, onUserMsg = UserMsg } msg model

```

And then that `update` function returns the parent`s message type, without having to know it (since it just uses the supplied function). The type would be

```auto
update : { onMsg : Msg -> parentMsg, onUserMsg : User -> parentMsg } -> Msg -> Model -> ( Model, Cmd parentMsg )

```

Not sure what this pattern is called but it’s very nice.

---

<div class="post-metadata">

**Author:** ![pdamoc](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/pdamoc/32/36_2.png) [@pdamoc](https://discourse.elm-lang.org/u/pdamoc)\
**Post date:** [November 4, 2018, 7:40am UTC](https://discourse.elm-lang.org/t/modifying-parent-state-from-child-page-in-an-elm-spa-example-like-architecture/2437/4 "2018-11-04T07:40:35Z")

</div>

> [@glennsl](#):
>
> The question essentially is: **How do I change `Main.Model.user` from `LoginPage` ?**

`user` behaves like a global value. You have 2 options to change it: either return it updated from the page’s `update` OR return a global `Msg` that does the updating at the top level.

I tend to prefer the second approach. The pages’ `update` function looks like this:

`update : Session -> Msg -> Model -> (Model, Cmd Msg, Session.Msg)` where `session` is the name I use for the global context.

In the main `update` the message handlers look like this:

```elm
    ContactsMsg cmsg ->
        let
            ( contacts, cmd, smsg ) =
                Contacts.update session cmsg model.contacts
        in
        updateSession smsg { model | contacts = contacts } (Cmd.map ContactsMsg cmd)

```

where `updateSession` has this signature:  
`updateSession : Session.Msg -> Model -> Cmd Msg -> ( Model, Cmd Msg )`

Please note that this uses a pattern where all the models for all the pages are held in a record together with the global state but the pattern can be adapted to be used with the the way `elm-spa-example` keeps the page model.

---

<div class="post-metadata">

**Author:** ![rupert](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/rupert/32/1775_2.png) [@rupert](https://discourse.elm-lang.org/u/rupert)\
**Post date:** [November 4, 2018, 11:25am UTC](https://discourse.elm-lang.org/t/modifying-parent-state-from-child-page-in-an-elm-spa-example-like-architecture/2437/5 "2018-11-04T11:25:08Z")

</div>

Here is a complete example of how the users session can be held in a parent module, but manipulated from any child module (this is for 0.18, I am currently updating it for 0.19 - bigger job due to elm-mdl being deprecated).

> <https://github.com/the-sett/auth-elm/blob/3.0.2/example/Top.elm>

When a child module wants to change the user’s session state, it uses one of these functions in the `Auth` module to build a message for the auth module:

```
login : Credentials -> Cmd Auth.Msg
refresh : Cmd Auth.Msg
logout : Cmd Auth.Msg
unauthed : Cmd Auth.Msg

```

The child module can return the `Auth.Msg` as a so-called ‘out message’. The parent then feeds that to the `Auth` module which provides an updated session state as its out message. The new session state is then updated in the top-level `Model`.

Yes, it is quite a lot of boilerplate to do such a simple thing. However, it does give me a re-usable `Auth` package, and enforces a clean separation of concerns between the purpose of the auth module, the parent module and each child module.

Before switching to out messages, I was using ports to do child -\> parent comms behind the scenes. Also did this with native code, as the `elmq` package, which was perhaps not such a terrible idea, but could not be shared due to native code restrictions in packages. I therefore re-wrote my auth module using out messages, and I am actually happiest with that approach out of the 3 options.

local-storage may be being used to hold the session state, so that session state flows across browser tabs. A more secure way to do that is to use secure session cookies instead. That is only possible though if the API you are accessing is not cross-origin, which explains why local-storage and ‘Authorization’ headers is probably a more common way to do it.

---

<div class="post-metadata">

**Author:** ![glennsl](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/glennsl/32/1496_2.png) [@glennsl](https://discourse.elm-lang.org/u/glennsl)\
**Post date:** [November 4, 2018, 1:31pm UTC](https://discourse.elm-lang.org/t/modifying-parent-state-from-child-page-in-an-elm-spa-example-like-architecture/2437/6 "2018-11-04T13:31:50Z")

</div>

Thanks everyone for awesome ideas!

I went for out messages, which seems like the cleanest and least intrusive approach (and, in retrospect, probably the most obvious), since it’s an additional messaging mechanism that doesn’t need messing the existing one. It can easily be generalized across all Page modules, and, if needed, built out with or reuse something more complex and contained like the ´Auth´ module.

I still have one question regarding this approach though. What do you do if the child page returns a `Cmd` along with the out message, and you want to run a `Cmd` of your own. Just `Cmd.batch` them together?

Passing message constructors I think is best suited when the child should be independent of the larger app structure and be easy to reuse anywhere, as it’s very intrusive in the child but very easy on the parent.

And the translator pattern seems like out messages embedded in the existing message structure. An interesting idea that might have some benefits, but overly complex for the simple messaging needs I have right now at least.

---

<div class="post-metadata">

**Author:** ![malaire](https://avatars.discourse-cdn.com/v4/letter/m/b782af/32.png) [@malaire](https://discourse.elm-lang.org/u/malaire)\
**Post date:** [November 4, 2018, 2:27pm UTC](https://discourse.elm-lang.org/t/modifying-parent-state-from-child-page-in-an-elm-spa-example-like-architecture/2437/7 "2018-11-04T14:27:04Z")

</div>

> [@glennsl](#):
>
> And the translator pattern seems like out messages embedded in the existing message structure. An interesting idea that might have some benefits, but overly complex for the simple messaging needs I have right now at least.

The [article](https://medium.com/@alex.lew/the-translator-pattern-a-model-for-child-to-parent-communication-in-elm-f4bfaa1d3f98) I linked about translator pattern starts by shortly discussing out-messages and then concludes that:

> This is really nice, but still leaves something to be desired. It requires the child to handle messages it might not need to see, just so it can pass them on to the parent".

Example with out-messages:

1. child `view` generates html `button [onClick (Child.NewUser)] [...]`
2. parent `view` maps `Child.NewUser` to `ChildMsg Child.NewUser`
3. parent `update` passes `ChildMsg Child.NewUser` to child `update`
4. child `update` returns `OutMsg.NewUser`
5. parent `update` handles `OutMsg.NewUser`

Same with translator pattern:

1. child `view` generates html `button [onClick (Child.NewUser)] [...]`
2. parent `view` translates `Child.NewUser` to `Parent.NewUser`
3. parent `update` handles `Parent.NewUser`

In this case child `update` doesn’t need to handle `Child.NewUser` at all and so it will be simpler.

Of course as you say, translator pattern is a bit complex to set up, so it depends on use case which one is better choice overall.

---

<div class="post-metadata">

**Author:** ![glennsl](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/glennsl/32/1496_2.png) [@glennsl](https://discourse.elm-lang.org/u/glennsl)\
**Post date:** [November 4, 2018, 2:40pm UTC](https://discourse.elm-lang.org/t/modifying-parent-state-from-child-page-in-an-elm-spa-example-like-architecture/2437/8 "2018-11-04T14:40:52Z")

</div>

> The [article](https://medium.com/@alex.lew/the-translator-pattern-a-model-for-child-to-parent-communication-in-elm-f4bfaa1d3f98) I linked about translator pattern starts by shortly discussing out-messages…

Ah, yes I saw that but I didn’t really understand the complaint. I see what’s meant by your example though, but I don’t actually consider that a downside. I think it’s better to have `view` only concern itself with internal messages and have `update` deal with “outside stuff”. Partly that’s because it’s simpler (conceptually), cleaner and more contained, but it also seems more flexible (in this regard, it might not be in others). In my case I actually DO want the message to be handled in the child first, because I want it to emit a route command before sending a message to the parent. It’s not immediately clear how I’d accomplish that with the translator pattern, but I haven’t looked too deeply into it since it seemed much simpler to just use out messages.

---

<div class="post-metadata">

**Author:** ![Chadtech](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/chadtech/32/609_2.png) [@Chadtech](https://discourse.elm-lang.org/u/Chadtech)\
**Post date:** [November 4, 2018, 6:12pm UTC](https://discourse.elm-lang.org/t/modifying-parent-state-from-child-page-in-an-elm-spa-example-like-architecture/2437/9 "2018-11-04T18:12:46Z")

</div>

I think the `OutMsg` approach works pretty well, but what Ive been trying out lately is the way Richard does it in the spa-example, which is somewhat demonstrated on this line of code (the user is inside `session`) [https://github.com/rtfeldman/elm-spa-example/blob/master/src/Main.elm#L125](https://github.com/rtfeldman/elm-spa-example/blob/master/src/Main.elm#L125)

Basically, **dont put the user in the main model to begin with**. Have it so that each page stores the `User` in its own way. Then when you move from page to page, pull the `User` out of one page, and stick it in the next page.

---

<div class="post-metadata">

**Author:** ![glennsl](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/glennsl/32/1496_2.png) [@glennsl](https://discourse.elm-lang.org/u/glennsl)\
**Post date:** [November 4, 2018, 7:30pm UTC](https://discourse.elm-lang.org/t/modifying-parent-state-from-child-page-in-an-elm-spa-example-like-architecture/2437/10 "2018-11-04T19:30:39Z")

</div>

Interesting approach, but I don’t really see the benefit. Perhaps if it’s a shared piece of data that’s manipulated across many pages, like if you have a login modal on each page, but otherwise it mostly just seems like a lot of plumbing. Could you elaborate on why you chose it?

I’m surprised there’s so many different approaches to this, that they’re all cool and interesting in their own way, and not one of them involves dirty hacks like I feared they would.

---

<div class="post-metadata">

**Author:** ![Juan\_Gabriel\_Fraire](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/juan_gabriel_fraire/32/1503_2.png) [@Juan\_Gabriel\_Fraire](https://discourse.elm-lang.org/u/Juan_Gabriel_Fraire)\
**Post date:** [November 5, 2018, 11:58pm UTC](https://discourse.elm-lang.org/t/modifying-parent-state-from-child-page-in-an-elm-spa-example-like-architecture/2437/11 "2018-11-05T23:58:57Z")

</div>

I think the concept is similar to the `encoders`, `decoders`. So you have a `Session record`, then you `encode` the `Session` in your first page `Login record`, then you get an updated `Session` from that page and you start again the process with the next one.

An issue that I find with `OutMsg`, is that more than one `child level` or `nesting` makes the intermediate modules handle the messages between their parent and child, and with the time I also end with message wrappers that are too long for the debugger tool like `UserMsg ProfileMsg FormMsg ImputMsg "some input text"`.

---

<div class="post-metadata">

**Author:** ![Chadtech](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/chadtech/32/609_2.png) [@Chadtech](https://discourse.elm-lang.org/u/Chadtech)\
**Post date:** [November 8, 2018, 11:59am UTC](https://discourse.elm-lang.org/t/modifying-parent-state-from-child-page-in-an-elm-spa-example-like-architecture/2437/12 "2018-11-08T11:59:59Z")

</div>

> Could you elaborate on why you chose it?

I guess the end-of-the-day reason is because applications need stuff like `User` functionality. But you already knew that and all these approaches serve that purpose. So its a matter of efficiency, which I think about as “what do I have to type, maintain, and think about in these different approaches”.

The `OutMsg` approach has…  
0 An `OutMsg` type  
1 An `OutMsg` in every case of the update, which is often nothing  
2 A function for handling the `OutMsg` in the parent scope, for every page.

So at the very least with the `session` approach, you _dont_ have any of that. To me, thats plumbing, and its gone.

But do you have new plumbing in the `session` approach, what is it?  
0 Every page `Model` contains the field `session : Session`  
1 Every page `init` function probably needs the signature `Session -> Model`  
2 You need one function `toSession : Model -> Session` for your main model.

I think if you just add up the lines of code for each of these approaches, the session approach is much smaller. But, LOC isnt everything. Conceptually we lose the messy and complicated process of parent-child communication with the session approach. Losing a big messy concept from our mental space is great. I dont see the session approach adopting any new complicated things as a trade off.

---

<div class="post-metadata">

**Author:** ![glennsl](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/glennsl/32/1496_2.png) [@glennsl](https://discourse.elm-lang.org/u/glennsl)\
**Post date:** [November 8, 2018, 5:30pm UTC](https://discourse.elm-lang.org/t/modifying-parent-state-from-child-page-in-an-elm-spa-example-like-architecture/2437/13 "2018-11-08T17:30:01Z")

</div>

> [@Chadtech](#):
>
> The `OutMsg` approach has…  
> 0 An `OutMsg` type  
> 1 An `OutMsg` in every case of the update, which is often nothing  
> 2 A function for handling the `OutMsg` in the parent scope, for every page.

You don’t need to handle `OutMsg´ for every page, just those that use it. Which in my case was just one.

> [@Chadtech](#):
>
> But do you have new plumbing in the `session` approach, what is it?  
> 0 Every page `Model` contains the field `session : Session`  
> 1 Every page `init` function probably needs the signature `Session -> Model`  
> 2 You need one function `toSession : Model -> Session` for your main model.

0 and 1 were already in place, so that actually wouldn’t be extra plumbing in my case. I was thinking you’d also need a `toSession` function for each page’s `Model`, like elm-spa-example does, but I suppose you don’t if by convention you expose it as an alias to a record with a `session` field. I think the case for this is looking better.

I now need to initiate the rendering of modals/popup menus at root level from each page and am considering which approach to use. I already have `OutMsg` in place of course, but I don’t want modals and popups to persist between pages, so it would be better if each page owned this data instead of the main model. Looks like it might be time to convert then!

---

<div class="post-metadata">

**Author:** ![roovo](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/roovo/32/49_2.png) [@roovo](https://discourse.elm-lang.org/u/roovo)\
**Post date:** [November 8, 2018, 6:10pm UTC](https://discourse.elm-lang.org/t/modifying-parent-state-from-child-page-in-an-elm-spa-example-like-architecture/2437/14 "2018-11-08T18:10:55Z")

</div>

I’ve recently converted an app to the “session based” 0.19 elm-spa approach and it is just so much nicer to work with that the 0.18 version. I do have modals in my app and I’ve approached these by adding them to the page view functions so they have a type signature of:

```elm
view : Model -> { title : String, content : Html Msg, modal : Maybe (Html Msg) }

```

This seems to work pretty well for me so far.

---

<div class="post-metadata">

**Author:** ![Sebastian](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/sebastian/32/98_2.png) [@Sebastian](https://discourse.elm-lang.org/u/Sebastian)\
**Post date:** [November 9, 2018, 4:18am UTC](https://discourse.elm-lang.org/t/modifying-parent-state-from-child-page-in-an-elm-spa-example-like-architecture/2437/15 "2018-11-09T04:18:01Z")

</div>

We use the outer message approach. Is simple to understand and works really well.

But we return a list, not one. When there is nothing to do we return `[]`.

When calling nested updates we end up with a bunch of messages to process e.g. update the user, show a notification. Every update along the way can add to this list, very similar to `Cmd.batch`.

---

<div class="post-metadata">

**Author:** ![glennsl](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/glennsl/32/1496_2.png) [@glennsl](https://discourse.elm-lang.org/u/glennsl)\
**Post date:** [November 10, 2018, 4:53pm UTC](https://discourse.elm-lang.org/t/modifying-parent-state-from-child-page-in-an-elm-spa-example-like-architecture/2437/16 "2018-11-10T16:53:32Z")

</div>

> [@roovo](#):
>
> I’ve approached these by adding them to the page view functions so they have a type signature of:
> 
> ```auto
> view : Model -> { title : String, content : Html Msg, modal : Maybe (Html Msg) }
> 
> ```

Yes, this is what I’m doing now as well. Passing `Html` in the model doesn’t work well if you need it to actually change with the model as well. The problem (or rather annoyance) I have with this approach is that you either have to thread the modal through quite a few view functions and/or move the code far from where it belongs. And in my case the “modals” are actually dropdown menus that have trigger buttons which change depending on what you do with the dropdown, exacerbating the problem.

---

<div class="post-metadata">

**Author:** ![MarkHamburg](https://avatars.discourse-cdn.com/v4/letter/m/cdc98d/32.png) [@MarkHamburg](https://discourse.elm-lang.org/u/MarkHamburg)\
**Post date:** [November 18, 2018, 5:36pm UTC](https://discourse.elm-lang.org/t/modifying-parent-state-from-child-page-in-an-elm-spa-example-like-architecture/2437/17 "2018-11-18T17:36:57Z")

</div>

Putting the shared state in the pages and just handing it off when creating a new page works nicely to avoid the parent data problem but introduces the potential issue that there is nothing in the data structure to express that we only have one user at a time except to the extent that we only allow one page at a time. What if things evolved in a way where we didn’t want to show only one page — e.g., what used to be a separate page turns into a panel that opens on the side? If correctness depends on there only being one logged in user, then the make-illegal-states-impossible philosophy says you should store the user somewhere where it is forced to be unique. On the other hand, if things would be functionally correct but maybe a bit weird with user values that were out of sync, then pushing it down into the pages — particularly as a non-editable value — is a good way to reduce plumbing.

We use out messages in a way where they subsume commands. Update functions return a list of out messages and one of the standard cases for an out message is “send this command”. The code that would just map commands to add addressing instead maps over the list of out messages coming from the child applying changes to the parent and/or accumulating parent out messages for the next level. It’s more wordy than the normal Elm command architecture but it fits essentially the same pattern which is nice. The general notion is that out messages and commands are the same thing from the child’s perspective: a request for something to happen that is beyond the child’s ability to perform itself.

We used to use out messages for state queries as well — thinking of them as being much like HTTP queries — but this resulted in more convoluted control flow than was ideal with requests going from child to parent and then back to the child. So, we now handle ancestral state either by passing it down to functions like `view` and `subscriptions` which have no power to modify state anyway and broadcasting it to descendants when it changes for those cases where children want to respond in their own state to changes in ancestral state. I’m less thrilled about the latter and am looking at ways to eliminate it but the data structures and algorithms often get more complicated in the absence of the ability to react to parental state changes. But that’s its own topic.

Mark

---

<div class="post-metadata">

**Author:** ![kyasu1](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/kyasu1/32/126_2.png) [@kyasu1](https://discourse.elm-lang.org/u/kyasu1)\
**Post date:** [November 25, 2018, 9:05am UTC](https://discourse.elm-lang.org/t/modifying-parent-state-from-child-page-in-an-elm-spa-example-like-architecture/2437/18 "2018-11-25T09:05:13Z")

</div>

I have been thinking about this pattern and I realized that I needed to convert `parentMsg` to `Cmd parentMsg` by a function like this,

```auto
send : msg -> Cmd msg
send msg =
  Task.succeed msg
  |> Task.perform identity

```

which was taken from the [medium article](https://medium.com/elm-shorts/how-to-turn-a-msg-into-a-cmd-msg-in-elm-5dd095175d84). But in there, the author did not recommended it though.

Just putting an user information to a parent model on success login, so no noticeable performance penalty for my case. Maybe there might be a race condition issue since I am changing url at the same time. I need to test more at this point, otherwise looks like this solution is pretty clean for me.

Could you let us know if you are doing this something different way ?

---

<div class="post-metadata">

**Author:** ![norpan](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/norpan/32/548_2.png) [@norpan](https://discourse.elm-lang.org/u/norpan)\
**Post date:** [November 25, 2018, 9:20am UTC](https://discourse.elm-lang.org/t/modifying-parent-state-from-child-page-in-an-elm-spa-example-like-architecture/2437/19 "2018-11-25T09:20:18Z")

</div>

> [@kyasu1](#):
>
> I have been thinking about this pattern and I realized that I needed to convert `parentMsg` to `Cmd parentMsg`

Yes, this is one drawback of this solution. If you see it as a drawback.

Another way to look at it is to see it as a complete separation of the components. Since the back communication is only through messages, you have tracability of that communication, which would otherwise get lost in the update function.

Perhaps you can explain what you mean by this being a race condition. Which command is the race with?

---

<div class="post-metadata">

**Author:** ![kyasu1](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/kyasu1/32/126_2.png) [@kyasu1](https://discourse.elm-lang.org/u/kyasu1)\
**Post date:** [November 25, 2018, 2:56pm UTC](https://discourse.elm-lang.org/t/modifying-parent-state-from-child-page-in-an-elm-spa-example-like-architecture/2437/20 "2018-11-25T14:56:10Z")

</div>

I was talking about the race condition just referring the mentioned article. By inspecting my application again, I realized I could change url to a new page after receiving `parentMsg` in the parent `update` function, so no such problem happen.  
Thank you for clarifying.

[Next page](https://discourse.elm-lang.org/t/modifying-parent-state-from-child-page-in-an-elm-spa-example-like-architecture/2437.md?page=2)