React - some reference

The virtual DOM

React doesn't use the standard DOM (Document Object Model). That is because, the standard DOM is painful to manipulate and it really was not designed to be used for interactive and dynamic contents. This is why, it is inefficient and slow and not well suited when dynamic contents are in mind. So, Facebook went a step ahead and brought virtual DOM to the playground. Let's have a closer look.

The virtual DOM is a fast, in-memory representation of the real DOM, and it's an abstraction that allows us to treat JavaScript and DOM as if they were reactive. Let's take a look at how it works:

Whenever the state of your data model changes, the virtual DOM and React will re-render your UI to a virtual DOM representation.

React then calculates the difference between the two virtual DOM
representations: the previous virtual DOM representation that was computed before the data was changed and the current virtual DOM representation that was computed after the data was changed. This difference between the two virtual DOM representations is what actually needs to be changed in the real DOM.

React updates only what needs to be updated in the real DOM.

The process of finding a difference between the two representations of the virtual DOM and re-rendering only the updated patches in a real DOM is fast. Also, the best part is, as a React developer, that you don't need to worry about what actually needs to be re-rendered. React allows you to write your code as if you were re-rendering the entire DOM every time your application's state changes.

Routing

React-Router is a routing solution for React applications. According to react-router, React Router keeps your UI in sync with the URL. It has a simple API with powerful features like lazy code loading, dynamic route matching, and location transition handling built right in.

History: a history knows how to listen to the browser's address bar for changes and parses the URL into a location object that the router can use to match routes and render the correct set of components.

There are three types of histories you'll come across most often, but note that anyone can build a custom history implementation for consumption with React Router.

browserHistory Browser history is the recommended history for browser application with React Router. It uses the History API built into the browser to manipulate the URL, creating real URLs that look like example.com/some/path.

hashHistory Hash history uses the hash (#) portion of the URL, creating routes that look like example.com/#/some/path.

createMemoryHistory Memory history doesn't manipulate or read from the address bar. This is how we implement server rendering. It's also useful for testing and other rendering environments (like React Native).

It's a bit different than the other two histories because you have to create one, it is this way to facilitate testing:

const history =createMemoryHistory(location)

Dynamic Routing: A router is the perfect place to handle code splitting: it's responsible for setting up your views.

React Router does all of its path matching and component fetching asynchronously, which allows you to not only load up the components lazily, but also lazily load the route configuration. You really only need one route definition in your initial bundle, the router can resolve the rest on demand.

Routes may define getChildRoutes, getIndexRoute, and getComponents methods. These are asynchronous and only called when needed. We call it "gradual matching". React Router will gradually match the URL and fetch only the amount of route configuration and components it needs to match the URL and render.

Testing

Facebook has built its own unit test framework for JavaScript called
Jest. It is built on top of Jasmine; another well-known JavaScript test framework. Jest automatically mocks the dependencies when tests are run. It automatically finds tests to be executed in the repository. Let's test this module