Cannot update during an existing state transition warning

[aeagle]

This is reported in the console with the current version:

'Cannot update during an existing state transition (such as within render). Render methods should be a pure function of props and state.'

Need to remove side-effects from render() method and reimplement in another React lifecycle.

[amcdnl]

Getting this as well ^^

Warning: Cannot update during an existing state transition (such as within `render`). Render methods should be a pure function of props and state.

[aeagle]

Whilst not ideal I haven't noticed any side effects apart from the warning message itself in dev.

[aeagle]

This warning has been resolved with the refactor to React Hooks in #22

[Nantris]

@aeagle this is possibly still occurring as a new error:

react-dom.development.js:546 Warning: Maximum update depth exceeded. This can happen when a component calls setState inside useEffect, but useEffect either doesn't have a dependency array, or one of the dependencies changes on every render.
    in SpaceInternal (created by Fill)
    in Fill (created by SpacesRoot)
    in div (created by SpaceInternal)
    in div (created by SpaceInternal)
    in SpaceInternal (created by Fill)
    in Fill (created by Fixed)
    in div (created by Fixed)
    in Fixed (created by SpacesRoot)
    in SpacesRoot (created by ConnectFunction)
    in ConnectFunction (created by Connect(SpacesRoot))
    in Connect(SpacesRoot) (created by MainSection)
    in div (created by ForwardRef(Box))
    in ForwardRef(Box)
    in ForwardRef(Box) (created by MainSection)
    in ErrorBoundary (created by MainSection)
    in div (created by ForwardRef(Box))
    in ForwardRef(Box)
    in ForwardRef(Box) (created by MainSection)
    in MainSection (created by ConnectFunction)
    in ConnectFunction (created by Root)
    in ErrorBoundary (created by Root)
    in div (created by HotKeysWrapper)
    in HotKeysWrapper (created by HotKeysEnabled)
    in HotKeysEnabled (created by Root)
    in div (created by Root)
    in ThemeProvider (created by Root)
    in Root (created by ConnectFunction)
    in ConnectFunction
    in Router (created by HashRouter)
    in HashRouter (created by SuperRoot)
    in Provider (created by SuperRoot)
    in SuperRoot (created by HotExportedSuperRoot)
    in AppContainer (created by HotExportedSuperRoot)
    in HotExportedSuperRoot
    in AppContainer

Only seems to happen with Space.Fixed, not with Space.ViewPort.

[aeagle]

Hi @slapbox. Thanks for reporting. Could you post the JSX you are using to produce this warning? Does the error happen straight away after first render or after a state or props change? It looks like you are using Redux at the root so any info on any props/state changes that are happening in your case would be appreciated so that I can try to repro.

[Nantris]

Hey @aeagle thanks for your reply. It's really weird, I had it working for several fresh starts of my project, but as I kept tweaking the CSS eventually it stopped working. Reverting the CSS didn't work. I eventually swapped out my intended children for simple spans, but the issue persisted.

The code is just:

      <Spaces.Fixed height="100%">
        <Spaces.LeftResizable size="25%">
          <span>Hello</span>
        </Spaces.LeftResizable>
        <Spaces.Fill>
          <span>Goodbye</span>
        </Spaces.Fill>
      </Spaces.Fixed>

I've updated the above post with the complete call stack.

We're using React Hot Loader (and gaeron's patched react-dom that's compatible with hooks) and not doing anything to trigger hot loading when this occurs. It's (weirdly) hard to be 100% certain hot loading is disabled when used with Webpack. It seems like a few places need to be updated. I haven't tried it in an environment where I'm completely certain hot loading is disabled, but as I mentioned it shouldn't be causing any issues because it shouldn't be patching anything.

As far as props/state changes nothing unusual going on and no loops that carry on for more than say 10-15 render cycles when starting up as we wait for data and try initializing again after a brief delay until we have it.,

Trying to reproduce the issue today, I've not been able to so far except by leaving the height prop off of <Fixed />. I wonder if using percentage based height perhaps isn't consistently safe? I'm not quite sure what's going on behind the scenes.

I've modified my approach to use <ViewPort /> for now so I'm hopeful I won't be seeing the issue again, but if I do I'll update the issue with any new information I uncover.

Thanks for this awesome project!

[aeagle]

@slapbox ViewPort is the way to go if you actually want it to fill the browser. I've actually only used Fixed spaces with a pixel height so there could be an issue that manifests itself when a percentage height is used. I'll try to repro.

[Nantris]

My situation is a bit weird, where we want to fill all but the top 20px. Adding a css rule to modify <ViewPort /> top: 20px seems to work without any negative effects (so far.)

[aeagle]

@slapbox It's not weird. Actually I had the use case myself. The viewport space actually has top, right, bottom and left properties to allow you to offset from the edge of the viewport. I just forgot to document it! In your case adding top={20} to the viewport space will do what you want without having to resort to using CSS.

[Nantris]

That works great!

[aeagle]

Glad that helped. It did highlight that I was not validating properties on the components for JS only consumers (non Typescript). I had typed the height property on the Fixed space as number with the intention that only pixel heights could be passed there. I've added issue #34 to add PropTypes for each component to avoid confusion in the future.