Documentation (cookbook): Advanced Loading Patterns

[amplitude]

Documentation (cookbook): Advanced Loading Patterns

[ryanashcraft]

Yeah this is a caveat with using URLs as the "cache key" and not basing off entities. A problem that GraphQL clients inherently do not have.

What we sometimes do, which I think is similar to what you're describing, is check to see if we already have the entity we need from the entities reducer, and then return null or undefined for the query config, so that connectRequest doesn't make any request.

For example:

const DashboardContainer = connectRequest((props) => {
    if (dashboard) {
        return {
            url: `/api/dashboard/${props.dashboardId}`,
            update: { ... },
        };
    } else {
        // already have dashboard (perhaps from a different query/URL), do not make an unnecessary request 
        return null;
    }
});

const mapStateToProps = (state, props) => {
    const dashboard = selectors.getDashboard(props.dashboardId);

    return {
        dashboard,
    };
};

[MrNice]

Yup that code snippet embodies what I meant: mapStateToProps is the best place to answer "Do we have enough data to render?" and then send a boolean signal prop to your internal mapConfigToProps as well as the loading component.

[simenbrekken]

@ryanashcraft Trying out this approach I'm getting warnings from redux-query stating it's attempting to cancel a request that is not in-flight. This is caused by the query being nulled as soon as mapStateToProps returns the entity.

Probably not an issue at all but the warnings are slightly distracting:

query-advanced.js:281 Trying to cancel a request that is not in flight:  {"url":"https://my-api.com/pages/frontpage"}

Code:

const mapStateToProps = (state, { id }) => ({
  page: getPageById(state, id),
})

const mapPropsToQuery = ({ id, page }) => (
  !page && createPageQuery({ id }))
)

compose(
  connect(mapStateToProps),
  connectRequest(mapPropsToQuery),
)

[ryanashcraft]

@simenbrekken This should be fixed with 2.0.

Closing this issue. If someone would like to contribute more demos for the redux-query site that demonstrates these patterns, feel free to open up a PR. All I ask is that the demo is smallish and matches the style of the current demos.