Comments (9)
That 500ms limit should work just as effectively regardless of how long the SSR response takes; it only needs to cover how long it takes for the whole app and all nested queries to mount at first render, after all the JS has been downloaded, parsed, and then run on the client.
If the server response takes a long time (say, 6 seconds), the 500ms only kicks in afterwards, when the client app mounts.
If the server response is quick, but the app/route JS bundles take a long time to download and parse (say, 10 seconds), again the 500ms only kicks in after that work has completed.
Are you noticing some issues with post SSR hydration, or were you just pre-empting a possible issue?
from graphql-react.
Hmm ok, yeah I'm noticing on one of our heavier pages the 500ms limit is exceeded and it requeries. I guess it just takes a little longer to rehydrate than expected...
from graphql-react.
Do you think you will be able to investigate why it takes so long for some parts of your app containing queries to mount, compared to the rest of the app?
There is a tradeoff that if you make the hydration time too long, it might stop legitimate client queries form loading. For example, a user might quickly click on nav link and the new route is supposed to load on mount.
from graphql-react.
I think it's a combo of styled-components rehydration and some third-party JS slowing things down that I don't have a lot of control of... Is it possible to just configure the rehydration timeout per instance of useGraphql
?
from graphql-react.
@probablyup it sounds like something asynchronous is happening between when react initially mounts with your GraphQLProvider
, and when your component with useGraphQL
is mounted ā perhaps you have a waterfall of requests going on? This is probably not a typical scenario.
That said, I believe you can get the kind of behavior you want by setting loadOnMount
to false
until you are sure your page is ready.
EDIT: This won't work, as it will trigger a re-render when you switch loadOnMount
back to true
.
from graphql-react.
If the first mount takes longer than half a second something funny must be going on that needs to be investigated, and hopefully fixed ā renders usually take milliseconds. It seems Styled Components has had performance issues before, so it could be something like that?
The problem with making the timeout longer in the component is that it is not the component itself that takes a long time to mount, but rather it's context amongst ancestors is the problem.
For example, imagine you have a profile component with a query that is used in two pages. In one page, it is deeply nested in strangely slow mounting components. In the other, the mount is speedy and not a problem. Lengthening the hydration timeout within the component to suit the first page would would unsuitably lengthen the timeout for the other page.
Note that if a query that attempts to load on mount within the hydration time that does not have a cache entry yet, it will still fetch data. So I suppose my earlier example of a user quickly navigating to a new route is not a very good one, since that would still fetch as the doesn't doesn't exist in cache yet. Perhaps a better example is a user clicking on a button to refresh a price ticker that already has a cache entry from SSR. Or a button that queries and displays a random quote would show the same quote again and not fetch a fresh quote if clicked quickly within the hydration timeout.
from graphql-react.
Honestly I'm clutching at straws trying to think of realistic edge-cases where lengthening the 500ms default to something like 1s would cause problems. My last examples are not strictly right either, because if the button just calls load()
then it will definitely fetch fresh data even if it's within the hydration time. The hydration time only applies to loading on mount, so an edge case would involve the user attempting to mount something very quickly that already has a cache entry, where you might reasonably expect the data to have changed in such a short period of time.
Would increasing the arbitrary, hardcoded 500ms value to 1000ms solve most of the issues?
from graphql-react.
Iād make it even looser, if you take mobile devices into account. Perhaps 5s, though hopefully no one is building apps that take that long to rehydrate.
from graphql-react.
Adding and documenting an extra option that takes a lot of technical knowledge to understand is not ideal.
I've increased the limit to 1000ms to cover most slower clients.
A little extra loading is no big deal for clients that take a very long time to hydrate; in that situation fixing the root issue, slow hydration and initial render, will also fix the extra loading.
from graphql-react.
Related Issues (20)
- hello can you convert for native js? HOT 6
- Document the `load` function HOT 3
- Support automatic persisted queries HOT 2
- How should you implement auth using this library? HOT 8
- Possibly missing files within package HOT 2
- Add ability to load on mount only if no cache HOT 2
- How to move gql query to useGraphQL operation query HOT 1
- Publish the GraphQL client in a separate package HOT 5
- Wrong type calculation on useGraphQL HOT 1
- How to use useGraphQL hooks when handleLoadMore functions trigger? HOT 1
- Allow React component displayName and propTypes to be removed in production builds HOT 3
- Pagination possible? HOT 4
- New composable React hooks HOT 2
- Add a license file HOT 3
- Add ability to clear not currently subscribed cache
- Switch to user defined cache keys
- Publish SSR functionality in a separate package
- error - unhandledRejection: TypeError: Head.rewind is not a function -> can't get the official example to work HOT 3
- How to use useLoading() to get the old loading from useGraphql()? HOT 4
- Clear code
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
š Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ššš
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ā¤ļø Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from graphql-react.