DioxusLabs / DioxusLabs/dioxus
Accept `impl Trait` in #[component] props via manual desugaring
- Dominant language
- Rust
- Stars
- 39.1k
- Forks
- 1.9k
- Avg merge
- 4d 10h
- Merged PRs (30d)
- 4
Description
Given the following examples:
```rust
#[inline_props]
fn MyComponent(cx: Scope, title: String, url: String) -> Element {
// Easy on the eyes, even though it might require memory allocations
// if you had a string reference available.
}
```
```rust
#[inline_props]
fn MyComponent(cx: Scope, title: T, url: U) -> Element
where
T: AsRef,
U: AsRef,
{
// More performant if you had a string reference available, but more
// complex to write and read.
}
```
```rust
#[inline_props]
fn MyComponent >(cx: Scope, title: T) -> Element {
// More readable (although debatable) for a small number of arguments,
// but currently not supported by the `inline_props` attribute.
}
```
```rust
#[inline_props]
fn MyComponent(cx: Scope, title: impl AsRef, url: impl AsRef) -> Element {
// Best of both worlds, but is currently not supported by the
// `inline_props` attribute.
}
```
Additionally, I noticed that with the proc macro, Rust Analyzer can start reporting errors of the macro itself trying to parse the token tree, and not succeeding due to a potential syntax error in the function implementation. This causes duplicate error reports, the entire function being marked as "invalid" in some cases, and other weird situations.
It made me realize (again) why I mostly prefer libraries that don't rely too heavily on macro use (which Dioxus happily doesn't, another wonderful library with great DX that doesn't rely on macros is the Bevy game engine). So I've since switched back to native prop types, but I wanted to report this issue, nonetheless, for others who do prefer the macro.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.