• 大面积使用Vue/React还是适合SPA,本以为Rails后端渲染也没问题的,结果带来了太多不必要的麻烦。

  • 谢谢。Rails渲染和SPA都有自己的合适的场景,不拘泥于框架、找到适合自己的解决方式才是最实际的。

  • 是的,我所遇到的问题是如果想要后端渲染,就不应当过度依赖Vue。但是有的时候还是略无奈啊,现在很多开箱即用的UI库(material、element、ant-design)几乎都是基于Vue/React/Angular实现的。既然选择重度依赖前端框架,其实就不该再强行依赖Rails在前端方面的传统优势了。

  • 😅

  • 最近做过webpacker搭配vue的尝试。可以给点简单的建议。先简单比对下后端渲染和前后端分离。

    后端渲染 + 前端框架

    优点

    • 前后端代码都在同一个项目中,方便调试。部署也只用部署一套代码。
    • 在Rails controller中定义的variables可以在template中直接使用,省去JSON API格式的定义。
    • 没有SEO和首屏加载的问题

    缺点

    • 开启了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的数据做一道转换。

    前后端分离

    优点

    • 完全使用前端的解决方案,后端只提供API,具体操作如何、路由怎么跳转完全由前端控制。
    • 如果使用第三方UI库,不用担心一些由于后端渲染和turbolinks导致的问题。

    缺点

    • SEO。但是这个问题我们需要根据自己的场景去看待。如果做的是一个内容展示型的网站,SEO十分重要,这时用单页应用就必须通过SSR这样的方式去做处理。但是如果我们做的是一个管理系统(CRM/OA等),大多数的界面都是在用户登录之后才能访问的,也就是说大多数界面我们并不需要SEO。这时候我们可以将一些公开的界面(如产品介绍页面)做成后端渲染的,登录之后的做成单页应用。SEO也不再是问题。
    • 首屏加载。首屏加载是每一个SPA都需要面对的问题。也是SPA被诟病的众多原因之一。但是现在的主流前端框架在build production之前都会做uglify之类的操作减少js文件大小,除此之外使用Lazy Loading、server上开始gzip之后最后得到的资源文件大小并不大。
    • Rails只是一个API,我们不能使用Rails的很多便利的东西(Helper,Form等)

    结论

    可能你看到这里会觉得我更加倾向于SPA。但事实上我所提到的在使用后端渲染 + 前端框架的这些缺点,都是因为在开始项目之前我不希望使用SPA,所以还是想像使用jQuery一样使用Vue,所以还是采用了后端渲染的方式之后发现的。我在项目中为了能快速搭建UI,使用了一个Vue的第三方组件库,开始时并没有觉得有什么问题,但是随着项目深入之后便发现了我之前提到的这些问题。为了解决这些问题反而花了更多的时间。

    但是这并不代表SPA就一定是更好的选择。技术选型不能脱离我们的业务和环境。关于究竟是SPA还是后端渲染,我想给出我自己的一些建议:

    • 如果你有很多重前端的场景,一些业务场景重度依赖于React/Vue,或者说你使用了一些基于React/Vue的UI库。为了减少你处理一些不必要的麻烦的时间,建议直接上SPA。
    • 如果你仅仅是用React/Vue处理某些交互麻烦的地方,如果React/Vue对当前项目来说只是jQuery般的存在,后端渲染会是更好的选择。
    • 最最重要的是,选择适合当前团队的方案。如果你现在的团队成员有过SPA的经验,并且更适应SPA的开发方式,那么前后端分离无论是对于开发效率还是质量来说可能都是更好的方式。反之,如果你的团队更熟悉传统的后端渲染的方式,为什么就一定要为了前后端分离而分离呢?前后端分离只是一种不同的开发方式,前后端分离可以实现的业务使用后端渲染一样可以实现。

    关于前后端分离的问题,社区里曾有过不少讨论。其实无论是前后端分离还是后端渲染,我们的目的都是为了解决问题,二者没有孰好孰坏之分。你不必因为现在很多项目都选择了前后端分离就一定要去跟这个潮流,放弃后端渲染。同时,也不必像我一样,在场景过于依赖前端框架的时候硬要上后端渲染(这里也有我个人的原因,最近一年的工作很多是和前端相关,对一些单页应用中的业务场景更加熟悉一些)。找到最适合自己和团队的方式,高效高质量地进行开发才是我们的最终目的。

  • 赞一下。我最近也在学习vue,也是拿ruby china练的手。发现vue中没有比较好用的分页组件(类似于react-paginate这样的),楼主demo中也是自己做了简单的处理。所以我就自己参考react-paginate写了一个简单的pagination组件,做了一个npm包,还算好用。楼主可以试试。
    github: https://github.com/lokyoung/vuejs-paginate

  • #6楼 @pengedy 谢谢,其实就是篇Getting Started的教程,整理下分享给大家~

  • #5楼 @42thcoder 谢谢推荐,之前没有尝试过gitlab,准备深入了解下!

  • #3楼 @ACzero 我们正好有项目有这样的需求,我最近就弄了下😀

web开发者。