You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I suspect this problem is a mix of stupid and real issues with however suspense is being handled.
On specific pages, notably clicking on a link to a specific IBC identifier from a paginated table route (e.g. ibc/clients -> ibc/client/[id]), there can be a very long delay between clicking on that identifier and the page being rendered for that identifier.
In theory, this shouldn't happen. Suspense is supposed to allow NextJS to fallback to loading.tsx while the route is being queried/served; however, I suspect that, because the IBC queries are so heavy (#148), that Suspense doesn't trigger until the server actually responds.
Having a custom indexer that flattens these queries is the high level solution for this kind of problem but the observed behavior is generally bad and should be mitigated. The solution may be as simple as breaking up the component even more so that additional Suspense boundaries can be set up with their own fallbacks. Alternatively, useSuspenseQuery still provides some boolean flags like isFetching and these might be useful for flagging and showing render state. Or maybe things are even dumber than that.
The text was updated successfully, but these errors were encountered:
Summary
I suspect this problem is a mix of stupid and real issues with however suspense is being handled.
On specific pages, notably clicking on a link to a specific IBC identifier from a paginated table route (e.g.
ibc/clients
->ibc/client/[id]
), there can be a very long delay between clicking on that identifier and the page being rendered for that identifier.In theory, this shouldn't happen. Suspense is supposed to allow NextJS to fallback to
loading.tsx
while the route is being queried/served; however, I suspect that, because the IBC queries are so heavy (#148), that Suspense doesn't trigger until the server actually responds.Having a custom indexer that flattens these queries is the high level solution for this kind of problem but the observed behavior is generally bad and should be mitigated. The solution may be as simple as breaking up the component even more so that additional Suspense boundaries can be set up with their own fallbacks. Alternatively,
useSuspenseQuery
still provides some boolean flags likeisFetching
and these might be useful for flagging and showing render state. Or maybe things are even dumber than that.The text was updated successfully, but these errors were encountered: