Handle "asyncConnect" decorated containers that are hidden in the children components

[elodszopos]

I have a nested structure of components (containers). Each has it's own asyncConnect. The top one can hold up to N number of children. These children can come from a CMS. The schema is well defined and each maps to one of these children.

Let's say the top level one would load available categories in an API call. Then the children ( sub-categories ) can be included dynamically, and each would worry about it's own content, separately, independent of the top level container ( other than a route parameter that contains the id of the category ). Each of these children would load details for the sub-category it is responsible for.

Some pseudo code below:

<Route ... component={TopLevelContainer} />

@asyncConnect([{
  promise: ({ store: { dispatch, getState }, params: { categoryId } }) => {
    const promises = [];
    const state = getState();

    if (!categoryActions.isLoaded(state)) {
      promises.push(categoryActions.loadCategory(categoryId));
    }

    .... 
    return Promises.all(promises);
}])
export default class TopLevelContainer extends Component { ....
    someChildContext stuff ...
    ....
    render() {
        return (
            <div>
                <ChildContainer />
                <ChildContainer />
            </div>  
        );
    }

@asyncConnect([{
  promise: ({ store: { dispatch, getState }, params: { categoryId } }) => {
    const promises = [];
    const state = getState();

   // why is this code not running ? Am I forced to keep this on the parent? 

    // COMMENT BELOW
    if (!subCategoryActions.isLoaded(state, categoryId, 'someSubcategory')) {
      promises.push(subCategoryActions.loadCategory(categoryId, 'someSubcategory'));
    }

    .... 
    return Promises.all(promises);
}])
export default class ChildContainer extends Component { ....

So .. I know it's a bit of code, but I was using the repo that this was forked from in hopes that maybe this would work here. And yeah .. am I doing something wrong? Is this a feature that's implemented and support and I'm not doing something correctly? I also found this on the older repo but I'm not sure it's what I need.

Also, regarding the // COMMENT BELOW part, is it somehow possible to get the context in the async connect? Or is that a more general thing?

Any help would be greatly appreciated,
Thank you very much!

[AVVS]

Components are gathered form react-router match function, therefore redux-connect doesn’t see any nested components. All the components with asyncConnect must be defined on the router, everything else won’t work. You can nest them IN react-router as much as you want, but they must be in the router. No async dynamic bananza here.

<Route path=“/nice“ component={Top} >
   <Route path=“/nice/:id” component={Children} />
</Route>

Hope I answered your question :)

On Jul 4, 2016, at 11:13 PM, Elod-Arpad Szopos notifications@github.com wrote:

I have a nested structure of components (containers). Each has it's own asyncConnect. The top one can hold up to N number of children. These children can come from a CMS. The schema is well defined and each maps to one of these children.

Let's say the top level one would load available categories in an API call. Then the children ( sub-categories ) can be included dynamically, and each would worry about it's own content, separately, independent of the top level container ( other than a route parameter that contains the id of the category ). Each of these children would load details for the sub-category it is responsible for.

Some pseudo code below:

<Route ... component={TopLevelContainer} />

@asyncConnect([{
promise: ({ store: { dispatch, getState }, params: { categoryId } }) => {
const promises = [];
const state = getState();

if (!categoryActions.isLoaded(state)) {
  promises.push(categoryActions.loadCategory(categoryId));
}

.... 
return Promises.all(promises);

}])
export default class TopLevelContainer extends Component { ....
someChildContext stuff ...
....
render() {
return (

);
}
@asyncConnect([{
promise: ({ store: { dispatch, getState }, params: { categoryId } }) => {
const promises = [];
const state = getState();

// why is this code not running ? Am I forced to keep this on the parent?

// COMMENT BELOW
if (!subCategoryActions.isLoaded(state, categoryId, 'someSubcategory')) {
  promises.push(subCategoryActions.loadCategory(categoryId, 'someSubcategory'));
}

.... 
return Promises.all(promises);

}])
export default class ChildContainer extends Component { ....
So .. I know it's a bit of code, but I was using the repo that this was forked from https://github.com/Rezonans/redux-async-connect in hopes that maybe this would work here. And yeah .. am I doing something wrong? Is this a feature that's implemented and support and I'm not doing something correctly? I also found this on the older repo brocoders/redux-async-connect#47 but I'm not sure it's what I need.

Also, regarding the // COMMENT BELOW part, is it somehow possible to get the context in the async connect? Or is that a more general thing reduxjs/react-redux#289?

Any help would be greatly appreciated,
Thank you very much!

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub #45, or mute the thread https://github.com/notifications/unsubscribe/ABol0T9_Gvq17mlrL6GMHwnhNOTCHP4fks5qSWlogaJpZM4JEodF.

[elodszopos]

But .. but .. CMS is all about dynamic bananza :(

Thanks for the explanation @AVVS. Figured this out shortly after I wrote the post. Before you close this out: which basket should I put my eggs in? Will you be more actively sustaining the fork?

[AVVS]

I'm maintaining in, so far we really have 1 use-case thats not covered - partial load from server and then loading the rest on the client. Unless you need it in the short term - this is a good module to use.

Other good alternatives are redial and redux-saga. Though they dont have what you want as well :)

On 05 Jul 2016, at 07:53, Elod-Arpad Szopos notifications@github.com wrote:

But .. but .. CMS is all about dynamic bananza :(

Thanks for the explanation @AVVS. Figured this out shortly after I wrote the post. Before you close this out: which basket should I put my eggs in? Will you be more actively sustaining the fork?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[elodszopos]

I'm keeping my eggs over here! Keep up the good work, thank you very much for the quick assistance @AVVS

[sergesemashko]

hi @AVVS, myself and my team are actively using this module in projects and after certain experience I can say that I would love nested components support. Our team noticed that often single asyncConnect function that fetches data for entire page is getting bloated and it's hard to reuse fetched data or fetching logic. In most cases it's not possible to split asyncConnect promise functions because of data dependencies.

Redux-saga(my opinion, fairly complicated) and redial are good alternatives, but they both always require custom reducers, even for repeating simple fetches. Redux-connect takes that off from developers and just uses single reducer making data fetching easy.

I'm going to play around and prototype something like this https://github.com/ericclemmons/react-resolver/blob/master/src/resolve.js anyways, just wanted to know is it welcomed to apply that kind of update? thanks

[elodszopos]

I whole-heartedly support that idea and if you need any help or support @sergesemashko, feel free to drop a line here. Granted @AVVS also agrees.

I was on the verge of going for it myself but unfortunately I had little time as of late.

[AVVS]

@sergesemashko you actually can use multiple asyncConnect functions for any number of components, if they are nested - they will resolve in series (to support state that depends on previous state), if they are in parallel branches - they will resolve in parallel. Key part here is that all asyncConnect components are all defined on react-router and are resolved from it during match action (even if it's a dynamic resolve). Given that nesting is actually supported.

What's not supported is a component, which renders a child component and that child component is actually a container with asyncConnect attached and it was not visible anywhere before that render() call in react occurred. In that case there is no way to find that static property on the container beforehand.

Given you have all that insight on that issue now - if you have any idea how to do nesting before rendering with no state - I'd fully support it and will help implement it. However, I have no idea how to achieve that as of this moment and therefore not tackling that issue at all at this moment

[sergesemashko]

glad to hear your sign off. @AVVS, thanks, that makes things even more clearer. React-resolver does nested fetching using react context + flags and data fetching on render. 2nd option would mean breaking change to redux-connect server rendering. I'll give it a shot and ping you back when I come up with something

[AVVS]

@sergesemashko let me know once you have more insight on this :)