如果你查看 Antd 和 Element Plus，会发现一件事情，Antd 的表格包含了 Pagination，而 Element Plus 的表格和分页是完全分离的。

看上去这是一样的，实际上，不同的设计哲学会造成不同的结果。对于 Antd，由于自身集成了分页，所以它可以明确知道，当前是否进行了分页操作；对于 Element Plus，这是做不到的。

那又怎么样呢？开发的经验告诉我们，一开始我们觉得没有影响的设计区别，最后总会导致一些问题，而我们几乎总能找到办法绕过。

设想一个问题：当table的数据变化的时候，我们是否应该将滚动条设置到最顶端？

对于 Antd，由于它可以知道什么时候是分页操作，什么时候不是分页。所以，它可以在分页的时候，使得滚动条重置到顶端；但是，对于 Element Plus，由于不知道场景，是不能这样做的。最简单的场景，对于下拉加载，这样做是明显的bug；

Element Plus 的解法是：提供了 setScrollTop 方法，用户在翻页的时候手动调用。换句话说，这部分逻辑被交给了业务方处理。

但是，这页导致业务方必然需要感知组件细节。它需要一个 ref，并调用它的方法。通常我们认为应该尽量避免这种写法，因为它导致耦合。

老实说，Element 的设计哲学更符合我的偏好。这两个组件相互分离，业务方自由组合，这更符合开发的思想。但是，这种做法却导致了业务方常常需要自己将这两个组件和父组件耦合（虽然我们可以通过 composition api 解耦）；归根结底，我们不得不承认，表格和分页，确实是一对苦命的鸳鸯。

现在，我们假设有这样的一个组件库。它为了自己的纯净，将大量逻辑交给外部处理，对所有的事情都提供 workaround，最终导致自己变成了纯粹的视图组件库。这样的组件库从代码上应该是纯净的、美丽的，但是这种纯净是因为它把难题都丢给了外部。我觉得，虽然它在代码上是漂亮的，但是作为组件库，却只是一个精致的花瓶。

因此，我认为开发需要容忍一些不符合一般哲学的设计。实际上，可以优雅地处理这些问题，才是功力的体现。

如果一个业务确实是相关的，那么它们的组合是可以接受的。换一句话说，在这个问题上，尽管在哲学上我更喜欢 Element 的方案，但是我更喜欢 Antd 的实现：在绝大多数情况，可以使用表格自带的分页；如果有特殊场景，那么可以自己组合。

开发的美学追求，和实际业务之间的妥协，是程序员永远要面对的问题。我们需要在这种限制之中寻找最优解。

注：本文只针对表格和分页这一个问题，且观点基于个人喜好。这两个组件库都是优秀的组件库，个人也对两个对社区的贡献深表敬意。