FirebaseExtended / FirebaseExtended/reactfire
Disabling queries via ReactFireOptions
- 主要语言
- TypeScript
- 星标
- 3.6k
- 派生
- 403
- 平均合并
- 14 小时 53 分钟
- 30 天内合并 PR
- 5
描述
I've read the discussion in #178 and am yet another person that has run into the wall of "can't use the hooks with a not-yet-defined id". I understand and agree with your desire to keep undefined/null ids as errors. But we still run into situations where the use of react-fire hooks constrains our design decisions and requires us to make several small components that issue the same query when one query would do and would allow us to present the UI in a single component as we wish.
I suggest adopting something similar to [how react-query handles this](https://react-query.tanstack.com/guides/disabling-queries). Passing in an `enabled` flag to the `ReactFireOptions` object which would prevent the query from executing if `enabled === false` (and instead returning `initialData`, if defined). This would allow the errors to persist when inadvertently passing in undefined/null, but also allow consumers to make their own design decisions when constructing dependent queries.
Alternatively, add an `exists` property to the `ObservableStatus` so that we can determine, without an additional query, whether the ref already exists. Currently when I have a dependent query I pass in an ID that I know not to exist, e.g. "-1", but I get back a document that has a firestore-generated ID and nothing else. Without the ability to disable the query or determine if the ref exists I rely on the object being otherwise empty to determine if I should return an `undefined` or not.
贡献指南
调研方向
该 issue 将 ReactFireOptions 和 ObservableStatus 列为相关入口;首先跟踪 ReactFire hooks 如何执行查询并暴露 status。将提议的 enabled 行为与替代的 exists status 进行比较,包括 initialData 的处理。完成的标准是:依赖查询可以避免意外执行,或能够可靠地确定引用是否存在,而不会将占位数据当作结果。
由索引模型根据 Issue 内容生成。
评估
- 技术栈
- firebase, react, typescript
- 领域
- frontend
- Issue 类型
- 功能
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 活跃度
- 停滞
- 描述清晰度
- 基本清楚
- 新手友好度
- 35/100