rendering child when parent removed from view (react-native, but not RNW)

[skins-app]

After I ported my react-native-web app to react-native, child components continue to render one last time after the parent removes it.

I'm providing state via context similar to one of your examples:

import React, { createContext, useContext } from 'react'
import { AppRegistry } from 'react-native'
import { proxy, useSnapshot } from 'valtio'



// context

const MyContext = createContext()

const MyProvider = ({ state, children }) => {
  return <MyContext.Provider value={state}>{children}</MyContext.Provider>
}



// index.js

const state = proxy({ user: { firstName: 'Sam' } }) // in my case, proxy must be created outside of render tree

AppRegistry.registerComponent(appName, () => () => {
  return (
    <MyProvider state={state}>
      <Parent />
    </MyProvider>
  )
})



// component tree

const Parent = () => {
  const state = useContext(MyContext)
  const snap = useSnapshot(state)

  console.log('RENDER PARENT')

  if (!snap.user) return null

  return (
    <>
      <Child />
      <Button onClick={() => state.user = null}>logout</Button>
    </>
  )
}



const Child = () => {
  const state = useContext(MyContext)
  const snap = useSnapshot(state)

  console.log('RENDER CHILD')

  return <>{snap.user.firstName}</> // ERROR! -- cannot read property 'firstName" of undefined
}

The logs are in this order on native:

• RENDER CHILD
• RENDER PARENT

But on web, it correctly just renders the parent:

• RENDER PARENT

So the valtio subscription is reaching the child first essentially, but only on React Native.

Is there something I can do to control the order of subscription notification?

I've designed my app so parent components short-circuit rendering when a given state is no longer available, so children don't have to do snap.user?.foo.

They can just do snap.user.foo and always assume they have a user object if they rendered in the first place.

Any options?

ps. it seems like the classic "zombie" component issue from redux.

[dai-shi]

ps. it seems like the classic "zombie" component issue from redux.

In that case, React 18 automatic batching solves it in RNW, so I guess RN doesn't use React 18 yet?

[dai-shi]

Can you try

  console.log('RENDER CHILD')
  useEffect(() => {
    console.log('COMMIT CHILD')
  })

and see if it's only the issue with 'RENDER' and not 'COMMIT'?

[skins-app]

CONFIRMED: it's only an issue with RENDER. COMMIT did not occur.

I saw there was some other issue a while ago regarding complex game computations that could fail in intermediate renders, but eventually commit correctly. It seems similar to that issue.

[dai-shi]

Thanks, so in practice, it's not a big issue. (unless your use case really suffers from zombie children, which is somehow worked around)

I'm curious how RNW and RN differ, though.

[skins-app]

It crashes (at least during development):

Does react for web catch and ignore these errors?

[dai-shi]

unless your use case really suffers from zombie children

So, you case does..

[skins-app]

react-native 0.70.2 uses 18.1.0.

Is it possible that it still needs to be enabled somewhere?

[dai-shi]

Hmmm, okay, so my assumption was incorrect. The issue is not (or not only) caused by automatic batching.

[skins-app]

I'm confirming concurrent mode is in fact running -- is there something I can log from javascript to confirm? (or was that the render/commit thing you had me do)??

According to the RN docs, it should be running:

https://reactnative.dev/docs/react-18-and-react-native#opt-ing-out-of-react-18-on-ios

But I have a feeling it still isn't.

[skins-app]

Well, it turns out it's not enabled. And I gotta do this:

https://reactnative.dev/docs/new-architecture-app-renderer-ios

I thought the latest versions of RN were doing this all automatically.

I'll let you know if it works. I bet it does!

[skins-app]

IT WORKED!

put this in your Podfile:

:fabric_enabled => true,

Then update your pods with the following flag (run from the root of your RN project)

cd ios
RCT_NEW_ARCH_ENABLED=1 pod install

[dai-shi]

🎉