search

atlassian-labs / react-resource-router

Configuration driven routing solution for React SPAs that manages route matching, data fetching and progressive rendering
https://atlassian-labs.github.io/react-resource-router
Apache License 2.0
202 stars 28 forks source link

Add max wait time as an option to static router #82

Closed CharlesCarey closed 3 years ago

albertogasparin commented 3 years ago

I think we are missing Flow types update, right?

jackbrown commented 3 years ago

This is looking great.

Can you help me understand the use case? Is this intended to help the app timeout in SSR sooner than it would if it waited for the actual SSR timeout? Is there any plan to use different timeouts on different resources?

albertogasparin commented 3 years ago

Can you help me understand the use case? Is this intended to help the app timeout in SSR sooner than it would if it waited for the actual SSR timeout? Is there any plan to use different timeouts on different resources?

Yes, actual SSR timeout currently does not render anything and loses data already fetched. We want to instead render a skeleton for components that have slow APIs but still render others that are ready. So SSR timeout should kinda never be hit (unless we have an issue with render or something).

Is there any plan to use different timeouts on different resources? Maybe, so far we did not have any specific request to support for it thought

CharlesCarey commented 3 years ago

This is looking great.

Can you help me understand the use case? Is this intended to help the app timeout in SSR sooner than it would if it waited for the actual SSR timeout? Is there any plan to use different timeouts on different resources?

@jackbrown the idea behind this change is to make sure we can always SSR some sort of content to the client. We have a hard timeout around the total SSR time already, if we surpass this then we throw away all of the SSRed result so the user sees a blank screen. With this change we can impose a limit on how long resources can take to fetch, leaving us enough time to complete the render. We should always be able to send something meaningful to the client, even if it is just a loading state.

The change will accomplish two things. Firstly, we can improve the user experience in the case of slow APIs (loading state vs blank screen) and we will be able to improve overall performance as we will only have to refetch failed resources on the client rather than everything.

jackbrown commented 3 years ago

Really great stuff. We should share this feature around to all consumers of RRR and SSR once it's available!