fix: improved rust-analyzer support in #[component] macro?

[gbj]

This restructures the component macro so that it always emits a function with the identical name into a #[doc(hidden)] module named like component_module_my_component, whether the rest of the #[component] expands successfully or not.

The goal here is to provide a better rust-analyzer experience when there are syntax errors, when you are typing, etc (see #1781 and #1782, which doesn't really fix it)

If some others could let me know if this actually helps, I'd appreciate it and will fix any CI errors that arise.

[reedwoodruff]

This didn't fix the case listed in #1781 for me, but I don't want to give a false negative, so I'll detail the steps I took:

1. Clone Leptos locally
2. Checkout this branch
3. Make a test project which has leptos as local dependencies

[dependencies]
leptos = { path = "../leptos/leptos", features = ["nightly", "csr"] }
leptos_dom = { path = "../leptos/leptos_dom", features = ["nightly", "csr"] }
leptos_reactive = { path = "../leptos/leptos_reactive", features = [
    "nightly",
    "csr",
] }

4. Attempt to autocomplete with a syntax error above:

use leptos::*;
use leptos_dom::*;

fn main() {
    mount_to_body(|| view! {<App />});
}

#[component]
fn App() -> impl IntoView {
    let (show, set_show) = create_signal(true);
    let  // Syntax error here
    let array = vec![1, 2, 3, 4];
    show. // Cursor here, no autocomplete when #[component] is present on the function
    view! {
        <button on:click=move |_| set_show.update(|prev| *prev = !*prev)>show/hide</button>
        <Show when=move || show.get()><div>Here is</div></Show>
        <div>Just some div</div>
    }
}

I made sure to restart the rust-analyzer server.
I could easily have missed something, though.

[gbj]

I agree, it actually doesn't fix the particular case in #1781 for me either, I think because that case includes a syntax error that prevents it from parsing the whole function. It's a bit difficult because we do need to parse the function signature in order to remove the #[prop] attributes and doc comments from function params before we can emit the code. But might be able to make it finer-grained so that it only tries to parse the signature, and modify that, and then emit the rest of the token stream unmodified.

[gbj]

@reedwoodruff Thanks a lot. I actually just went back to try to address the issue (namely, that if there's a syntax error in the body it won't successfully parse the dummy ItemFn) and realized I'd reimplemented the Dummy approach that @pikaju made in #1782. The dummy was exactly the right idea, and I think combining it with relocating the output of the macro into its own mod may actually solve the issue.

At least, I'm now able to defeat #1781 on my machine! Invalid syntax in the #[component] fn body with rust-analyzer still running.

If someone could test out the latest commit on this branch it would be much appreciated. Then I can try to figure out these CI issues.

[reedwoodruff]

Awesome, it's working for me with the latest commit! 👍

[diversable]

R-a is working for CSR & SSR examples for me as well (SSR doesn't compile due to some renamed items, but rust-analyzer works great!)

Let me know when this lands and I'll update the "DX" section of the Leptos Book accordingly (I'll keep an eye out, too).

Great work!

[gbj]

Ok, the issue with the tests here is that this mod solution runs afoul of this https://stackoverflow.com/questions/66752423/can-i-import-super-from-a-mod-thats-inside-a-fn