基于NodeJS的前端分离的思考与实践(二)模板探索

时间：2021-09-09 来源：互联网编辑：宝哥软件园浏览：次

序

在进行前端分离时，首先要考虑的是渲染，这是View级别的工作。

在传统的开发模式中，浏览器和服务器是由两个不同的团队开发的，但是模板在他们之间处于模糊地带。因此，模板上不可避免地存在越来越复杂的逻辑，最终难以维护。

我们选择了NodeJS作为前后的中间层。尝试按节点在视图级别对工作进行排序。

让前端分工更清晰，让项目更好的维护，实现更好的用户体验。

这篇文章

渲染占据了前端开发人员非常大的一部分日常工作，也是最容易和后端开发纠结的地方。

回顾过去几年的前端技术发展，View这个层面的工作发生了很多变化，比如：

表单提交整页刷新=AJAX部分刷新服务器延续MVC=客户端渲染MVC传统页面变化跳转=单页应用可以观察到，近年来大家都倾向于将渲染从服务器端转移到浏览器端。

而服务器专注于服务并提供数据接口。

浏览器端呈现的优势

我们都知道浏览器端呈现的好处，例如

1.摆脱Java模板引擎中业务逻辑和呈现逻辑的耦合和混乱。2.对于多终端应用，接口更容易。不同的模板在浏览器端匹配，呈现不同的应用。3.页面渲染不仅仅是html，前端渲染可以更容易地以组件(html js css)的形式提供功能，使得前端组件不需要依赖服务器生成的html结构。4.摆脱对后端开发和发布过程的依赖。5.便于联合调整。

浏览器端呈现的缺点

但是在享受好处的同时，我们也面临着浏览器端渲染带来的弊端，比如：

1.模板在不同的库中是分开的。有些模板放在服务器端(JAVA)，有些放在浏览器端(JS)。前后模板语言没有连接。2.开始渲染前需要等待所有模板和组件都加载到浏览器上，不能立即打开。3.第一次进入时会有白屏等待渲染，不利于用户体验。4.开发单页应用时，前端Route与服务器端Route不匹配，处理起来非常麻烦。5.重要内容在前端组装，不利于SEO

反思前后的定义

其实回过头来看，当我们把渲染工作从服务器(Java)拉到浏览器(JS)的时候，我们的目的只是为了明确前后方的职责分工，浏览器渲染是没有必要的。

只是因为在传统的开发模式中，浏览器是从服务器出来的，所以前端的工作只能局限于浏览器。

所以很多人认为后端=服务器前端=浏览器端，就像下图一样。

在淘宝UED目前进行的中途岛中途岛项目中，通过在JAVA-Browser中间设置NodeJS中间层，我们尝试再次区分工作职责的前端和后端的分界线，而不是硬件环境(服务器浏览器)。

因此，我们有机会共享模板和路线，这也是前端分工中最理想的状态。

淘宝中途

在中途岛项目中，我们将前端和后端的分割线从浏览器移到了服务器。

有了一个易于前端控制并与浏览器共享的Nodejs层，可以更清晰地完成前端分离。

你也可以让前端开发决定最适合不同情况的解决方案。而不是一切都在浏览器端处理。

职责分工

中途岛不是前端想抢后端饭碗的项目。目的是把模板的模糊区域切清楚，得到更清晰的职责划分。

后端(JAVA)，专注于1。服务层2。数据格式和数据稳定性。业务逻辑前端，重点关注1。UI层2。控制逻辑和渲染逻辑3。交互和用户体验，而不是拘泥于服务器和浏览器的区别。

模板共享

使用NodeJS，后端学生可以专注于JAVA层的业务逻辑和数据的开发。前端学生专注于控制逻辑和渲染的开发。并选择这些模板在服务器端(NodeJS)或浏览器端呈现。

使用相同的模板语言XTemplate，相同的呈现引擎JavaScript

在不同的渲染环境中(服务器端、个人电脑浏览器、移动浏览器、网络视图等)。)，则呈现相同的结果。

路线共享

并且由于NodeJS层的存在，路由可以被更仔细地控制。

如果需要在前端做浏览器端路由，可以同时配置服务器端路由，这样可以在浏览器端或者服务器端换页，可以得到一致的渲染结果。

同时也处理了SEO的问题。

模板共享的实践

通常当我们在浏览器端渲染一个模板时，这个过程只不过是

加载模板引擎(XTM普莱特，榨汁机，处理杆等。)在浏览器端加载模板文件。这些方法可能包括使用脚本类型='js/tpl './script打印在页面上，使用模块加载工具，加载模板文件(KISSY、requireJS等)。)获取其他数据，并使用模板引擎生成html并将html插入指定位置。从上面的过程可以观察到，如果要跨终端共享模板，重点其实是一致的模块选择。

市场上有很多流行的模块标准，比如KMD、AMD、CommonJS。只要NodeJS的模板文件可以通过一致的模块规范输出到NodeJS，就可以做基本的模板共享。

以下系列文章将进一步讨论模型的代理和共享。

个案研究

因为中途岛的中间层，过去有些问题有比较好的答案，比如，

案例1复杂的交互式应用程序(如购物车和下单页面)

状态：所有HTML都在前端呈现，服务器只提供接口。问题：进入页面时，会出现短暂的白屏。答：第一次进入页面，在NodeJS上渲染整个页面，后台下载相关模板。在后续的交互操作中，使用相同的模板在浏览器端完成本地刷新，产生相同的结果

案例2单页应用

场景：使用客户端MVC框架在浏览器中改变页面。问题：渲染和页面更改在浏览器端完成。直接输入网址或f5刷新时，不能直接呈现相同的内容。答：当浏览器端和NodeJS端共享相同的Route设置，浏览器端更改页面时，当浏览器端更改Route并渲染页面内容，直接输入相同的网址时，页面框架页面内容在NodeJS端渲染。无论是浏览器端换页还是直接输入同一个网址，看到的内容都是一样的。除了增加经验和降低逻辑复杂度。也解决了SEO的问题

案例3纯浏览页面

情况：页面只提供信息，很少或者没有交互问题：html在服务器端生成，css和js放在另一个位置，相互依赖。答：通过NodeJS，未来如果需要扩展成复杂应用或者单页应用，可以很方便地转移对html css js的统一管理。

案例4跨终端页面

情况：同一个应用需要在不同的端点呈现不同的界面和交互问题：html管理不容易，往往在服务器端生成不同的html，而浏览器端需要做不同的处理解决方案：跨终端页面是呈现问题，由前端统一处理。通过NodeJS层和后端服务，我们可以为这种类型的复杂应用设计最佳解决方案。

摘要

过去出现的AJAX、客户端MVC、SPA、双向数据绑定等技术，都是试图解决当时前端开发的瓶颈。

NodeJS中间层的出现也在尝试解决前端局限于浏览器的局限。

本文重点介绍了前端和后端之间的模板共享，希望能引起更多的关注。我们将与您讨论如何改进我们的工作流程，以及如何与后端合作，使前端在NodeJS中间层的框架下更好地工作。