Shulou(Shulou.com)06/03 Report--

Editor to share with you how to carry out the front and back-end isomorphism of native JS, I believe most people do not know much about it, so share this article for your reference. I hope you will learn a lot after reading this article. Let's learn about it together.

What is front and rear isomorphism?

Three concepts are clear: "back-end rendering" refers to the traditional rendering mechanism of ASP, Java or PHP; "front-end rendering" refers to the use of JS to render most of the content of the page, which represents the popular SPA single-page application; and "isomorphic rendering" refers to the sharing of JS between the front and rear ends, and the use of Node.js to go straight out of the HTML when rendering for the first time. Generally speaking, homogeneous rendering is a common part of the front and back end.

I feel that the front end is indeed a twists and turns, and before it was still popular, the front and back ends were separated, but now why do we have to do the front and back ends to be isomorphic?

The reason is that the popular SPA front-end single-page application is relatively heavy, the first access needs to load more files, the first load is too slow, users need to wait for the front-end to render the page. And it is not conducive to SEO and caching, and there is a certain threshold for development.

The front and back end isomorphism reuses the template and the JS file so that a code can run on both the server and the browser, render the page using nodejs for the first time, and then use SPA to route the jump. It can effectively reduce the waiting time for users to visit for the first time, and is friendly to SEO and easy to cache.

Project profile

This front-end isomorphism project is mainly divided into two parts, one is a koa2-based rendering server, and the other is a front-end SPA based on native JS and zepto.

The characteristic of the project is that it does not use the framework such as vue and react, the threshold is low, the development speed is fast, it is easy to start, and it is relatively light. The core router part only has about 100 lines of code. It is suitable for scenarios with few page interactions and infrequent changes, which can effectively improve performance and loading speed.

Front end part

The core of the front-end part is the routing part. The specific implementation can be based on history API or hash. There are many implementations on the Internet. This time, we will mainly talk about the architecture.

The front-end part adopts MVC hierarchical structure.

What the router layer does is to create a routing example, call the get method of the route, and bind functions from the control layer to specific pages.

Forms such as:

The constructor of the import control from'.. / control'// route supports passing in the render function, the global name of the route, and the hook router = new Router (render,'ROUTER',beforeFn) router.get ('/ page/a', control.pageA') called before the route is redirected.

What the control layer mainly does is to load the rendering template and rendering data shared with the backend, and then run the page function after rendering the page.

Forms such as:

Let control = {pageA (req,res) {/ / webpack dynamic loading, code splitting function import (/ * webpackChunkName: "pageA" * / 'script/pageA'). Then (module= > {/ / check whether the page has been rendered by a server If yes, run module.default / / directly, otherwise load the template and data for rendering, and finally call the page function if (this.needRender (module.default)) {/ / the address accessed when loading the data is the address of the page currently ready to render, only adding the parameter loadData ('pageA'). Then (data = > res.render (xtpl,data,module.default))} / / capture webpack hot updates Let him only perform the operation equivalent to a page jump instead of refreshing the page if (module.hot) {module.hot.accept (['script/pageA'], () = > {control [ROUTER.req.currentControl] .call (ROUTER,null,ROUTER.res)})}

The view layer is the template. Here we use the xtpl template, which supports rendering pages in both server and front-end environments.

The form of the page function

The page function is required to be written in the module of es6, in conjunction with the demand loading function of webpack.

Export default () = > {window.addEventListener ('scroll', fn) / / the page function supports returning an unload function, which will be called when the page leaves / / is mainly used for memory release, timer clearance, event monitor removal, etc. Return function () {window.removeEventListener (' scroll', fn)}}

Back end part

A rendering server built using koa2 will request data from the API server when it receives the page request from the frontend, and identify whether the page request has the parameter of json=1. If so, it is the request of the frontend route jump, and the data can be returned directly. If there is no json parameter, load the template shared with the frontend, render the data with the data, and send it to the browser.

These are all the contents of this article entitled "how native JS is isomorphic at the front and back end". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.