Store from Redux provider unavailable in connected react-pixi-fiber components

[nstolpe]

I'm having issues using redux connect on react-pixi-fiber components if the redux provider is not a child of the Stage component.

The following setup works for me:

// index.js
import Test from 'Test'

const appContainer = document.getElementById('app-container');

render(
    <div>
        <Test />
        <div>...</div>
    </div>,
    appContainer
);

// Test.js
import TestContainer from 'TestContainer';

const Test = props => {
    return(
        <Stage>
            <Provider store={store}>
                <TestContainer />
            </Provider>
        </Stage>
    );
}

export default Test;

// TestContainer.js

const mapStateToProps = state => ({ ...state });

const TestContainer = props => <Container />;

export default connect(mapStateToProps, null)(TestContainer);

However, if I move the Provider so that it wraps Stage

// Test.js
import TestContainer from 'TestContainer';

const Test = props => {
    return(
        
        <Provider store={store}>
            <Stage>
                <TestContainer />
            </Stage>
        </Provider>
    );
}

export default Test;

I get this error:

Uncaught Error: Could not find "store" in the context of "Connect(TestContainer)". Either wrap the root component in a <Provider>, or pass a custom React context provider to <Provider> and the corresponding React context consumer to Connect(TestContainer) in connect options.

Ideally I'd like

// index.js
import Test from 'Test'

const appContainer = document.getElementById('app-container');

render(
    <Provider store={store}>
        <div>
            <Test />
            <div>...</div>
        </div>
    <Provider>,
    appContainer
);

// Test.js
import TestContainer from 'TestContainer';

const Test = props => {
    return(
        <Stage>
            <TestContainer />
        </Stage>
    );
}

export default connect(mapStateToProps)(Test);

But it gives me the same error as above.

I can work around this by not using connect on TestContainer and instead just passing props down to it (When the redux Provider is used in index.js, the connected Test component does have access to the props from the store), but it would be simpler to use it with connect.

I came across this issue in a similar project (that references pixi-react-fiber, so may be at least partially based on it). Comments there indicate that it's a problem with context in general and not specifically redux. The empty objects here and here look like it might be something similar.

I did a little debugging, but couldn't figure anything out. If this is a solvable issue, I'd love to help out if any contributors could give me some pointers.

[michalochman]

@nstolpe thanks for the report. If you are using react-redux@6.0.0 which is using the new Context API then this is a limitation of the new Context API itself. The context is not passed across different reconcilers because of context boundaries. See this comment for more info and workarounds.

[nstolpe]

Thanks for getting back to me so quickly @michalochman. I'll give some of the workarounds in the PR comment, shoulda looked at some closed issues for more info (I'll close this too).

[michalochman]

@nstolpe these workarounds are functional, personally I use this one.

[nstolpe]

I was able to get back to this and solved the issue thanks to those links, using something like this:

const ScreenContext = createContext();

const TestContainer = props => {
    // react-pixi-fiber Container
    return (<Container name="TestContainer" position={props.testContainerPosition} />);
};

const mapStateToProps = (state, ownProps) => ({ ...state });

const ConnectedTestContainer = connect(mapStateToProps, null, null, { context: ScreenContext })(TestContainer);

const Screen = props => (
    <ReactReduxContext.Consumer>{({ store }) =>
        <Stage>
            <AppContext.Consumer>{app => (
                <Provider store={store} context={props.context}>{props.children}</Provider>
            )}</AppContext.Consumer>
        </Stage>
    }</ReactReduxContext.Consumer>
);

render(
    <Provider store={store}>
        <AppWrapper>
            <ScreenWrapper>
                <Screen context={ScreenContext}>
                    <TestContainer />
                </Screen>
            </ScreenWrapper>
            <ConnectedControls />
        </AppWrapper>
    </Provider>,
    appContainer
);

ConnectedControls are ReactDOM components that are connected to my Redux store, and
ScreenContext is used with the inner Redux provider and connected components to avoid the warning about the same context being used by multiple renderers. And all of my data from the provider inside render is available to the react-pixi-fiber components inside of Screen's stage/consumer/provider section.

Thanks again for the help.

[michalochman]

Thanks for sharing that @nstolpe!

[ygorlf]

Hi guys, I'm struggling to integrate redux in my react-pixi-fiber demo, anyone have a demo of a simple integration that I can look? Thanks!
@michalochman @nstolpe

[michalochman]

@ygorlf see the simplest example I could come up with: https://codesandbox.io/s/react-pixi-fiber-with-redux-g4k7n

[0xdevalias]

This solution is also pointed out here: michalochman/react-pixi-fiber#93.

I'll close this issue now as it is not related to this lib but to React Context API.

In case anyone else stumbles here from Google/etc, react-pixi-fibre now lists this in it's 'caveats' section of the README:

• https://github.com/michalochman/react-pixi-fiber#react-context-api-limitations

This links to the following React issue:

• Imperative wrappers can't access current context value in commit phase facebook/react#13336

Which seems to have been closed by this PR:

• Support class component static contextType attribute facebook/react#13728

Which seems to have been included in the React 16.6.0 changelog in this PR:

• Add 16.6.0 changelog facebook/react#13927

---

I haven't looked any deeper into things that that yet, but at least in theory, I would expect that the React side of this bug/issue/weirdness should be fixed now. So it may 'just work'.

Originally posted by @0xdevalias in pixijs/pixi-react#77 (comment)