Live data from Hacker News

React Server

react-server.io

41–50 of 143 posts

Re: React Server

#41

Based on the documentation and the design principles this seems like a really promising framework. The data hydration, incremental HTML delivery and incremental code loading are really, really important for creating web apps that aren't load time hogs. Great to see that they were unopinionated about data fetching, too. That's one of the things that has made it difficult to drop Relay into existing applications. Is th…

Redfin uses it in production. https://www.redfin.com/blog/2016/05/announcing-react-server....

"We’ve been using it here at Redfin in production for over a year and it serves the three highest traffic pages on the site. We’re serving 1 billion requests a month from our React Server instance; hundreds of requests per second during peak hours."

Re: React Server

#42
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?

Re: React Server

#43
post #38
post #8

Earlier quoted context omitted.

The website itself is meant to serve as a demo. :) When you land on the site the first page is rendered by the server. Then the client controller wakes up and subsequent page views ask the server for data, but render in the browser. That's what we mean by "seamless transitions".

I see you are from Redfin, is this deployed anywhere in production yet? Thx for Redfin btw!

Hello! Redfin has been running React Server in production since early 2015. There's a little more information on React Server in production at https://www.redfin.com/blog/2016/05/announcing-react-server.....

Re: React Server

#44
post #15

Earlier quoted context omitted.

"seamless transitions" in the web design world is often taken to mean "transitions" in the sense of CSS animations, i.e. instead of hard page refreshes elements smoothly morph into their positions in the next page state. See eg. Google's Material Design or Apple's iPhone UI. This is a big, largely-unsolved problem in HTML5, at least in making them pervasive, performant on mobile, and easy for developers. Advertising…

Oh, hadn't considered that interpretation. Our full project description on GitHub is "React framework with server render for blazing fast page load and seamless transitions between pages in the browser". The tag line on the website is shortened from that. I think the full version is a little less ambiguous, but it's a little too wordy in the context of the site. Will have to think about a better tag line... Thanks!

I share nostrademons's interpretation. I'd expect the first page rendered on the server and the rest rendered on the client in any isomorphic framework. When I hear "transitions", I expect elements morphing between assets, ala neon-animated-pages:

https://elements.polymer-project.org/elements/neon-animation...

I think your value proposition is something like: "Renders on the server or the client - whichever's fastest for that request"

Re: React Server

#45

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…

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

Re: React Server

#46

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…

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

Re: React Server

#48

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…

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) 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).

Re: React Server

#49
post #9

It doesn't seem like it is for beginners. Docs look at the author assumes everything is self-obvious. Need better tutorials.

Yes, definitely agree! We need better tutorials! We need better docs in general. Contributions welcome! :D

I'm totally on board with the "contributions welcome" response from open source maintainers, but when it's the only response to questions about documentation it's pretty off-putting. This is your project, how could you expect a new contributor to add docs without your input? I get that good documentation is hard, and takes time, but if you want your project to succeed I think it's almost mandatory for you to write these docs (at least the initial version!) yourself.

Re: React Server

#50
Looks fascinating, I will definitely be watching this project in the coming year.

Just curious, if it's been successfully running in production for over a year, why is it only being used to serve three pages?

Post reply on HN