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
Thank you for the excellent work on isomorphic-relay and isomorphic-relay-router
I am trying to understand how the implementation of IsomorphicRelay.Renderer is different to Relay.Renderer.
They both wrap RelayReadyStateRenderer which is a private api (it's not mentioned in the docs)
IsomorphicRelay.Renderer is not rendering the initial loading screen to prevent duplicate renderings on the server
Relay.Renderer is referencing the Garbage Collector and implements other things that IsomorphicRelay.Renderer doesn't implement (I am not familiar enough with Relay to know what these things do).
Are there any known inconsistencies/limitations in using IsomorphicRelay.Renderer in place of Relay.Renderer?
I can tell from the history of the relay repo that there has been previous attempts to make Relay.Renderer isomorphic. This makes me think that isomorphic-relay is a stepping stone to native isomorphic rendering in relay. Is this correct? If so, are there current blockers to make this happen?
The text was updated successfully, but these errors were encountered:
IsomorphicRelay.Renderer is not rendering the initial loading screen to prevent duplicate renderings on the server
It just doesn't send a data fetch request if the data is already available. But if the data is not ready you can render a loading screen, exactly as with bare Relay.Renderer.
Relay.Renderer is referencing the Garbage Collector
As IsomorphicRelay.Renderer is no longer solely responsible for data fetching, it can't be responsible for acquiring a GC lock.
Fortunately, there is no point to enable GC on the server (as we throw Relay store away on each request anyway), and most apps don't need it on the client. But if you really want to enable it (using a not so public API), then you need to do GC locking yourself.
Relay.Renderer ... implements other things that IsomorphicRelay.Renderer doesn't implement
What other things?
Are there any known inconsistencies/limitations in using IsomorphicRelay.Renderer in place of Relay.Renderer?
I am not aware of any except the described above.
This makes me think that isomorphic-relay is a stepping stone to native isomorphic rendering in relay. Is this correct? If so, are there current blockers to make this happen?
After reading the bottom of that comment I understood that the Relay team prefer not to deal with server side rendering directly, but to provide minimally necessary API to help implementing external libraries like isomorphic-relay. Maybe with Relay 2 it will change.
Thank you for the excellent work on
isomorphic-relay
andisomorphic-relay-router
I am trying to understand how the implementation of
IsomorphicRelay.Renderer
is different toRelay.Renderer
.RelayReadyStateRenderer
which is a private api (it's not mentioned in the docs)IsomorphicRelay.Renderer
is not rendering the initial loading screen to prevent duplicate renderings on the serverRelay.Renderer
is referencing the Garbage Collector and implements other things thatIsomorphicRelay.Renderer
doesn't implement (I am not familiar enough with Relay to know what these things do).Are there any known inconsistencies/limitations in using
IsomorphicRelay.Renderer
in place ofRelay.Renderer
?I can tell from the history of the
relay
repo that there has been previous attempts to makeRelay.Renderer
isomorphic. This makes me think thatisomorphic-relay
is a stepping stone to native isomorphic rendering inrelay
. Is this correct? If so, are there current blockers to make this happen?The text was updated successfully, but these errors were encountered: