dioxus icon indicating copy to clipboard operation
dioxus copied to clipboard

Simplify and fix some issues with `#[component]` macro

Open tigerros opened this issue 1 year ago • 3 comments

  • Gets rid of a ton of code (almost half of the component.rs file + the 130 line long creatively named utils.rs file), which wasn't even being used!! This is the doc building that I introduced in 1563, and I'm sorry for introducing it. It's completely unnecessary because people can simply view the props struct through the props argument, and I don't know how it even got merged. Anyway, since then there have been some changes, and the original features made in 1563 just didn't work. I tested it out and the macro simply would not build any docs. So there was a bunch of useless code, technically being used at compilation, but not being used at runtime. Or maybe it was being used somehow, slowing down compilation but not producing any results.
  • Proper casing. I've included a little trick which will actually make the compiler prefer camel case names for the function identifiers. Previous implementations just applied #[allow(non_snake_case)] for the entire function, including the body, which would silence other stuff like variables (and also wouldn't make the compiler prefer camel case). This PR makes it so that the macro only changes case lints for the function identifier.
  • Allow struct pattern parameter parsing (e.g. fn Navbar(NavbarProps { title }: NavbarProps)). This was previously being parsed incorrectly and the macro just wouldn't compile. I noticed this was used a lot in Freya which is probably why Freya doesn't use the #[component] macro, instead opting for putting #[allow(non_snake_case)] everywhere (which, as mentioned, is incorrect because it silences warnings of other identifiers).
  • Update and generally improve the outdated docs.
  • When "inlining" props, changes the expansion to be a little cleaner. The change is very minor but it does make generated docs quite a bit cleaner (IMHO).
    #[component]
    fn Foo(bar: usize) ...
    
    // old expansion:
    fn Foo(mut __props: FooProps) ...
    // rustdoc:
    fn Foo(__props: FooProps) ...
    
    // new expansion:
    fn Foo(FooProps { bar }: FooProps) ...
    // rustdoc:
    fn Foo(_: FooProps) ...
    

tigerros avatar Apr 10 '24 15:04 tigerros

Expanding the component name to a struct will cause lints on any components that use the component_name syntax with an underscore instead of upper camel case

ealmloff avatar Apr 11 '24 18:04 ealmloff

Expanding the component name to a struct will cause lints on any components that use the component_name syntax with an underscore instead of upper camel case

That's the point, since the convention is upper camel case and not snake case.

tigerros avatar Apr 12 '24 07:04 tigerros

Can we keep support for lowercase components? They're basically our unofficial syntax for wrapped web components. IE you'd wrap a stringly typed kebab-case-element {} with a strongly_typed_element {}.

Done. I just want to point out that they're definitely "supported", they will just trigger a warning (which you can easily suppress with #[allow(non_camel_case_types)]), not an error. I thought it made sense because camel case is the convention, but I guess I didn't consider web components.

tigerros avatar Apr 26 '24 18:04 tigerros