Documentation (cookbook): Advanced Loading Patterns

[MrNice]

Our app can load the same entity in two ways: by its ID, or by loading a list with that entity.

I want to avoid loading the single entity after having loaded the list view, even though redux-query will see them as different routes. Redux-query cannot know the relationships between my routes and adjust its cache strategy for them - that's fine.

My solution is simple:
I'm using mapState to determine whether or not a component has all the data it needs to render, which it then lets redux-query and the component know by attaching a loading prop.
My connect request mapPropsToConfig then only fetches if loading is true.

This reduces redundant requests, but does allow a few cases where data can still be fetched (in the case of coordinating loading many different entity types from singly typed routes, á la REST, the order the requests come back in can effect rendering during the app's bootstrapping phase).

[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.