4 ms·

How does it handle fetching data from a path on the same origin? For instance, I only need to fetch('/api/users.json') on a certain page (/users). This means th

How does it handle fetching data from a path on the same origin? For instance, I only need to fetch('/api/users.json') on a certain page (/users). This means that it can either be hydrated in the initial state when performing a full page load of /users or needs to be fetched (using xhr/fetch) when navigating to that page from another page on the site (which shouldn't require a full page load). So how exactly does the server perform that same fetch when attempting to hydrate the full page without actually making an HTTP request against itself?

onewaystreet 10y ago
It doesn't. The data is included with the rendered page. React uses checksums to tell if it needs to rerender.
- dustingetz 10y ago
  I believe React will always re-render, to attach click handlers and the like.
  - Bartkusa 10y ago
    This is true. However, if the checksums match, then React can skip tree-diffing and DOM mutations.
kcjonson 10y ago
gigabo's account has been rate limited, but he wants to say: There's no data caching across pages. On first page load the responses from data requests for that page are transferred to the browser and rehydrated. For a client-side transition to another page there are two options: Fetch the data from the server as a bundle (this just works... one of the cooler features of React Server, I think) or make the individual requests via xhr from the browser. Both have their place. There's some more discussion of this here: https://react-server.io/docs/guides/client-transitions https://react-server.io/docs/guides/client-transitions
wwalser 10y ago
The other responses seem to be answering how this would work once the hydration is occurring on the client side. I understood the question to be `Does the http request layer support doing API requests to routes which are on the same webserver as react-server`. There doesn't appear to be special handling for this use case. However, they use SuperAgent (https://github.com/visionmedia/superagent https://github.com/visionmedia/superagent) for http requests and I expect implementing the behavior that you're describing is relatively easy with their plugin system. Specifically I'd bet that plugins previously designed for testing could be used to accomplish your goal (superagent-mock or superagent-mocker).
- idbehold 10y ago
  What I'd like to be able to do is not incur an additional HTTP request against my own server. Does SuperAgent have a way to avoid opening a new socket when making a request against yourself?
  - shriek 10y ago
    I'd like to know the answer to this too. What I've thought so far is that I just call the function that makes db calls or other operation on the server side but this is clearly not the way do in client side if the app was to be universal.
    - exogen 10y ago
      In my experience [1], you'd probably just use an if statement that does something different when you're on the server. That's totally fine and is still a universal app; universal apps don't have to take every exact same code path on the client and server, they just have to run the same code base. In React, people typically use the ExecutionEnvironment module [2] for this: if (ExecutionEnvironment.canUseDOM) { // make client side request } else { // make direct db request } ...but you could also just do some simpler check, like see if `window` exists, or make up your own `IS_SERVER` global, etc. Next you'll wonder: won't that still ship the server-side code to the browser, even if it's not run, and pull in any server-only modules you're importing, e.g. database access stuff? No: you'd fix this with (for example) webpack's `DefinePlugin` [3], telling it that `ExecutionEnvironment.canUseDOM` should always be `true` wherever it occurs in your client-side JS bundle, and dead code elimination will then rip out those server-only `else` branches before that code gets shipped to the browser. Or a similar setup, like wwalser hinted at: write 2 versions of your 'request' module: one for the client, and one for the server. Tell webpack it should point to the client-side one when you generate your client JS bundle. People use webpack because it lets you do all kinds of overrides like this. [1]: I work at Formidable, we do a ton of React for big companies. [2]: https://github.com/JedWatson/exenv https://github.com/JedWatson/exenv [3]: https://webpack.github.io/docs/list-of-plugins.html#defineplugin https://webpack.github.io/docs/list-of-plugins.html#definepl...
Bartkusa 10y ago
Hey, I'm a dev at Redfin, and I've done something like this (with Gigabo's help). It's possible, but it's not well-supported yet. My team owns one special-snowflake API in React-Server. We want the API to be reachable from the client via HTTP, but also want to execute the code directly during server-side rendering, with no HTTP call. It's your exact use-case. In order to do that, we 1. Detect if the API is invoked server-side. 2. Tell Superagent* to tell the client "hey, if you want data for $API_URL, don't make an HTTP request; the response will come inline in the page's HTML response. 3. Invoke the API code directly. 4. When the API response is ready, serialize it, and tell Superagent to pass it to the client. We don't do this kind of thing frequently, so we haven't built any graceful tooling for it. * I _think_ this is Superagent: https://visionmedia.github.io/superagent/https://visionmedia.github.io/superagent/ https://visionmedia.github.io/superagent/https://visionmedia.... Somehow, we use it in a way that notifies the client of what HTTP requests the server is performing on its behalf; not sure if that's stock Superagent or if we added some magic to it.

onewaystreet 10y ago

It doesn't. The data is included with the rendered page. React uses checksums to tell if it needs to rerender.

dustingetz 10y ago
I believe React will always re-render, to attach click handlers and the like.
- Bartkusa 10y ago
  This is true. However, if the checksums match, then React can skip tree-diffing and DOM mutations.

kcjonson 10y ago

gigabo's account has been rate limited, but he wants to say: There's no data caching across pages. On first page load the responses from data requests for that page are transferred to the browser and rehydrated. For a client-side transition to another page there are two options: Fetch the data from the server as a bundle (this just works... one of the cooler features of React Server, I think) or make the individual requests via xhr from the browser. Both have their place. There's some more discussion of this here: https://react-server.io/docs/guides/client-transitions https://react-server.io/docs/guides/client-transitions

wwalser 10y ago

The other responses seem to be answering how this would work once the hydration is occurring on the client side. I understood the question to be `Does the http request layer support doing API requests to routes which are on the same webserver as react-server`. There doesn't appear to be special handling for this use case. However, they use SuperAgent (https://github.com/visionmedia/superagent https://github.com/visionmedia/superagent) for http requests and I expect implementing the behavior that you're describing is relatively easy with their plugin system. Specifically I'd bet that plugins previously designed for testing could be used to accomplish your goal (superagent-mock or superagent-mocker).

idbehold 10y ago
What I'd like to be able to do is not incur an additional HTTP request against my own server. Does SuperAgent have a way to avoid opening a new socket when making a request against yourself?
- shriek 10y ago
  I'd like to know the answer to this too. What I've thought so far is that I just call the function that makes db calls or other operation on the server side but this is clearly not the way do in client side if the app was to be universal.
  - exogen 10y ago
    In my experience [1], you'd probably just use an if statement that does something different when you're on the server. That's totally fine and is still a universal app; universal apps don't have to take every exact same code path on the client and server, they just have to run the same code base. In React, people typically use the ExecutionEnvironment module [2] for this: if (ExecutionEnvironment.canUseDOM) { // make client side request } else { // make direct db request } ...but you could also just do some simpler check, like see if `window` exists, or make up your own `IS_SERVER` global, etc. Next you'll wonder: won't that still ship the server-side code to the browser, even if it's not run, and pull in any server-only modules you're importing, e.g. database access stuff? No: you'd fix this with (for example) webpack's `DefinePlugin` [3], telling it that `ExecutionEnvironment.canUseDOM` should always be `true` wherever it occurs in your client-side JS bundle, and dead code elimination will then rip out those server-only `else` branches before that code gets shipped to the browser. Or a similar setup, like wwalser hinted at: write 2 versions of your 'request' module: one for the client, and one for the server. Tell webpack it should point to the client-side one when you generate your client JS bundle. People use webpack because it lets you do all kinds of overrides like this. [1]: I work at Formidable, we do a ton of React for big companies. [2]: https://github.com/JedWatson/exenv https://github.com/JedWatson/exenv [3]: https://webpack.github.io/docs/list-of-plugins.html#defineplugin https://webpack.github.io/docs/list-of-plugins.html#definepl...

Bartkusa 10y ago

Hey, I'm a dev at Redfin, and I've done something like this (with Gigabo's help). It's possible, but it's not well-supported yet. My team owns one special-snowflake API in React-Server. We want the API to be reachable from the client via HTTP, but also want to execute the code directly during server-side rendering, with no HTTP call. It's your exact use-case. In order to do that, we 1. Detect if the API is invoked server-side. 2. Tell Superagent* to tell the client "hey, if you want data for $API_URL, don't make an HTTP request; the response will come inline in the page's HTML response. 3. Invoke the API code directly. 4. When the API response is ready, serialize it, and tell Superagent to pass it to the client. We don't do this kind of thing frequently, so we haven't built any graceful tooling for it. * I _think_ this is Superagent: https://visionmedia.github.io/superagent/https://visionmedia.github.io/superagent/ https://visionmedia.github.io/superagent/https://visionmedia.... Somehow, we use it in a way that notifies the client of what HTTP requests the server is performing on its behalf; not sure if that's stock Superagent or if we added some magic to it.