Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Josh Levinson
    @joshlevinson
    Because it's then 2 api queries, one of which is to a collection
    Nick Palmer
    @nickpalmer
    Yeah, that's fine. That is easy to arrange in ArticleRoute with componentDidMount
    class ArticleRoute extends Component {
        componentDidMount() {
             this.setState({ mounted: true })
        }
         render() {
             this.state && this.state.mounted ?
             <Article article={this.props.kasia.article}></Article> :
             null
        }
    Josh Levinson
    @joshlevinson
    Ah, nice. Don't know why lifecycle stuff didn't come to mind. This is my first serious foray into ssr, and it's been quite a journey :D
    Nick Palmer
    @nickpalmer
    It takes more thinking for sure, and lifestyle issues are much more at play. :)
    But for AMP friendly you pretty much have to go down this route.
    Josh Levinson
    @joshlevinson
    Oh wow, I bet AMP gets real fun :P
    Nick Palmer
    @nickpalmer
    @sdgluck Any chance we can push a 4.2.0-beta.2 release to npm so I can stop installing and building from my github branch?
    Sam Gluck
    @sdgluck
    @nickpalmer Sure thing- that's up now on kasia@beta
    Nick Palmer
    @nickpalmer
    Awesome! Thanks!
    Sam Gluck
    @sdgluck
    No problem thanks for testing it!!
    Josh Levinson
    @joshlevinson
    Have y'all run into a situation in which you need to identify a given query to take a specific action? e.g. an application might make many requests for resources (even of the same type), but a specific action is needed for a specific query. I'm struggling with how to identify a unique/individual query, considering that kasia communicates queries by "id" (the # of the query in time).
    Nick Palmer
    @nickpalmer
    Not sure I understand the use case but you can fire the extra action in the saga if you are using sagas for your queries.
    So detect that it is this "special" query using the props passed to the query and fire a put() in the query saga.
    Josh Levinson
    @joshlevinson
    So–I'm using express for ssr, and need to be able to set some things in res.locals based on the response of the "main" query for a given page.
    e.g. the main query would be displaying a single post, and I need to be able to provide express with some metadata from that post via res.locals
    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.