next.js弃坑总结

关键字:next.js

next.js接触

接触next.js的过程在next.js记录中已经说过了,主要是在自己搭建后台渲染过程中,使用了web-isomorphic-tools,而它官网中,推荐使用其进化版本universal-tools或者使用集成了universal-tools的next.js。而自己搭建的渲染,跳过了无数坑之后,渲染Materila-Ui组件时失败,况且不知道越过这坑后边是否还有坑,索性研究一下next.js.

next.js是一个后台渲染的MPA(多页面应用)

next.js优点

  • 后台渲染做的不错
    对Material-Ui支持不错

  • 代码切割做的不错
    本身是不过加载页面中不用的component,也可以手动进行动态加载,并支持prefetch(预取)的功能,提高加载的速度。

  • 动态数据加载做的可以
    由前端服务器向api server获取数据使用getInitPrepoty的方式不错

next.js缺点

这里的缺点是针对我们应用的场景而言

  • 文件系统路由的方式不太适合
    虽然它支持定制路由,但也仅是做了as,类似于一个别名,还需要服务侧做转换。
    并且由于文件系统路由,使它内部仅支持用query方式(url?key=value)传参,若需要param方式(/:userId),需要使用定制url。

  • 对componet不太友好
    在面临选择page还是componet时,next.js偏向与page。比如通过link导向一个page,然后在page进行一些操作之后,通过component切换的形式来做一些view的切换,这时候如果想再逆操作时,没法通过点击link的方式进行切换,只能自己控制。link发现地址没变,点击不会响应。

  • 传参问题
    由于更多的页面,在传值问题上存在更多的挑战。使用react的component,可以愉快的使用向下流的传值,而页面只能在地址中增加一些id,然后在页面内部再次去获取数据,这样效率比较低一些。

结语

与同事讨论之后,我们觉得,next.js更适合向博客、新闻等使用场景,不太适合写数据交互多的场景,这样就准备弃用了。
如果非要用next.js来写的话,感觉可以将next.js做一个后端渲染的活,然后在next.js之上移植react-router,由MPA转换成SPA,这方面的资料在next.js github的issue中可以找到一点,有兴趣的朋友可以考虑一下。