Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Nick Palmer
    @nickpalmer
    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.
    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.
    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.