前端什么阶段需要开始考虑组件化了？
项目初始化的时候。
前端在做需求拆分的时候就应该考虑组件化了。
前端组件我一般分成两种：
一种是和数据层无关的通用组件，形式是根据业务需要对AntD这类组件库的封装，能更快的实现一些基础通用的业务功能。这类组件其实可以在开发过程中根据需要再进行抽取，一般会在开发阶段的中间阶段基本成型，后面再根据需要增加。
另一种是与数据层绑定的业务组件——以组件的形式去实现业务的最小独立功能。这个事情应该在拿到需求的做分析的第一时间就开始做。由于业务功能会被拆的很细，让所有组件共享业务数据的数据层就很重要了。我一般把业务相关的功能尽可能的放到数据层中，这样组件只需要承载交互相关的逻辑，组件会更清晰。这样最大的好处是防止那种上千行混合著业务逻辑和UI逻辑的屎山组件出现，后续的维护成本和重用性都会有巨大的提升。当然这种做法也有问题，如果把业务组件抽取出来给多个项目共用的时候会有额外的成本，但是这种情况我没有遇到过，如果有人遇到过大量的这种需求，欢迎评论讨论做法。
总体来说，组件化是类似于后端服务拆分的工作，对提高做业务的效率有奇效，所以应该一开始就开始考虑。
写第一行代码之前，就要考虑组件化了。
甚至夸张点说，现代的前端项目，你可以认为全都需要组件化。
组件化可以被视为现代前端的政治正确（原意，无讽刺意味）。
没什么好考虑的，唯手熟尔。我只能说，当你的经验到了一定程度，常常需要考虑的是，什么时候不应该组件化，而是用复制粘贴。
我的做法是，先不做组件全部直接写，直到你出现一些可以复用的东西的时候，这时就可以拷贝粘贴将原来代码变成组件，这样可以避免某些无需复用的东西因为写成组件增加了复杂度
如果做得到的话，尽可能的组件化，哪怕只有一个地方用到，不需要代码复用。组件化除了代码复用外，很大的好处是让代码低耦合，很灵活，像积木一样。如果功能不需要了，把组件拿掉就好了，就像他从来没来过。如果没有组件化，你拿掉一个功能，需要考虑对其他部分的影响。
当你考虑维护和需要复用的时候
当你觉得经常做一下重复的工作的时候就应该考虑组件化了，
讲道理，按原子设计系统，在设计UI的时候就要考虑了。
当重复性的功能和ui的时候
组件化就解决的是重复劳动
简单理解 你有一个弹出框用来显示列表 每个页面都用 那你是每个页面都写一个还是组件化直接复用？具体情况具体分析 组件化了能给自己偷懒那就需要组件化。如果不能偷懒还增加了工作时间那么就不需要组件化
写之前就可以考虑了，以后是否有可能复用。
或者是，同样的业务场景遇到2次以上，就可以考虑组件化了。
楼上说的有些虚无缥缈了
我来说一些实际的
比如一个后台管理系统
一个表格在UI中反复出现
并且样式不能用常见的UI框架替代
那么这个时候是不是该把这个表格改完样式后,变成一个公用的组件
----------这是公用组件部分
在实际业务逻辑中,通常一些弹窗,tab栏里面的内容 一般会作为组件嵌入主页面,否则所有代码都写在一个文件内代码的可读性和冗余程度就会让维护代码开销很大
----------这是页面私有高耦合组件部分
当然"完成功能就好"这种想法,也是OK的
但是代码如何可以更加优雅,是一个程序员的更专业的素养
推荐阅读：
