webpack 后端渲染-浅谈后端如何在前端渲染开发模式的夹缝中生存

也想出现在这里？点击联系我~

立即下单

进入商城

进不了网站？换个网络试试！

前言

近年来，后端领域发展迅速，前后端分离已成为行业共识。 各种管控系统（对B）和SPA不值一提，但仅针对展示类项目，对于SEO来说，还是需要依赖服务器端的Render html。

以前也尝试过填SPA的SEO，现在看来效果达到了，而且工作量也大大减少了（因为前端用的PHP不能同构）。

虽然我们无法改变依赖服务端渲染的现实webpack 后端渲染，但我们可以勇敢地拥抱它，用强大的后端利器（又名webpack）啃碎服务端模板层！

初步认识的两个阶段

整个后端项目，从本文主题来看，可以分为两个阶段：

纯静态页面开发阶段

这个阶段，所有的开发都和静态网站一样。 页面按照UI稿进行裁剪，交互做得很好。 可以使用ajax来请求API。 与前端唯一的合作点就是API文档。

传统的后端工作到这里就结束了，但是对于我们来说，当前的结果并不是我们最终的交付； 因此，请注意，我们在这个阶段可能会“偷懒”。 比如一些显而易见的事情应该由服务器端循环生成的部分（产品列表、文章列表等），我们写一次就可以了。

动态页面重构阶段

这就是所谓的“页面集”。 传统上，它是由前端完成的。 其实前端也很惨。 毕竟模板不是我们自己写的。 有的时候还是需要修改的，这就是我们后端需要努力的地方。 为战斗而生。

这个阶段我们的主要工作是根据前端模板引擎的规则编写模板变量占位符。 当然，循环输出和逻辑判断也不会缺少。 另外，还可能需要用到一些前端定义的函数。 取决于项目需要。

在两个阶段之间来回

这两个阶段不一定完全独立，必要时可以来回。

那么什么时候才叫“必要”呢？ 比如，当你把原来的静态页面改造为需要前端渲染的页面模板时，你发现前端此时还没有准备好对应的模板变量，需要对页面的UI部分进行更改这次。 ，那么你就会很被动，因为修改后的页面模板根本无法运行。 有两种解决方案：

装修开始

本文重点介绍如何将静态页面转化为前端渲染所需的模板。

根据前端模板命名规则生成对应的模板文件

根据前端框架或它们使用的其他要求，不同的项目将具有不同的模板放置目录结构。 那么，如何创建前端所需的目录结构呢？

在静态网页阶段，我习惯将html/css/js根据所属页面放入各自的目录中（public css/js其实是放在public目录下的）。 查看HtmlWebpackPlugin配置：

pageArr.forEach((page) => {
  const htmlPlugin = new HtmlWebpackPlugin({
    filename: `${page}/index.html`, // page变量形如'product/index'、'product/detail'
    template: path.resolve(dirVars.pagesDir, `./${page}/html.js`),
    chunks: [page, 'commons/commons'],
    hash: true,
    xhtml: true,
  });
  pluginsConfig.push(htmlPlugin);
});

改造阶段，放置在前端指定位置：

pageArr.forEach((page) => {
  const htmlPlugin = new HtmlWebpackPlugin({
    filename: `../../view/frontend/${page}.php`, // 通过控制相对路径来确定模板的根目录
    template: path.resolve(dirVars.pagesDir, `./${page}/html.js`),
    chunks: [page, 'commons/commons'],
    hash: true,
    xhtml: true,
  });
  pluginsConfig.push(htmlPlugin);
});

此时我的模板目录结构是这样的：

│  
├─alert
│      index.php
│      
├─article
│      detail.php
│      index.php
│      
├─index
│      index.php
│      
├─product
│      detail.php
│      index.php
│      
└─user
        edit-password.php
        modify-info.php

这里需要注意的是，我的后端项目目录实际上是作为前端目录中的子目录存储的，这样就可以通过相对路径来确定模板文件存储的根目录位置。

处理站内链接

对于站内链接，我建议使用后端模板中的函数来适应两个阶段：

{
  /* 拼接系统内部的URL */
  constructInsideUrl(url, request, urlTail) {
    urlTail = urlTail || '';
    let finalUrl = config.PAGE_ROOT_PATH + url;
    if (!config.IS_PRODUCTION_MODE) {
      finalUrl += '/index.html' + urlTail;
      return finalUrl;
    }
    return `<?php echo cf::constructInsideUrl(array('module' => '${url}'), $isStaticize)?>`;
  },
};

在后端模板中使用它：

<a href="<%= constructInsideUrl('index/index') %>">
  <%= require('./logo.png') %>">

这样，就可以在静态页面阶段和前端渲染阶段分别生成相应的超链接。 而且，在前端渲染阶段，我们生成的不一定是完整的URL。 我们可以像我上面的代码一样生成调用前端功能的模板代码，从而灵活满足前端的一些需求（比如我的项目如果需要静态化，那么静态站内链接将与动态渲染的不同）。

处理模板变量

虽然这个我没什么可说的，无非就是输出变量、循环输出变量、判断条件输出变量、调用前端（模板引擎）函数根据前端的规则调整输出变量——结束模板引擎。

关键是我们需要得到一个模板变量文档webpack 后端渲染，这个文档和API文档类似。 它实际上是一个前端数据合约。 有了这个文档，我们就可以在前端没有完成的情况下进入动态页面重构阶段，根据内容实现模板变量mock。

模板布局渲染权纠纷

关于借助模板布局系统复用多个页面的公共部分，我在上一篇文章中已经提到过。 我设计这个系统的想法来自于前端模板渲染。 那么，在模板布局系统前端和前端都可以实现的前提下，我们应该选择什么呢？ 我的答案是，前端一定要吃！

从后端角度来看：

从前端的角度来看：

总结

在前端渲染项目中使用webpack多页面应用架构是绝对可行的，但是不要让老顽固们欺骗你回到传统的后端架构。