Component render previous value

[qetr1ck-op]

Preconditions:

• component A as a page for react-router
• component B as a page for react-router
• observable object state which is used in A and B

The use case:

0. Initial state { value: 0 }
1. Initial URI - /a
2. React-router renders the component A. It renders { value: 0 }.
3. Redirect to /b
4. Component A has a cleanup hook where the state was updated to { value: 1 }
5. React-router renders the component B. It renders { value:1 }

Problem:

In .5 component B renders an old state { value: 0 } (before cleanup in component A).
After it reacts for changes for second rerender it has a new state { value:1 }.

Demo

https://codesandbox.io/s/adoring-fog-dsvew?file=/src/App.js

I bet either I'm doing smth wrong or I don't understand how it's possible to clean/reset global stores/states.
I'd appreciate any feedback.

[danielkcz]

I would advise you against a global store in such a case. Instead of resetting just create a new one when appropriate and pass down through props.

[qetr1ck-op]

Thanks for response!

IMO it's not always an option. Even though, re-creating a new instance still won't work. A silly example:

useEffect(() => {
    return () => {
      state = observable({ value: "from home" }); // the same behaviour 
    };
  }, []);

To solve this I create a dummy hook to somehow patch the router:

export function usePageCleanup(cleanupFn: () => void) {
  const history = useHistory();

  useEffect(() => {
    const historyListener = history.listen(() => {
      cleanupFn();
    });

    return () => {
      historyListener();
    };
  }, []);
}

I assume it runs before than traditional useEffect.cleanup and as result, the new rendered component received an updated state.

[urugator]

The react mounts/unmounts component if the rendered tree differs ... logically you first have to return new tree (render page B), so it can diff it with previous one. Then it finds out the component A was replaced by component B and runs cleanup for A.
In other words until you render B, it doesn't know it has to unmount and cleanup A.

I am not familiar with react router so I won't tell you how to do that, but you either have to

1. reset the state during navigation event (this is ideal because therer will be only single render)
2. reset the state on mount of a new page

// must be layout effect
useLayoutEffect(() => {
  resetState()  
}, [])

// The first render will see the old state
// so you may want to render it conditionally
if (isStillOldState) return null; // don't worry this won't ever be flushed to screen

But why do you need to reset the state? Why don't you simply have 2 local states?
If you want to reset only part of the state, then split it into two - local and shared (move the shared one up before router).

[qetr1ck-op]

@urugator thank you for your response!

First the questions:

But why do you need to reset the state? Why don't you simply have 2 local states?

For historical and convenient reasons, I guess. Let's see almost every from the mid-size app has something which we've named as "global state". Auth, UI, etc. states. Redux/Mobx/MST solve it with either one "global state" or "root store". And there is a high probability of changing the slice of it and render the updated version.

If you want to reset only part of the state, then split it into two - local and shared (move the shared one up before router).

The single responsibility principle works here, and in IMO it should be a clear separation of concern as you've mentioned.
"Moving up before router" isn't clear for me. Could you elaborate on it a bit?

About:

I am not familiar with react-router so I won't tell you how to do that, but you either have to

The approach listening to events and patch the behavior is valid. But is ridiculous, because you need to match the routing path.
Btw, with react-router (the most popular react-router alternative) the behavior is the same.

In other words until you render B, it doesn't know it has to unmount and cleanup A.

The same mental model was in my had as well. So I've tried a bit silly approach - wait when the component is mounted and only after doing a presentation logic.

export function useIsMounted() {
  const isMounted = useRef(false);

  useEffect(() => {
    isMounted.current = true;

    return () => {
      isMounted.current = false;
    };
  }, []);

  return isMounted;
}

The working example - https://codesandbox.io/s/laughing-yonath-ico78?file=/src/App.js
What your guys thoughts about it?

[urugator]

The approach listening to events and patch

I didn't mean attaching an event listener, but intercepting the function that does the navigation.
It may not be possible with react-router I dunno ... the idea is that the lib would let you define own navigate function like:

function navigate(router, page) {
  // reset state or whatever
  resetState(page)
  // actually navigate
  router.navigate(page)
}

