[Bug] mobx-react 9.x has some another BC? Help please.

[MirKml]

Hello, I try to upgrade from mobx-react 7.6 to latest 9.x but hit the problem. I read your changelog, but I think this one is different then props, state observation.

Our app is huge with many stores and components, I'm still trying to find the root of problem and then make a minimal example but it's complicated to find the root of problem. Please help me. What I found yet

setup before upgrade: react 17.0.2, mobx 6.10.0 mobx-react 7.6.0
after upgrade: react 17.0.2, mobx 6.10.0 mobx-react 9.0.0.

This is component/store simple setup - tab component which observers one store changes and Grid child component with another store. This grid call store for tab component in componentDidMount. Injection store isn't important, it works fine.

@observer
class Tab extends Component {
    store: StoreTab

    render() {
        console.log("tab render");
        return (
            <>
            <div>{this.store.loading.toString()}</div>
            <div>{this.store.mapItems.length}</div>
            <button onClick={() => this.store.setMapItems([0,1,2])}>Test</button>
            <Grid /> // important, see later
            </>
      )}
}

StoreTab {
    mapItems = [];
    loading = false;

    constructor() {
        makeAutoObservable(this);
    }

    // async action, modify/clean mapItems
    async setMapItems(ids) {
        await something();
        runInAction(() => this.mapItems= ....);
    }
}

@observer
class Grid extends Component {
   store: StoreGrid
    
   componentDidMount() {
     this.store.clean(); // action
   }
   
}

StoreGrid {
     storeTab
    
    constructor() {
        makeAutoObservable(this);
    }

    clean() {
       // clears the storeTab mapItems,  it calls without await
       console.log("clearing map items")
       storeTab.setMapItems([]);
    }
}

When app starts with mobx-react 7.6 it writes to the console

tab render
clearing map items
tab render

yes it render parent component twice, then after each button hit it re-renders tab and works fine

After upgrade to mobx-react@9 it renders only first time and nothing more, no reaction for button hit

tab render
clearing map items

I discovered that problem is with Grid component and its componentDidMount, which changes array in parent store. When I comment it out, it works with mobx-react@9 - when i hit button, tab re-rerender.

Can you help me to find what was changes in latest mobx-react, that it breaks such common component, stores usage? Is there another breaking change in mobx-react 9?

[mweststrate]

Clearing in a didmount sounds potentially dangerous, might want to check if that surely happens only once, or do it async? That sounds like something that could potentially cause render loop?

…

On Sat, 22 Jul 2023, 18:21 MirKml, ***@***.***> wrote: Hello, I try to upgrade from mobx-react 7.6 to latest 9.x but hit the problem. I read your changelog, but I think this one is different then props, state observation. Our app is huge with many stores and components, I'm still trying to find the root of problem and then make a minimal example but it's complicated to find the root of problem. Please help me. What I found yet setup before upgrade: react 17.0.2, mobx 6.10.0 mobx-react 7.6.0 after upgrade: react 17.0.2, mobx 6.10.0 mobx-react *9.0.0*. This is component/store simple setup - tab component which observers one store changes and non related Grid child component. Injection store isn't important, it works fine. @observerclass Tab extends Component { store: StoreClass render() { console.log("tab render"); return ( <> <div>{this.store.loading.toString()}</div> <div>{this.store.mapItems.length}</div> <button onClick={() => this.store.setMapItems([0,1,2])}>Test</button> <Grid /> // important, see later </> )}} StoreClass { mapItems = []; loading = false; constructor() { makeAutoObservable(this); } // async action, modify mapItems async setMapItems(ids) { }} When I hit the button, Tab component re-renders fine - before mobx-react upgrade. *But after upgrade to ***@***.*** nothing happened*. I discovered that problem is with Grid component. When I delete Grid component from Tab, it magically works with ***@***.*** But Grid component use completely different stores. How it's possible and why it works before upgrade? So I dig into Grid component and found that problem is with its *componentDidMount*. It looks like this @observerclass Grid extends Component { store2 store3 componentDidMount() { this.store2.clean(); // action this.store3.clean(); // action }}```When I delete Grid.componentDidMount- calls unrelated stores then store used in Tab - Tab re-renders fine when its store changes. Can you help me to find what was changes in latest mobx-react, that it breaks such common component, stores usage? Is there another breaking change in mobx-react 9? — Reply to this email directly, view it on GitHub <#3730>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN4NBHRQRP3BMLWMCY7N5TXRP4YVANCNFSM6AAAAAA2T5RG6E> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[MirKml]

I will try to find what really stores in componentDidMount do next week, keep issue open please.

But even if it something like you mentioned, can you explain me a little how it is possible that it works fine with [email protected] and doesn't with mobx-react@9? I thought that 9.x changes are related to latest React strict mode, breaks observables for props, state, context. Does 9.x something new with render loop detection, loop breaking?

I ask for better searching cause for potentially another places, situations, when our another mobx applications stop working after upgrade.

Clearing in a didmount sounds potentially dangerous, might want to check if that surely happens only once, or do it async? That sounds like something that could potentially cause render loop?

[mweststrate]

It uses a different underlying primitive from React itself, the externalStoreSync thing (sorry AFK, forgot the actual name)

…

On Sat, 22 Jul 2023, 20:44 MirKml, ***@***.***> wrote: I will try to find what really stores in *componentDidMount* do next week, keep issue open please. But even if it something like you mentioned, can you explain me a little how it is possible that it works fine with ***@***.*** and doesn't with ***@***.***? I thought that 9.x changes are related to latest React strict mode, breaks observables for props, state, context. Does 9.x something new with render loop detection, loop breaking? I ask for better searching cause for potentially another places, situations, when our another mobx applications stop working after upgrade. Clearing in a didmount sounds potentially dangerous, might want to check if that surely happens only once, or do it async? That sounds like something that could potentially cause render loop? — Reply to this email directly, view it on GitHub <#3730 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN4NBCGEVVQ6VEU36KWTOTXRQNRVANCNFSM6AAAAAA2T5RG6E> . You are receiving this because you commented.Message ID: ***@***.***>

[MirKml]

Hm, I discovered what componentDidMount of child does.
It clears the observable array for parent (tab) component store. I changed the first comment, look at it please. There is now better explanation and console.log outputs that explains the behavior before and after upgrade.
Before - it renders parent twice at start and then react for each button hit. After upgrade renders only once and doesn't react - it's broken.

I think that something new breaks the old behaviour. I can prepare some real example next week, but I think it's clear now. What do you mean it's bug?

[urugator]

We don't react to changes unil the component is mounted. This is to prevent warnings about calling forceUpdate on components that were abandoned (IIRC). So the problem is that parent's componentDidMount is called after child's componentDidMount, so the changes are ignored. I think you can consider it a bug. I am writing a test to verify this atm.

[urugator]

Fix ready #3731

[MirKml]

Thank you guys for such a quick bug review and responses during a weekend.