relay-tools / relay-query-lookup-renderer Goto Github PK

The mentioned PR in Readme is merged. But still the QueryRenderer from react-relay package does not support caching. Also the current package is not working because the component is unmounted, can you add some documentation to README as to how to retain the component so that lookup code is executed in componentWillReceiveProps.

You are a legend for putting this together and sharing. Works great.

Sorry, this isn't an actual issue, but rather a question;

I'd like to be able to distinguish when the QueryRenderer is loading data (making requests) in order handle intermediate loading states (primarily when changing query variables which causes a new network request). I have a PR ready for this complete with tests, which adds a loading boolean to readyState in QueryRenderer. But, before submitting the pull request - is this something you'd be willing to discuss merging? I understand it diverges from the original thought of this repo.

Otherwise I'll just fork and use that for my specific use case, but maybe this could benefit others too.

thanks for the handy workaround of lookup and retain but I noticed that when I execute the query bellow several times but with different params all query is sent out.

query routerPageBlogQuery($count: Int!, $cursor: String) {
    blogPage {
      id
      name
      content
    }
    blogPosts(first: $count, after: $cursor) {
      edges {
        cursor
        node {
          id
          name
        }
      }
    }
  }

as you can see blogPage doesn't require any params so basically it can be excluded from subsequent requests, is it possible to support that?

I find that I am getting the following warning: Warning: setState(...): Can only update a mounting component. This usually means you called setState() outside componentWillMount() on the server. This is a no-op. Please check the code for the ReactRelayQueryRenderer component.

It seems to be caused by the setState inside onNext . Line 211 this.setState({readyState});

If I wrap this in a if (this._mounted) is seems to work okay, without the warning:
if (this._mounted) { this.setState({readyState}); }

I'm not 100% sure why this fix helps, or if it is a correct fix. My app seems to be okay after this fix and no warning is generated. If this fix is good, should it also be added a few lines above in onError? (Line 188)

Thanks!

This can not work when I use commitMutation.
I found the data was changed in relay store, but this did not get the change data.
I think the problem is componentWillReceiveProps in relay-query-lookup-renderer. For commitMutation, query, environment, variables dose not change. As a result, the result of this check is always false. This will not update a new store to readyState.
https://github.com/robrichard/relay-query-lookup-renderer/blob/master/src/index.js#L77-L81

Maybe we need to check the readyState in relay-query-lookup-renderer should be equal to the data in relay store?

Finally, thank you for doing this project. This is the best way for modern relay SSR I found.

streamQuery is deprecated now and prints out console warnings

@robrichard

The react-relay query render will performance once fetch, regardless of how many times it appears in the react tree.

For example

import {QueryRenderer} from 'react-relay';
const something = [1,2,3]
{something.map( () => <QueryRenderer {...props} /> )

Will cause a single request.

import {QueryLookupRenderer} from 'relay-query-lookup-renderer';
const something = [1,2,3]
{something.map( () => <QueryLookupRenderer {...props} /> )

Will fire 3 requests, if it can not find the data in the store.

Only difference between these two screenshots was using switch QueryRenderer for QueryLookupRenderer

Doesn't seem to be compatible with the new relay... Any plans on supporting it?

Sorry this isn't an issue but rather a feature request

I'd like to programmatically check if there is a cache hit in the render prop so that i can pass has hasCache prop to my component. So this is my use case:
I want to increase perceived performance in my RN app without caching my screen. I thought I could just use QueryRenderer with caching enabled by default then pass hasCache prop to my component. Then I could just refetch the whole data when that component is mounted using relay modern createRefetchContainer only if there is a cache hit. That way I could drastically improve perceived performance of my app.

Hey @robrichard! Thanks again for publishing this! Following up on our discussion on your PR, I have a couple suggestions for the API. Mainly it would be nice to hide the details a bit - for example not requiring the user to call retain() or sendQuery(). An example of this style is @denvned's https://github.com/denvned/isomorphic-relay

For Relay Modern, the equivalent might be something like:

// server
import { prefetchQuery, Renderer } from '...';

async function serverRender() {
  const {data, props} = await prefetchQuery(environment, graphql`...`, variables); // throws on error
  const markup = React.renderToString(
    <Renderer {...props} />
  );
  // render markup plus JSON.stringify(data)
}

// client
import {loadPrefetchedQuery, Renderer} from '...';
const props = loadPrefetchedQuery(env, query, vars, data); // data is JSON.parse(...) of data from server
ReactDOM.render(
  <Renderer {...props} />
);

Key points are that the details are hidden from the user, and that Renderer accepts input that is most easily created by executing one of prefetchQuery() (server) or loadPrefetchedQuery() (client). As far as loading prefetched data on the client, you can use environment.getStore().publish(new Source(data)).

the code need to be recompiled before pushing to npm registry

Would it make sense to implement a prop to disable GC (a'la Relay Classic behaviour) to this package?

I find it wasteful, even annoying to fetch all the data again & again in most of my own apps. Very few (browser) apps are very long-lived & I don't belive most of our apps ever get memory problems, especially if you don't target emerging markets (very low-end devices).

It would also be pleasantly flexible for different strategies, for example:

• List view - dynamic, updates often, don't retain: <QueryRenderer other={"props"}/>
• Single item view - retain it: <QueryRenderer retain other={"props"}/>

It would be very cheap because it would only be checked againts on componentWillUnmount or what?

But how would one even implement this? I think something like this, haven't seen any side-effects so far..

_release() {
  // ... _rootSubscription & _pendingFetch code -> nothing to do with retaining data

  // reference to retained data ("protected" from garbage collection) - jackpot, add condition
  if (!this.props.retain && this._selectionReference) {
    this._selectionReference.dispose();
    this._selectionReference = null;
  }
}

I haven't 100% figured out yet how onError & onNext might affect retained data in different situations.

This library works fine with react relay app on the web but it breaks with react native relay

subj

Hi!

I think that this library might not be 100% compatible with a fetchQuery.
Imagine the following setup:

• There are 2 pages, PageA and PageB which have a QueryA and QueryB connected to them respectively.
• We are using relay-query-lookup-renderer only to read from the Relay store, data fetching is done independently via fetchQuery.

The user journey is:

1. Visits PageA. QueryA is fetched on the server, Relay store records are used to hydrate the store on the client. QueryLookupRenderer reads the data from Relay store by being rendered with query={QueryA} and render={({props}) => <ComponentA data={props}/>}
2. Travels from PageA to PageB.

• QueryB is fetched via the fetchQuery
• QueryLookupRenderer is re-rendered with query={QueryB} and render={({props}) => <ComponentB data={props}/>}, data is already in the store

3. Travels from PageB to PageA

• QueryA is fetched via the fetchQuery
• Possible bug - before QueryLookupRenderer is re-rendered with query={QueryA} it actually invokes the render function with props corresponding to QueryA, even though the render itself is still ({props}) => <ComponentB data={props}/> and the query prop is still QueryB
• QueryLookupRenderer is re-rendered with query={QueryA} and render={({props}) => <ComponentA data={props}/>}

I suppose that it has to do something with QueryA already being present in the Relay store. Recreating a store on every page transition fixes it.

Hi!
You set this (https://github.com/robrichard/relay-query-lookup-renderer) url instead of relay-context-provider repo on npm.
BTW, u have made a good solution