"Moving up before router" isn't clear for me.

I mean https://reactjs.org/docs/lifting-state-up.html
If multiple components share some state, the state simply must be lifted up ... in your case the state shared by pages would be defined in an ancestor of router component, while page related state would stay inside individual page components.

If you want to keep page related state inside a global state I suggest doing it like this:

const globalState = {
  // this could be an array, but we want the lookup by id be fast and simple
  pages: {    
    home: {
      id: 'home',
      title: 'Home',
    },
    products: {
      id: 'products',
      title: 'Products', 
    },
  },
}
// action
setFoo(pageId, foo) {
  globalState[pageId].foo = foo;  
}
// in render
const pageState = globalState[router.currentPageId];

Do not place all state that is needed inside a page on globalState.pages[currentPage] object.
Eg if each page has some "tabs", use the same approach:

const globalState = {
   pages: {    
    home: {
      id: 'home',
      title: 'Home',
      // A page will refer to tabs by id
      tabs: ['home-description', 'home-images'],
    },
    /* ... */
  },
  tabs: {
    // The id is just for illustration
    // The idea is NOT to make tabId derivable from pageId
    // A page refers to tab by id explicitely as seen above
    'home-description': {/* ... */},
    'home-images': {/* ... */},
    'products-prizes': {/* ... */}
  },
}

The idea is that for each unique (and reusable) state shape, you have a collection (pages,tabs) in global state - exactly like tables in sql db. It may seem a bit inconvinient/redundant, but it scales very well and avoids all sorts of problems.

[qetr1ck-op]

I didn't mean attaching an event listener but intercepting the function that does the navigation

Still, we're trying to fix the consequences nor the problem.
IMO intercept the navigation doesn't scale at all.
Don't think narrowly about "resetting the state" in a nutshell it's all about "changing the state" in a concrete lifecycle hook of the component. And don't blame about telling of lifecycle hooks in the functional component.

If you want to keep page related state inside a global state I suggest doing it like this...

There're plant techniques on how we can deal with "GlobalState". AST and RootState, Mobx and RootStore pattern is one of them in the world of mobx. There's a clear separation of domain entities.
Normalization the state doesn't solve anything in my particular case.

There is an interesting release note from React team about react@17. The direct statement:

However, when a component is unmounting, effect cleanup functions used to run synchronously (similar to componentWillUnmount being synchronous in classes) ...

Which is exactly what I was expected, but as turned out it works differently with a combination of routers.

[urugator]

fix the consequences nor the problem
it's all about "changing the state" in a concrete lifecycle hook of the component.

But changing the state as a side effect of render is the problem. It's an antipattern as it breaks one way data flow. The react wants you to avoid this by lifting state up.
Otherwise you're creating loops in state propagation that are hard to follow, predict and deoptimize the redering - as you need multiple render passes until the state (hopefully) settles down.

intercept the navigation doesn't scale at all.

All I can tell is that whenever I need to synchronize multiple "states" (if I can't merge them together), I find it more robust and maintainable if I do it inside a single action, rather than doing it ad hoc in effects or reactions.
So in your case if I would need to synchronize router with other domain object, I would like to have a single navigate function somewhere, that handles everything about the navigation - invoking the router.navigate, resetting some state, etc.

There is an interesting release note

I don't think it has anything to do with this ... It doesn't matter whether the clean up runs synchronously or not it always runs after the new component is rendered. It's just that the cleanup function doesn't block the browser from repainting.

[qetr1ck-op]

The react wants you to avoid this by lifting state up...

I'm glad for the react =) That's why a prop drilling is an antipattern that appeared. And why state management frameworks exist to solve the lifting state problem and decompose data sharing.

I would like to have a single navigate function somewhere, that handles everything about the navigation - invoking the router.navigate, resetting some state, etc.

It was my initial thought. But I'm not in favor of it because we're mixing responsibilities. Navigation should know nothing about state and vise-verse. Moreover, imagine navigation with 10th navigation items and we need to conditionally do something with the state before making actual navigation. Instead of a particular component when it should be destroyed.

[mweststrate]

Moving to discussions