qingo
commented
3 years ago 上文提到一个有意思的概念，组件即服务，对这个概念的理解抛个砖：
- 前端的封装和集成可以分为三个层次，组件、模块、应用，事实上比较虚的三层，这三层对于React来说都是组件，大概就是职责范围不同，可能会和路由配置有关联等，但是这些其实都无所谓，都是二次封装的概念。
- React现在主张一切都是组件，从App到最顶端的一个字，一个span，一个链接来说都是组件，嵌套大法是React强大而统一的绝招。
- 应用层的集成，也就是
render(<App/>, dom),这种模式，其实市面上有很多致力于跨框架的前端微服务，我感觉其实是微应用，对这个方面不太感兴趣，跨框架一般是不同系统的整合了。 - 组件层面的集成，往往是
<Component prop1={value} {...props}>{Children}</>，组合组件更为复杂，起威力更为巨大，还有context、hook等方式此处不做赘述，如2中所说，React应用其实是通过组件调用等方式集成不同层级的组件从来集成为整个应用。 - 综上，React应用本质是由不同层级的Component集成为App，根据不同的业务展示和交互的需要，不同层级的状态集成到不同层级的Component中，所以合理的React应用，其状态和数据所在层级的设计恰当，可以让其组件树的交互更为合理。
- 展望一下，如果能做到组件即服务，也就是说可以从不同的层级集成，可以通过传递类似
uri：component?condition1=value1&condition=value2这种形式获取到需要的组件，然后集成到应用中，其实是一种蛮有意思的模式，很明显不是为了SEO，不同层级的Component根据其状态需要通过uri调用的形式获取到应得的组件配置，完成其服务。这可能是组件即服务的理想状态吧。
12月末：
嗯。。。又是个搞事情的冬冬；
先理解下使用的场景
1. 获取数据
实现一个简单的page，用到了多个组件嵌套，每个组件都可以通过fetch去获取数据，当然可以在最顶部获取所有数据再渲染。
a. 每个组件都自己获取数据，没有问题，但需要发茫茫多的请求；（性能）
b.顶部获取数据，没有问题，就是维护起来会很累；（可维护性）
所以，Server Components 解决了数据获取的问题，让数据和component在服务器端进行组合，直接展示；
2.ssr
服务器端渲染免不了提一下ssr，ssr最早起源于解决首屏白屏和seo的问题，也就是服务器端返回的是html；
Server Components 返回的是序列化的“指令”，所以和ssr没半毛钱关系；
另外纠结了下“渲染”两个字的含义，Server Components 算不上是服务器端渲染，我们常说的渲染往往支持转换为html，Server Components 应该理解为build更合适，build成序列化“指令”；
啊，这是个性能不错、可维护性强的解决方案，用户体验？？额，我感觉用户体验就体现在前两者上面了。 那么，沉思。。。这东西到底有什么好的使用场景呢？？？
1.组件即服务
以前拿数据只能通过后端提供的api，还要自己去组装，现在不用了，直接拿来，例如图表；
2.报表（BI）
组件即服务的延伸，可以直接获取报表；
3.组件中台
业务中台，从数据中台进化为组件中台；
4.开箱即用
5.降低服务器的并发压力
6.提速提速！！！
最后，如何实现，demo在哪里？？看官网吧，我还没尝试。。。