这是一个创建于 681 天前的主题，其中的信息可能已经有所发展或是发生改变。
第 1 条附言 · 2023-01-13 10:53:07 +08:00
老铁们来点意见，交流交流
第 2 条附言 · 2023-01-13 19:18:59 +08:00
解释好累。我寻思整篇 blog 也没说这就是全部啊，不管是标题还是副标题，这不都表示这是一部分？大标题那里明显带着 "-1"。
而且评论这么问，让我觉得他们的微前端项目看起来不包含我提的这部分。可以理解，毕竟有可能他们是直接启动一个微前端项目，而不是我这样的迁移。
而且评论这么问，让我觉得他们的微前端项目看起来不包含我提的这部分。可以理解，毕竟有可能他们是直接启动一个微前端项目，而不是我这样的迁移。
 |
1
Azuer 2023-01-13 10:58:14 +08:00  3
微前端是个什么概念？
|
 |
2
hucw21750 2023-01-13 11:03:48 +08:00
我们公司产品后台管理应用已成为巨石应用，一直想搞微前端分解下业务，奈何人力时间都不足，都是在脑海中实践。
|
 |
3
musi 2023-01-13 11:07:53 +08:00
“你可能并不需要微前端”
|
 |
5
lrwlf 2023-01-13 11:11:27 +08:00
你说的这几点不是大仓吗，跟微前端有什么关系么
|
 |
6
horizon 2023-01-13 11:12:31 +08:00
我也不懂什么是微前端。。
|
 |
7
MorningStar0 OP |
|
8
musi 2023-01-13 11:18:08 +08:00
@MorningStar0 #7 你这微前端的部分都还没开始怎么就开始吹微前端了，还有现在微前端已经玩烂了，阿里又开始说“你可能并不需要微前端”了
|
|
9
MorningStar0 OP @musi 呃我理解，微前端也包含我提到的这部分吧，而且我就是记录下自己实践的部分，blog 中提到的后续计划，已经在开发中了。
通过网络动态引用的部分已经完成了，只是其他计划还没有完成，我觉得不适合单独写一个专题。 动态引用的代码，在仓库中的 dynamic-import module 中 |
|
10
lrwlf 2023-01-13 11:25:29 +08:00
@MorningStar0 似乎不是想要像传统“微前端”那样拆分子应用，而是更细化到组件和 SDK 。有点像“模块联邦”，可以参考 https://tnfe.github.io/hel/
|
|
11
musi 2023-01-13 11:25:35 +08:00
@MorningStar0 #9 现在市面上的为前端框架重点除了是远端加载更重要的是代码隔离，让远端的代码运行在一个沙箱环境之中，这个基本上是工作量的大头，远端加载的话其实是比较简单的
|
|
12
MorningStar0 OP @MorningStar0 #9 至于微前端玩烂了，还有 ali 的技术观点，其实不太影响我。总的来说 我的需求对于微前端时刚需，这点是指我在 blog 中提到的
“对于不同用户，同一个包需要在运行时 提供不同的版本”。 |
 |
13
yaphets666 2023-01-13 11:27:20 +08:00
@musi 远端代码运行在沙箱是什么意思？前端代码都是运行在浏览器啊
|
|
14
musi 2023-01-13 11:29:14 +08:00
@yaphets666 #13 就是在浏览器里面构建了一个 js 沙箱，去运行不受信的代码，或者说不能对主应用造成干扰
|
|
15
MorningStar0 OP @musi 沙箱还是需要的，我这里目前的方案是，将通过 new Function 加载的远程库，把它的 context 绑定到一个 object 下，这个 object 提供了一些允许调用全局变量。
|
|
16
MorningStar0 OP @lrwlf 可能我这个 blog 中给出的例子确实更像模块联邦😂
|
 |
17
yikyo 2023-01-13 11:32:04 +08:00
@yaphets666 微应用级别的隔离，防止几个微应用间冲突。沙箱的话，核心代码只有几行，你可以看一下 神光的编辑秘籍 近期那篇微前端方案那篇文章
|
 |
18
zhaol 2023-01-13 11:56:56 +08:00
微前端最大的问题就是信息传递，贼麻烦，真的。应用一但多起来，共享状态的管理真的很麻烦，debug 的时候也很头疼。主应用和微应用以及不同微应用之间的交互也麻烦，能别微前端就别微前端。不过学学技术可以，业务中尽量少用
|
|
19
MorningStar0 OP @zhaol 确实比较麻烦，我的解决方案是将带有 context 的功能，作为单独的 module 打包，然后在构建的时候，保持这个 context 的唯一实例。
|
 |
20
alexsunxl 2023-01-13 12:24:52 +08:00
你这个理解的微前端是不是有点问题。你这属于是组件优化层面。
不是说 monorepo 就是微前端。 微前端并不是解决 项目大的问题啊。 我理解的微前端和微服务的核心关键词都是一个： 技术栈无关。 你得把 vue2 ，vue3 ，angular ，react ，原生 js 通过路由层能揉在一起的才叫微前端。 微服务也一样的。每个团队能选自己的技术栈（ go ，java,python...)和框架，最后只要按规范接入平台作为一个完成服务就行。 |
|
21
alexsunxl 2023-01-13 12:26:12 +08:00
|
|
22
alexsunxl 2023-01-13 12:26:38 +08:00
统一 -> 同意
|
|
23
MorningStar0 OP @alexsunxl 这里源引 https://micro-frontends.org/来解释下。
> Techniques, strategies and recipes for building a modern web app with multiple teams that can ship features independently. 翻译：微前端是一种多个团队通过独立发布功能的方式来共同构建现代化 web 应用的技术手段及方法策略。 我可能更侧重独立发布功能和#12 中提到的需求 |
|
24
MorningStar0 OP @MorningStar0
@alexsunxl 这不意味着我否定技术栈无关这点，但我确实不想引入其他技术栈。虽然这在我通过#15 层提供的沙箱方案可以解决。 并且我觉得不一定要严格要求通过 **路由层** 解决 collection 的问题。 |
 |
25
anonymous2351d00 2023-01-13 16:52:29 +08:00
微前端在 Angular 中的应用
https://github.com/worktile/ngx-planet |
 |
26
weijiagege 2023-01-13 16:56:20 +08:00
这不是 monorepo 前端实践吗，怎么就成微前端了
|
 |
27
corianderHunter 2023-01-13 17:48:16 +08:00
这是哪门子微前端，而且感觉完全没必要用 monorepo ，应该是构建优化。
|
|
28
MorningStar0 OP @weijiagege
@corianderHunter 一个问题，你们的微前端项目不包括 monorepo 么？也不包括构建方式更改？ 而且标题这里的 “从 CRA 将 react 项目迁移成微前端项目-1” 和副标题这里的 “从 CRA 将 react 项目迁移成微前端项目 —— 目录结构的确定和构建方式的更改”，这俩说明不了这篇是主要讲目录结构和构建更改的吗？ 然后这个主题提到的 “在主项目中引用抽离的项目”，引用子应用的方式，包括我在#15 、#9 的回复，应该不难看出这个项目拆分完成的结果吧 |
 |
29
IvanLi127 2023-01-15 02:29:47 +08:00 via iPad
这内容确实和微前端没啥关系。。。另外我感觉微前端是个伪概念。。。
|
Select Language