akiomik / akiomik/nosvelte

ReqResult's data and error are typed as always present but are undefined in practice

未关闭
#69 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看
bug
主要语言
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

`data: Readable` and `error: Readable` are the
honest types, but they break every TypeScript consumer that currently writes
`$data.event` or `$error.message` — the compiler starts rejecting code that
works today. That makes it a minor release, and worth deciding alongside
whether the list and single-event hooks should keep sharing one result type at
all.

贡献指南

这个仓库没有索引到贡献指南

调研方向

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

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。