Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Josh Levinson
    @joshlevinson
    I think your saga idea might just work
    Nick Palmer
    @nickpalmer
    Ah, so then why not put those in store? Express probably knows about the store to serialize state, so you can retrieve them from the store after that. If you don't want them in the serialized state you can delete them before serializing the store state and banging that into the content.
    And you can still use the saga (if you are on 4.2.0-beta.2) to fire an action for your "special" query to put it into the store where you want it.
    Josh Levinson
    @joshlevinson

    @nickpalmer So I ended up giving the saga-as-a-query-fn a shot, and got it working–kind of. The issue I ran into that has me really stumped is that I haven't let kasia run its complete saga (and thus the completeReducer), meaning none of the data is normalized through kasia's core normalization + plugins (e.g. wp-api-response-modify). I could work around that if I had to, just working with the normal shape of the api response, but wondered if you had any ideas.
    e.g.

    const singleQueryFn = function* singleQueryFn(wpapi, props, state) {
      // call to getSingle yields an array with 1 item.
      const [single] = yield call(getSingle, wpapi, props, state);
    // This action/reducer puts the resource in the store under `routeResource`.
    // However, this object is not normalized through kasia's core normaliser.
      yield put(routeResourceAdded(single));
      return single;
    };

    Later, in my communication with express, I have a handler with access to the res and store, which sets things in the res based on state.routeResource.

    Nick Palmer
    @nickpalmer
    I am not using wp-api-response-modify but it should be fired.
    Oh, I see
    So I would just have routeResourceAdded take the id of the thing that was returned.
    And then get it out of the wordpress store by id.
    There is no reason to duplicate the data in two places in the store.
    Josh Levinson
    @joshlevinson
    Yep, I think that - or something similar, like opts.preserve - is what I'll need to do. Should have thought twice about storing the entire object in two places...
    Nick Palmer
    @nickpalmer
    Have you guys ever implemented infinite scroll?
    I would like to be able to trigger another query but not sure how to do that exactly.
    Digging through the code...
    Nick Palmer
    @nickpalmer
    So redux/actions.js has them.
    But kasia doesn't export them.
    Nick Palmer
    @nickpalmer
    outlandishideas/kasia#70
    Nick Palmer
    @nickpalmer
    So, thinking about the preload design. With react router v4 there isn't a great way to walk the whole component tree.
    So hard to know what preloaders to call.
    I am managing this with careful engineering around what can be connected with Kasia.
    But I was thinking, why doesn't kasia have a 'registry' that can be turned on for server rendering.
    And just store all the queries in the registry.
    Or I guess a way to store all the tasks.
    And then when kasia is done rendering you can ask it to join all tasks that were generated.
    Won't have time to dig into that for a few weeks but I think it would work.
    Sam Gluck
    @sdgluck
    Hey Nick- do you mean that when someone uses the connect* fns that Kasia would keep an internal record of the respective functions? I like that
    But you lose the ability to know which queries to fire off depending on a route?
    Nick Palmer
    @nickpalmer
    So with react v4 you loose the ability to know all the components in the tree because routing can happen at multiple levels.
    When you render the routing all figures out what to render and everything just works.
    The problem is that there is no way to tell the server to wait for the query tasks to finish.
    I guess you would end up doing a two render pass then though which is not ideal.
    First pass you would get the "Loading" page which is probably not what you want.
    So then when all queries finished you would rewind Kasia and do another render.
    Nick Palmer
    @nickpalmer
    What I am doing now is hoisting sub component pre-renders.
    And only allowing components one level deep to connect.
    But this is less than ideal.
    Nick Palmer
    @nickpalmer
    So, I think we need to think about the connection between queries and creators.
    I just did commenting on posts for the first time and it was harder than it should be.
    Once a comment is created I had to do some work arounds to get the query for all comments to re-run.
    And even that isn't really ideal.
    Sam Gluck
    @sdgluck
    Yeah kasia doesn't provide any api for those kinds of api interactions
    It is something that has been on the backlog for some time
    Sam Gluck
    @sdgluck
    If you have time I would love to collaborate with you on implementing this kind of functionality