前端后端的各位，接口请求数据的时候，你们更喜欢哪种方式

[szyp]

如图所示，如果上面三个 Tab 栏中的数据都不相关

你是选择：
1. 一次性加载所有数据，前端点击直接切换
2. 点击 Tab 栏切换请求对应的数据

本人是后端，我更期望前端使用第二种方式去请求，这样开发的时候，调试工具更能直观的看到哪个接口出了问题，影响到什么了

[zhengfan2016]

那肯定是点哪个请求哪个呀，我理解 op 为什么想要第二种，减少并发是吧哈哈哈。

你要是想让前端按第二种改，可以使劲抓它小辫子，比如你当前在 tab1 ，但是 tab2 页后端更新数据了，切换 tab2 数据没有及时刷新，你就怼前端 tmd 怎么写出 bug 了。前端如果把切换 tab 就请求对应接口写上了，你就怼前端初始进入页面的时候请求三个接口，切换 tab 又请求接口，重复请求，又有 bug ，你们前端 xxxxx 吃的 hhh

[chihiro2014]

一般不是看生命周期么，tab 加载和切换的时候才会取数据。一次性取三个，除非是静态数据

[blackmatch]

这不仅仅前后端协作的问题，还会涉及到用户体验的问题，如果一下子请求 3 个 tab 的数据，从技术人的角度可能会觉得对用户是友好的，提前准备好数据，能够无缝切换 tab ，但是体验上却未必：
1. 一次请求多个 tab 页的数据会增加服务压力，可能会影响接口性能，降低整体的用户体验
2. 提前加载数据，用户切换 tab 的时候不能及时展示最新的数据
3.没有过度动画会给人一种“假数据/写死的数据”的错觉

综上，个人更倾向于切换 tab 时实时请求当前页的数据。

[jamesjammy061]

graphql 按需取可以么，但是需要不被后端挨骂🤣，还需要老板支持

[SanjinGG]

肯定是第二种啊，三个接口，这样数据量也小请求快，如果用户不点 bc ，也不会请求浪费资源

[RightHand]

@xuld 中台：这个需求等排期

[kinghly]

还有另外一种，初始化只请求第一个，闲时获取其他数据。点击切换时如果该数据未获取，则插队获取对应数据。

[egan0606]

想什么呢，必须 3 个接口呀， 职责单一； 前后端分离，3 个接口， 前端按要求自行控制加载逻辑；

[buffzty]

我会根据情况写 1-2 个接口,但是一次性加载 3 个 tab 的接口是必须要做的,这样用户体验较好,没有卡顿不需要等待

首先看这个 tab 是否永远都是这 3 个会不会变成 456 个.
第二看这些 tab 是否会分页.

如果不分页的话直接一个接口完事,有分页就写两个接口. 1. 获取首页 tab 预览信息(即所有 tab 的前 10-20 个记录)
2. 获取某个分类 tab 的分页数据

[zangbianxuegu]

主要是考虑用户体验，并不太会影响调试。既然考虑 1 ，大概率数据不需要及时更新。在这个前提下 1 的体验好一点，请求 1 次； 2 查看了 3 个 Tab 的时候请求了 3 次。
还要考虑场景，切换 Tab 的概率大不大。
综合我建议 2 ，接口更清晰，能避免第一次加载过多数据，Tab loading 问题不大。2 对前端要求更高一点。
而且如果做数据缓存，只有第一次请求的差别。

[Lemon2ee]

接口都写，然后根据用户习惯在前端进行预加载，能保证请求干净，并且前端体验不会很糟糕。

[niubiman]

@xuld 中台这个鬼东西真的是比微服务还玄学

[wanggaoqi]

@blackmatch 肯定要点击后刷新，但是你没说到重点，因为你在上滑肯定有加载分页的，就这一条，就得让他实时刷新

[wangtian2020]

肯定是 2 ，这是最基础的设计原则。每个接口要做专一的事，除非页面出现频繁调用接口。
举个例子，那么以后出现一个其他的单独的页面只要 A 页的数据，那怎么办，第一种方法的话会有大量的性能损失，更何况是无关的数据

[zhmouV2]

菜逼前端 我开始是 2 测试切 tab 感觉体验不好 叫我改成 1 了（一次性请求多个 tab 的接口 虽然不是一个接口）
数据实时性在我这个 case 不是问题，因为都是用户导入的数据，而且用户登录只能单点登录，导入之后刷新对应 tab 就行

[seeu2ex]

@Rennen 为什么写 3 个，一个传不同的 tabId 不行吗

[Zzzz77]

后端提供：
GET api.com/list?id=xxx ，不传 ID 加载全部

前端看具体需求和业务情况选择怎么用