DioxusLabs / DioxusLabs/dioxus
Make Resource Ready/Pending State Explicit
- Dominant language
- Rust
- Stars
- 39.1k
- Forks
- 1.9k
- Avg merge
- 4d 10h
- Merged PRs (30d)
- 4
Description
## Feature Request
### Background
It would be great if the explicitness of `Resource` ready/pending was built in to the type.
Locally I use `Pending` as a type alias for `Option` when the resource has not finished yet
```rust
/// A type alias for the state of a resource
pub type Pending = Option;
```
I think it makes things more clear. Since
```rust
let resource: Resource> = use_resource(move |_| async move {
todo!()
});
// rather than
let read: GenerationalRef>>> = resource.read();
// It becomes
let read: GenerationalRef>>> = resource.read();
match &*read {
Pending::Some(_) => todo!(),
Pending::None => todo!(),
}
```
But from an IDE perspective, this currently does not make code actions more clear, since the rust-analyzer looks through type aliases, which is a known issue - https://github.com/rust-lang/rust-analyzer/issues/1666
### Solution
Instead of using `Option` or a type alias here, we could do better with something like [Poll](https://doc.rust-lang.org/std/task/enum.Poll.html). That would it would look like
```rust
let read: GenerationalRef>>> = resource.read();
match &*read {
Poll::Ready(_) => todo!(),
Poll::Pending => todo!(),
}
```
We would probably want to use our own type rather than the std libs `Poll` though. As our own type would be more flexible. `Poll` is a good name, but it would likely cause confusion with how `Poll` is used with `Future`s, which is not what is happening behind the scenes here. If we choose a different name, we should avoid a name like `ResourceValue` or `ResourceState`, so we can use it more generally. Something like `AsyncValue` may be more appropriate. But whatever the name is, the variants `Ready`/`Pending` are probably correct choice.
### Related
Likely related to https://github.com/DioxusLabs/dioxus/pull/4846
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.