Live data from Hacker News

React Server

react-server.io

71–80 of 143 posts

Re: React Server

#71
post #54

Earlier quoted context omitted.

I have to agree here. There's nobody better to explain how something really works than the person who wrote it. The rest of us are just fumbling around guessing. As a dev and a creative person, I understand the desire to get something out there. But documentation and tutorials aren't just something that's nice to have. They are your marketing tool, your adoption driver, and the way to create educated advocates for yo…

That process of you fumbling around and guessing is actually really extraordinarily helpful. The things a contributor might think to do or to try, and the things that a newcomer might think to do or to try, are completely different. No documentation survives its first encounter with a real newcomer. We can, and will, continue working on the onboarding experience, but we'll need real users to roll up their sleeves and…

That process is the second part of the process, once clear, basic documentation exists.

Re: React Server

#72
post #5

This is interesting, especially since I just spent the last two weeks setting up a boilerplate for a universal react/redux SPA on spec for a new client. I enjoy the flexibility but the need to develop a deep working knowledge of several independent libraries, transpilers, and build tool configuration files (each of which has several competing options with their own way of doing things) just to get to hello world is c…

I've always used React Router for routing. It's super flexible and plays very nicely with Redux and server-side rendering. In terms of syncing up state to views, you might want to look into 'redial' and 'react-redux', which are just higher-order components that ensure your React components can injected with the necessary state.

Re: React Server

#73
post #5

This is interesting, especially since I just spent the last two weeks setting up a boilerplate for a universal react/redux SPA on spec for a new client. I enjoy the flexibility but the need to develop a deep working knowledge of several independent libraries, transpilers, and build tool configuration files (each of which has several competing options with their own way of doing things) just to get to hello world is c…

I've always used React Router for routing. It's super flexible and plays very nicely with Redux and server-side rendering. In terms of syncing up state to views, you might want to look into 'redial' and 'react-redux', which are just higher-order components that ensure your React components can injected with the necessary state.

I eventually settled on universal-redux-router, but I'll check out redial. I have found the redux ecosystem to be generally high quality.

Re: React Server

#74
Would be useful if this project explained the difference between React and ReactServer. It seems they are as similar as Java and Javascript.

Instead of the render() method in React to output JSX, it appears that ReactServer uses getElements() for a similar purpose. So the entire model and object lifecycle is probably different as well?

Re: React Server

#75

Would be useful if this project explained the difference between React and ReactServer. It seems they are as similar as Java and Javascript. Instead of the render() method in React to output JSX, it appears that ReactServer uses getElements() for a similar purpose. So the entire model and object lifecycle is probably different as well?

Is each page pushed to the browser in a static fashion? Or does ReactServer implement minimal client DOM updates in a similar manner to React?

Re: React Server

#76
post #34

I see a bunch of failed attempts in console to connect to slack websocket. Is everything looking ok for you? After blocking 2 iframes with adblocker I could finally inspect what was going on :) Anyway, I can definitely feel that is fast and seamless and worth to give a deeper look! In the meantime, prefetching all the content in docs or source views upon load generates quite a few requests and might explain your scal…

That's a result of the Slack badge at the bottom of the page trying to use a WebSocket to update its counts. We discovered getting WebSockets working through ELB was not trivial and have decided instead to disable the real-time updates to the badge. The changes have been made for that, but sadly, not deployed in time for your visit. Anyway, the errors in the console aren't impacting the behavior of the site (the badg…

> getting WebSockets working through ELB was not trivial

Amazon announced the Application Load Balancer today which supports Websockets:

https://aws.amazon.com/blogs/aws/new-aws-application-load-ba...

Re: React Server

#77

Would be useful if this project explained the difference between React and ReactServer. It seems they are as similar as Java and Javascript. Instead of the render() method in React to output JSX, it appears that ReactServer uses getElements() for a similar purpose. So the entire model and object lifecycle is probably different as well?

React Server uses React; the page that has getElements is sort of a meta-React-component that has other specified behavior, as well as returning a React component to be mounted. So it renders the first page you visit on the server (for fast loading), then all subsequent pages are rendered on the client.

Re: React Server

#78
post #77

Would be useful if this project explained the difference between React and ReactServer. It seems they are as similar as Java and Javascript. Instead of the render() method in React to output JSX, it appears that ReactServer uses getElements() for a similar purpose. So the entire model and object lifecycle is probably different as well?

React Server uses React; the page that has getElements is sort of a meta-React-component that has other specified behavior, as well as returning a React component to be mounted. So it renders the first page you visit on the server (for fast loading), then all subsequent pages are rendered on the client.

Thanks. That should be the very first line in the documentation.

Re: React Server

#79

Would be useful if this project explained the difference between React and ReactServer. It seems they are as similar as Java and Javascript. Instead of the render() method in React to output JSX, it appears that ReactServer uses getElements() for a similar purpose. So the entire model and object lifecycle is probably different as well?

Is each page pushed to the browser in a static fashion? Or does ReactServer implement minimal client DOM updates in a similar manner to React?

Each page is split into sections. Each section may wait for async data and API responses. When all the data arrives, the section is rendered as an HTML string.

The server streams each section's static HTML to the client as soon as it's ready, and after all prior sections are streamed.

The server also streams the async data to the browser. This avoids the latency of the client downloading some HTML, then downloading some JS, then making the requisite API calls for the page's data. (Think of it as a hacky version of HTTP Server Push.)

On the client-side, React and your JS are downloaded, React will recycle as much of the static DOM as possible (writing isomorphic JS isn't always easy), then take over and do its thing.

Re: React Server

#80

Earlier quoted context omitted.

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

I believe React will always re-render, to attach click handlers and the like.

This is true. However, if the checksums match, then React can skip tree-diffing and DOM mutations.
Post reply on HN