https://github.com/reactjs/react-rails#server-side-rendering
前后分离也在向前走,前端代码 (Vue, React) 服务端渲染解决了首屏加载慢,和搜索引擎爬不到你的网站这两个痛点,这两个大问题解决的情况下,是否能使SSR-SPA
在webpacker
的加持下成为 2018web 开发的终极方案
react 没有太多了解,不过我最近在用 vue
说到这个问题,其实首先应该区分一下 服务器端渲染 vs 预渲染 (SSR vs Prerendering),这是两个不同的概念
如果只是预渲染(Prerendering),那其实还是前后端分离的,没有什么可说的
如果是 SSR,那我就会觉得是兜了一个大圈子,最后还是来解决了一个和 turbolinks 类似的问题,也大概可以算是殊途同归了
为什么是『大概算是』呢?因为这两者导致的结果是不一样的,turbolinks 解决了 SPA 的问题,但是它没有去解决前端代码怎么去架构的问题,虽然也有像 tao_rails 这样的框架,但是它也只是在尝试解决问题,它能迎合偏后端的程序员或者全栈程序员的口味,却很难让偏前端的程序员觉得『干,用这个写起来真的好爽~』
编程使我快乐不只是 ruby 的专利
因此,基于『写起来爽』这个初衷来看,你觉得选什么方案合适呢?
就目前看来,webpacker
的用处应该还是拿来替代以前拿jQuery
撸的部分,或是大网站里面比较小的子系统,网站的主体还是 simple_form + haml + turbolinks + bootstrap
最近做过 webpacker 搭配 vue 的尝试。可以给点简单的建议。先简单比对下后端渲染和前后端分离。
开启了 turbolinks 的情况,需要在 turbolinks 相应的 callback 中销毁和重新注册相关组件。但是如果你使用了基于 Vue/React 这些前端框架的第三方 UI 库,某些第三方组件在 turbolinks 开启的情况下会出现一些意想不到的的问题。
表单操作方面,Vue/React 不能直接在 Rails 原生的表单中使用。如果还是使用 ujs 的方式去处理表单,遇到需要 Vue/React 去处理某些数据绑定的操作,也还是不方便。如果使用 Vue/React 去构建 Form,提交表单只能发起异步请求,不会有 Rails 原生表单的行为,一些本来交给 Rails 处理的行为(例如在 controller 中 redirect)需要交给前端处理。而且这样的行为在一个非前后端分离的项目中可能会显得比较怪异。
例:如果使用了 Vue 去提交一个表单,想在提交成功之后做 redirect。由于是一个异步请求,Rails 并不能帮助我们进行 redirect,只能在前端使用window.location
这样类似的方式进行 redirect。这个行为既不 Rails 也不 SPA。(SPA 中通常使用 Router 进行跳转)
前后端数据命名格式不一致。在 js 中,命名的规范是camelCase
,在 Rails 中是下划线的形式。如果你有过 SPA 的开发经验,在写前端逻辑时应该会倾向于camelCase
,所以我们还是需要对 Rails 的数据做一道转换。
可能你看到这里会觉得我更加倾向于 SPA。但事实上我所提到的在使用后端渲染 + 前端框架的这些缺点,都是因为在开始项目之前我不希望使用 SPA,所以还是想像使用 jQuery 一样使用 Vue,所以还是采用了后端渲染的方式之后发现的。我在项目中为了能快速搭建 UI,使用了一个 Vue 的第三方组件库,开始时并没有觉得有什么问题,但是随着项目深入之后便发现了我之前提到的这些问题。为了解决这些问题反而花了更多的时间。
但是这并不代表 SPA 就一定是更好的选择。技术选型不能脱离我们的业务和环境。关于究竟是 SPA 还是后端渲染,我想给出我自己的一些建议:
关于前后端分离的问题,社区里曾有过不少讨论。其实无论是前后端分离还是后端渲染,我们的目的都是为了解决问题,二者没有孰好孰坏之分。你不必因为现在很多项目都选择了前后端分离就一定要去跟这个潮流,放弃后端渲染。同时,也不必像我一样,在场景过于依赖前端框架的时候硬要上后端渲染(这里也有我个人的原因,最近一年的工作很多是和前端相关,对一些单页应用中的业务场景更加熟悉一些)。找到最适合自己和团队的方式,高效高质量地进行开发才是我们的最终目的。
我突然想明白了为什么会在 ssr 和 spa 纠结了半天,因为 simple_form,haml, turbolinks 这些个 rails 组件太好用了啊,如果是其他语言的框架,根本就不用纠结,全上 spa 了