@mikulch
已经回复过你好几次了。
主要是原来的设计稿里面没有分页这个概念，所以实现上不能单独做一个。你可以选择：
1. 用我们提供的 `useTheme` 功能自己实现一个
2. 和其他包含分页的组件库组合使用
3. 在 zeit 的 spectrum 上询问这些设计元素有没有 roadmap

没法编辑... 真的难受

1. [r2]( https://github.com/mikeal/r2) 是比较早期的替代品，算是 request next 早期比较通用的产品，core 大约 [3.17kb]( https://cdn.unix.bio/?q=r2&npm=1)

2. [node-fetch]( https://github.com/node-fetch/node-fetch) 是仿造 fetch API 写的 NodeJS HTTP 客户端，如果你对 fetch 比较熟悉考虑这个，有点是一直在更新，启动堆栈差不多 20k 。大家比较熟就不多说了。

3. [axios]( https://github.com/axios/axios) 是浏览器与 NodeJS 兼容的，比较重，因为兼容了浏览器的代码。这部分代码在运行时也会进入堆栈，尽管不会执行，因为不管什么 module 都不能 tree shaking 编程式的分发的代码块。API 有些土里土气，属于简单易懂的状态型编程风格。

4. [bent]( https://github.com/mikeal/bent) 也是浏览器与 NodeJS 兼容的，但比较小巧 (意味着功能没有那么多)。API 只有一个函数，但是目前没有基线测试不知道性能如何。

5. [got]( https://github.com/sindresorhus/got) 专业的 NodeJS HTTP 客户端。非常非常非常大。亮点之一就是支持 `pagination` 与一些编程式的 hook，社区中有非常非常非常多的示例教你如何使用它，毕竟用的人多。开发者也是知名的开源狂魔 `sindresorhus` (他维护了 1000+ 的开源仓库)，算是比较值得信赖吧。

6. [superagent]( https://github.com/visionmedia/superagent) ，一个有意思的 HTTP 客户端库吧，用的链式 API 。也是兼容浏览器和 NodeJS 。优势是支持 HTTP2，具体可以看这个 [PR]( https://github.com/visionmedia/superagent/pull/1399)。早期是你们熟知的 TJ 一个人在写，现在已经是组织在维护。(体积也很大)


总结一下，如果你喜欢小巧一些可以考虑 `node-fetch` 和 `bent`，需要功能比较强大就是 `got` 和 `superagent`。
另外给你们强烈推荐一个适用于微服务的 http-client: [zeit-fetch]( https://github.com/zeit/fetch)，支持 DNS 缓存、重试和 `keep-http-agent`，如果你正在写微服务，可以试一试。

最后说一句题外话，现在 NodeJS 的 API 非常的友好，如果你只是一个简单的 request(特别是 `get` ) 不用库也就几行而已。

@mikulch 主要是原来的设计稿里面没有分页这个概念，所以实现上不能单独做一个。
你可以考虑和其他分页组件组合使用。也可以在 zeit 的 spectrum 上询问这些设计元素。

@baiduyixia 大兄弟，你也太狠了....

@GDC
@kasper4649

一个好消息，React 版本现在已经发布 alpha 了： https://github.com/zeit-ui/react

我觉得有两个很重要的原因，一个是国内愿意参与贡献的人少，大部分都是只去拿来用，没有社区这个说法只有核心贡献者天天添砖加瓦；第二是没有捐赠的习惯，不管这个项目对你有多少帮助，谈到钱不管多少是不可能的，没让你给加功能没喷你这个那个缺点已经是不错了，捐赠怕不是在做梦呢。缺少良性反馈这个从常见的 sponsor 网站就能看得出来。

如果能力不够参与不了贡献，合适的打赏捐赠对于开源项目来说也是保障生命力非常重要的方式。

@melonzzz 现在这个也没什么门槛了，就装个 Node 运行俩命令就完啦

@frostcake 当然可以，这个就是开源给别人用的。

@missdeer 是 ui 组件的功能，参见这里 https://react.zeit-ui.co

@mikulch 暂时没有，让我想想办法…

@dtsdao 是手写的呀，我先写了一个 react ui 框架，然后用这个结合 next.js 写的，还是挺不错的。

@Baboonowen 🤣🤣

@hoythan 主要是用在 markdown 和第三方的文档里面，这里面禁止写 js

@wolfan

> 早年间的统计好像比这个强。

好吧。不过从功能评判价值不太科学，如果是一个静态博客或者自己写文档，加入一个图片作为阅读数来说是非常简单且有较高的开发体验，可以不用烦心各种问题，但如果和专业的统计服务比功能和稳定性自然是不能相比的，几乎所有服务都是在特定的场景下才有自己的核心价值。

如果你未来正在写一个文档，可能只想要在短短几分钟内生成一些页面，这可能是非常合适而且舒适的解决方案，有机会你也可以尝试一下。

@BFDZ

> 还以为真是无服务器，话说现在卜蒜子统计非常慢，可能你这个用的人多了也慢，想找个真正的无服务统计

这个服务实现上是在 Serverless 上实现的, 没有快和慢的说法，用多少，容器就唤醒多少，用多久就唤醒多久，容器本身是无状态的。

@mayx 看文档，加上 `unique=1` 会按用户 cookie 统计。

@xiri 当然。这也没有什么不妥的。jsorg 和 jsdelivr 不都是由发起者提供服务吗？