说明 其实你说的是一个问题,多入口就是多页应用;目前 SPA 应用非常火热,一般项目用 SPA 应用就可以搞定了,但是当这个项目变的越来越大或者说架构之初就知道项目是一个企业级的庞大应用,这时候我们在架构之初其实就可以考虑做多入口,也就是开发一个多页应用,利用多页应用来做更好的模块化,也就是 微应用,前端微架构 的一种方式 什么时候用多页应用 举个例子 我有一个项目,在 架构之初选择了 SPA 的方式,开发时我已经做了很好的模块化划分,比如有模块A、模块B、模块C、...、模块xxx,一句话我有很多个模块,项目一步步的进行开发,结束,完美上线。这时候突然又来一个项目,这个项目的需求和之前的项目需求一样,只是它只需要其中的部分模块,比如模块A、模块B、模块C,其它的都不要,这时候我们怎么做? 很开心啊,发现上一个项目代码居然可以复用,其实就是把自己的产品卖给不同的甲方(客户),只是每个客户的需求不一样;继续正题,我们会从 Git 上 fork 出一个分支,然后在该分支上做改动,比如改配置文件、或者路由文件、或者数据库(将各个模块信息存到数据库,做灵活的权限管理),总之一通改,删掉不需要的功能,嗯,完成,然后一通测试,没问题,交给甲方,哇,很方便啊,so easy !! 过了一段时间,又来了一个项目,和第二次的项目情况类似,于是我们重复第二次的过程,fork 分支,改配置、改代码等等操作,删除不需要的功能,完成。 ....就这样过了很久很久,做了很多很多的项目,回过头来看看,发现,我的妈呀,我的 Git 服务器上怎么这么多项目分支,然后发现,诶?这个分支是干嘛的?项目 B 的?特别是碰到了这种情况,各个项目需要做维护,发现有一个功能模块,比如模块A有一个bug,于是噌噌噌的改完,然后提交,突然发现一个问题,我去。。。,我好像要把这个改动同步到所有分支诶,心里早已xxx,什么玩意儿,怎么感觉维护有点困难呢?算了,歇息吧,明天来搞吧。。 这时候发现?是不是有点累? 其实这种情况,还是挺常见的,这个时候应该考虑是不是有更好的方式来解决,比如重构?微前端架构怎么样?微应用的方式呢?嗯,好像不错,一番验证,嗯,可行,开始动手。 微应用 我们重构时的架构选择微前端的中的微应用方式,其实就是配置多个入口,一个入口是一个模块,这个模块其实就是一个应用,比如一个Vue应用,这里推荐 Vue-Cli3 的 pages 选项,开发完毕以后,我们再会过头来看之前的案例,是不是发现不同的项目我只需要配置webpack.config.js(vue.config.js)的入口文件就好了,打包完成,保险起见还是做一做测试,其实只要模块化划分的够好,产品没问题,打包出来的子产品就问题,这样会发现,不同的项目在打包时就配一下入口文件即可,我们也只需要维护一份代码(就自己的产品),做持续的维护、迭代即可,不再碰到之前案例中坑爹的事情,这种架构是不是想想就很诱人 !!
说明
什么时候用多页应用
举个例子
微应用