Previous Lecture Complete and continue  

  Universal Web Before React


Ok, so the next problem is how do you prefetch the data, so you don't see that "Loading..." so much or at least you can speed up the performance a little bit. And what I mean by prefetching. So let's say you have your single-page application, and then the data is actually coming from a legacy API. So your your server-side application—that's not touching the database directly. So that communication between the Node and in the Node you can also build some caching. Maybe you can use Redis for that. So that communication is taking quite some long


time. So how you can prefetch some of the data so single-page application will get that data really fast and really when it needs it. So one of the solutions we used at DocuSign when we were re-engineering the web app, initially it will build on the C# and we used Backbone, Node.js, Express, CoffeeScript (I love CoffeeScript) and then Grunt and Browserify. So one of the solutions we implemented... we prefetched the data from API on the very first load. So the very first load when the server gets that URL, we already know what


data that page will need how. Well actually there is this file. It's called data mapping. So each link, you can see the URLs. So mapping. And then in the square brackets that's the URL, so slash home (/home) for example. So each URL in this object and by the way it's CoffeeScript, that's why you don't see commas. And that's one of the reasons why I love CoffeeScript even now we have ES6 and 7, and I still think CoffeeScript is doing more and is more elegant solution. Anyway, we have this


object mapping and it has URLs as keys as properties. So this file is accessible both from the server code and from the client code. So when the URL hits slash home (/home) for example, server already knows like: "Hey, I need to get this data." So it goes: signatures, profiles, those type of data that I will need. And then the backbone models, they are also shared on the server. They're not just accessible on the client so the server will go to that model and will actually get the URL for the RESTful API, will go get that


data, fetch it into the Redis caching. And then by the time browser renders the page and interprets the code, the JavaScript code and makes those AJAX and XHR requests for that specific data (for example signatures and profiles), that data will already be conveniently and available in the Redist cache. It will be all very easy to get that data, and serve it right back instead of making another request to the API which takes more time. So that's one of the advantages


of universal web approach. You can do this type of optimization. So Universal is not exclusive to React as you saw but React makes it easier, obviously. So that's why we're talking about React and Express. So what is React? If you're not familiar with the React. React is a UI library. So it's just a tiny bity UI library. It's not a complex framework, it's not an advanced framework, it's not a framework at all. And it's not opinionated which is a good thing in my mind. So React way is building simple functions. So we have some input and then you


have output. Output is your typical... is your UI, is typically HTML, but it could be anything. It could be iOS, could be Java, Android. It could be Canvas. In this case when we're talking about web React, it's HTML. So the key here it's a predictable way. So for each input you have exactly the same output.


So because we have this predictability, React allows you to render exactly the same UI components, UI views on the server. And it's also have this concept of one way binding which makes it simple. Simple, simple, simple. The views are just simple functions. The input, we call them props. And then there could also be some state inside of those "functions", inside of those components which allow you to modify the view as well. So the main idea is that there's one way binding. React is


all about simplicity and keeping those simple components very predictable.