Concern about RxSwift dependency and feasibility of migrating to Combine (or other reactive frameworks)
还没有人认领这个 Issue。
评估
调研方向
该 issue 没有列出任何文件或测试。先检查 repository 的 RxSwift 依赖、公共 API、scheduler 的使用方式和 disposal 模式；将这些约束与提议的基于 Combine 或 provider 的设计进行比较。要算完成，需要维护者就迁移方向或 prototype 范围达成一致。
由索引模型根据 Issue 内容生成。
描述
Hi maintainers,
First of all, thank you for the great work on ribs-ios—it's been a solid foundation for many of us.
Recently our team has started to evaluate the long-term cost of keeping RxSwift as the only built-in reactive dependency. RxSwift is a fantastic library, but it adds ~2 MB to the binary, drags in a third-party scheduler model, and—most importantly—requires engineers to master an additional DSL that no longer ships with the OS. With Apple investing heavily in Combine and async/await, we worry that:
- On-going binary-size / security-surface overhead (RxSwift is not distributed with the OS).
- Harder hiring / onboarding (new iOS engineers already know Combine, but rarely RxSwift).
- Potential mismatch with Apple's future APIs (e.g. async sequences, Swift Concurrency back-pressure).
- One more layer to maintain when RxSwift eventually winds down.
Therefore we'd like to understand:
A. How tightly is ribs-ios coupled to RxSwift today?
- Are we using any Rx-specific scheduler contracts that have no Combine equivalent?
- Is there any public API surface that exposes Rx types (Observable, Single, Completable, etc.)?
B. Has there been any prior discussion / spike about providing a "reactive-provider" protocol so that consumers could plug in Combine, ReactiveSwift, or even their own lightweight wrapper?
C. If such a layer does not exist, would the maintainers be open to a PR that introduces one?
- We imagine a tiny ReactiveProvider protocol (with operators like map/flatMap/zip/just/fail) plus two concrete modules: RIBsRxSwift and RIBsCombine.
- By default the repo could still ship RIBsRxSwift so the change is 100 % source-compatible for current users.
- Consumers who want Combine would depend on RIBsCombine instead and get zero RxSwift binary cost.
D. Are there any architectural blockers we should be aware of (e.g. intricate uses of RxSwift's recursive scheduler or custom disposables that Combine cannot replicate)?
We are happy to invest engineering time to prototype the approach, but we wanted to check direction with you first to avoid duplicate effort or design conflicts.
Looking forward to your thoughts!
- 主要语言
- Swift
- 星标
- 193
- 派生
- 25
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
uber/RIBs-iOS 的其他 Issue
-
难度 3/5 1-2 天 新手友好度 38/100
-
难度 2/5 1-3 小时 新手友好度 45/100
-
难度 2/5 1-3 小时 新手友好度 45/100
-
难度 4/5 3-5 天 新手友好度 42/100
-
难度 5/5 一周以上 新手友好度 20/100
相似的 Issue
-
swift.md: `Date(myString, strategy: .iso8601)` example omits `try` — the initializer is throwing未关闭
难度 1/5 1 小时以内 新手友好度 88/100
-
bug core p3
难度 2/5 1-3 小时 新手友好度 70/100
RunanywhereAI/runanywhere-sdks#1083 ·
维护者通常 5 天内回复
-
难度 2/5 1-3 小时 新手友好度 66/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
nightscout/nightguard#368 ·
-
难度 2/5 1-3 小时 新手友好度 62/100
johnno1962/InjectionNext#175 · 2 条评论 ·