Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation missing for how to set variables initially on RefetchContainer #1770

Closed
lukewlms opened this issue May 17, 2017 · 5 comments
Closed

Comments

@lukewlms
Copy link

lukewlms commented May 17, 2017

RefetchContainer docs show how to set $count on Refetches, but how is count actually initialized?

loadMore adds 10 to count but it's not clear what value of count will be after the first loadMore call because it doesn't seem to be set anywhere.

At:
https://facebook.github.io/relay/docs/refetch-container.html

Update: Unfortunately relay-examples also doesn't have any instances of RefetchContainer so still trying to find an example of anywhere this is actually used. (We need the component to render different data based on date, which is initially set to Today.)

@lukewlms
Copy link
Author

@josephsavona Thanks - that got us part of the way there. Is there a way to access the fragmentVariables outside of the refetch call, e.g. in the render() function?

We need to track which date is being viewed, so it would be very convenient to be able to use the same variable to sync UI state and fetching variable to the same value. Otherwise we'll need to track two separate variables which is of course more fragile.

@josephsavona
Copy link
Contributor

Currently props.relay doesn't have variables, but it seems reasonable to add them. Care to send a PR? :-)

@lukewlms
Copy link
Author

lukewlms commented May 17, 2017

@josephsavona Thanks a lot for the quick replies. I'd like to create a pull request, though I'm combing through getVariablesFromObject and the related code but feel it's still out of my depth.

I'm trying to understand how this scenario can be supported (would be common in a calendar app):

"Initially render a view for today's date, then allow user to navigate to next/previous date and redisplay view."

It seems RefetchContainer is the right choice here since we need to refetch many times with different variables, but substitutions are not allowed in graphQL tags, so I'm stuck on how to initially fetch based on today's date. Any guidance on migrating a scenario like this from Relay Classic?

"Upgrading setVariables" in the docs mentions upgrading to RefetchContainer, but only in the vaguest way. Haven't found an example of how to actually upgrade a component using initialVariables and setVariables.

@josephsavona
Copy link
Contributor

josephsavona commented May 17, 2017

Ah, thanks for clarifying the use case. There is currently only one supported way to set the initial value of a variable dynamically: using global variables defined on the query (or queries) that includes the fragment [1]. So for this example the fragment might reference a global $currentDate variable, which your application initially sets (via variables on the QueryRenderer) to be the current data. Then your refetch container query would also define the $currentDate variable, and set it to the updated date.

[1] This is a tradeoff that Relay Modern makes to conform to the GraphQL specification. In a way, global variables as defined in the spec break the encapsulation of fragments/components and are at odds with the component-oriented model of React and React/Relay. Relay classic worked around this by using runtime query construction, which was not ideal for performance reasons. Our philosophy with Relay Modern is to conform to the spec as closely as possible, while simultaneously working to improve the spec to better address these types of use-cases in future releases.

@lukewlms
Copy link
Author

Thanks for the info, we'll work on this. So far working with Relay Modern feels much more like I'm coding directly in GraphQL which I love. The mutations are also way more straightforward. As long as we can get the app migration running, I think we're going to be very happy working with the new library!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants