ReqResult's data and error are typed as always present but are undefined in practice
- 主要语言
- TypeScript
- 星标
- 29
- 派生
- 3
- 平均合并
- 3 小时 5 分钟
- 30 天内合并 PR
- 11
描述
```ts
export interface ReqResult {
data: Readable;
status: Readable;
error: Readable;
}
```
Neither `data` nor `error` is actually always present:
- `error` is `undefined` until something fails, which is the normal case for a
whole request. `useReq.test.ts` asserts exactly that ("emits undefined as
.error"), and `useReq()` builds it from `writable()` with a
cast at the boundary.
- `data` is `undefined` for every single-event hook — `useEvent`, `useMetadata`,
`useArticle`, `useLatestEvent`, `useReplaceableEvent` and the wrappers around
them — while the request is in flight, and permanently when the event does not
exist. Those hooks pass no `initData`, and there is no sensible `EventPacket`
to stand in for "not found".
The components already work around it: every one of them writes `$data?.…`
rather than `$data.…`. Consumers using the hooks directly get no such warning
from the compiler — the type says the value is there.
This is what #59 fixed one instance of, by giving `useUniqueEventList()` the
`initData: []` its siblings already had. That closed the gap for the list hooks,
whose `[]` is a real value. It cannot be closed the same way for the
single-event ones.
## Why it isn't just a one-line change
贡献指南
这个仓库没有索引到贡献指南
调研方向
Start with useReq.test.ts and the useReq() construction, then trace the single-event hooks named in the issue to compare their runtime undefined behavior with ReqResult’s types. The work is done when the public result types and affected consumers/tests consistently reflect the chosen handling of absent data and errors, with the compatibility decision settled.
由索引模型根据 Issue 内容生成。
评估
- 技术栈
- typescript
- 领域
- developer-experience, frontend
- Issue 类型
- 缺陷
- 难度
- 5/5
- 预计耗时
- 一周以上
- 活跃度
- 冷清
- 描述清晰度
- 基本清楚
- 新手友好度
- 35/100