[RFC]: Unified syntax for providers, without code-generation
With the death of macros, I've been thinking a lot on the future of Riverpod. There are two common complaints with Riverpod: - Too many options - or it requires codegen Those are two sides of the same coin. Many users aren't satisfied with the API. The API issue impacts other areas too. For example, documentations are in a bad state in large part because there are too many things to cover. With that in mind, I've been experimenting on how to solve this issue over the years. And I think I'm ready to share a possible new syntax for Riverpod. ## The problems Before showing the new syntax, I'd like to list a few problems that we're trying to solve here. If you think one of them is missing, make sure to leave a comment! 1) There are too many types of providers. No need to explain anything. We all know what this is about. 2) `family`'s syntax without code-generation is bad. We are currently limited with a single required positional parameter. No optional ones. No default values. No named parameters. No generics. Codegen fixes this. But codegen is slow. 3) Updating a provider is needlessly complex. We currently have to write `ref.read(provider.notifier).method()`. We can probably do simpler. 4) We need a way to define "mutations" without codegen https://github.com/rrousselGit/riverpod/issues/1660 was implemented some time, but it requires code-generation. It was a good decision at the time. But that assumed we'd be getting macros. We should be able to use
Posted by rrousselGit on Mar 15, 2025, 1:02 AM
Tags
Related issues
- [Meta] Feedback on granular control over Copilot changes
- unexpected status 401 Unauthorized issue
- [MODEL] Measurable quality regression in Claude generation 5 (Fable 5 / Opus 5 / Sonnet 5): worse nonsense detection, ~2x verbosity, under-disclosed model fallb
- [CRITICAL] Subagent spawning and subagent pattern bugs trigger infinite recursion, infinite token usage, grossly inefficient token usage, and lost accumulated s
- Video stops playing after some minutes
- [MODEL] Claude verbose code comments by default — ignores instructions to stop.
Raise real-world problems, find people facing the same issue, and discuss solutions.2,000 issues0 comments
github (Software)
[Meta] Feedback on granular control over Copilot changes
unexpected status 401 Unauthorized issue
[MODEL] Measurable quality regression in Claude generation 5 (Fable 5 / Opus 5 / Sonnet 5): worse nonsense detection, ~2x verbosity, under-disclosed model fallb
[CRITICAL] Subagent spawning and subagent pattern bugs trigger infinite recursion, infinite token usage, grossly inefficient token usage, and lost accumulated s
Video stops playing after some minutes
[MODEL] Claude verbose code comments by default — ignores instructions to stop.
Scope Codex VS Code chats to the current workspace/project
Update on "Co-authored-by: Copilot" in commit messages
[RFC]: Unified syntax for providers, without code-generation
With the death of macros, I've been thinking a lot on the future of Riverpod. There are two common complaints with Riverpod: - Too many options - or it requires codegen Those are two sides of the same coin. Many users aren't satisfied with the API. The API issue impacts other areas too. For example, documentations are in a bad state in large part because there are too many things to cover. With that in mind, I've been experimenting on how to solve this issue over the years. And I think I'm ready to share a possible new syntax for Riverpod. ## The problems Before showing the new syntax, I'd like to list a few problems that we're trying to solve here. If you think one of them is missing, make sure to leave a comment! 1) There are too many types of providers. No need to explain anything. We all know what this is about. 2) `family`'s syntax without code-generation is bad. We are currently limited with a single required positional parameter. No optional ones. No default values. No named parameters. No generics. Codegen fixes this. But codegen is slow. 3) Updating a provider is needlessly complex. We currently have to write `ref.read(provider.notifier).method()`. We can probably do simpler. 4) We need a way to define "mutations" without codegen https://github.com/rrousselGit/riverpod/issues/1660 was implemented some time, but it requires code-generation. It was a good decision at the time. But that assumed we'd be getting macros. We should be able to use
Comments (0)
No comments yet. Start the discussion.