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…
React Server
71–80 of 143 posts
Re: React Server
#72This 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…
Re: React Server
#73This 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
#74Instead 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
#75Would 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
#76I 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…
Amazon announced the Application Load Balancer today which supports Websockets:
https://aws.amazon.com/blogs/aws/new-aws-application-load-ba...
Re: React Server
#77Would 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
#78Would 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
#79Would 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?
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
#80Earlier 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.