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

Differences between Relay.Renderer and IsomorphicRelay.Renderer #59

Open
coolov opened this issue Jan 3, 2017 · 1 comment
Open

Differences between Relay.Renderer and IsomorphicRelay.Renderer #59

coolov opened this issue Jan 3, 2017 · 1 comment
Labels

Comments

@coolov
Copy link

coolov commented Jan 3, 2017

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?

@denvned
Copy link
Owner

denvned commented Jan 14, 2017

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.

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

No branches or pull requests

2 participants