Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Josh Levinson
    @joshlevinson
    Y'all have any thoughts?
    Nick Palmer
    @nickpalmer
    You either need to pull the Article query into the promise the server is waiting for.
    Or let the client run it.
    It makes no sense to start the query on the server if you are not going to wait for it to complete. You are just thrashing the backend for nothing.
    I would do one of two things.
    EITHER arrange for the Article component to be found and add it to the preLoad chain.
    OR don't mount the Article component on the server.
    The latter can be handled by setting state in componentDidMount, which is not called on the server.
    So ArticleRoute.render would return null until the componentDidMount sets the flag.
    The former would depend on which version of react-router you are using.
    Nick Palmer
    @nickpalmer
    But I would personally use connectWpQuery() and run both calls there on Article.
    And drop the ArticleRoute / Article distinction all together.
    Especially on the 4.2 branch with sagas this is easy to do and I am doing it in a bunch of places now.
    See "Using sagas as queries" on the 4.2.0 branch: https://github.com/outlandishideas/kasia/tree/v4.2.0
    Josh Levinson
    @joshlevinson
    Gotcha. Those sound like some good options! I would prefer that Article does client-side stuff - the query there is essentially for "you may also like..." style related articles at the bottom of the Article component
    So it's something I would prefer not be blocking on the server render
    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.