Describe the bug When trying to render a <code class="notranslate

leptos_router parent Route attr view is not generating view for dynamic routes about leptos HOT 4 CLOSED

vitordhers commented on June 14, 2024

leptos_router parent Route attr view is not generating view for dynamic routes

from leptos.

Comments (4)

gbj commented on June 14, 2024 2

The fundamental issue here is that children doesn't flatten the children you pass it. Route expects to get n children, each of which is a Route. In your enumerated view, you pass it 2 children, each of which is a Route. In your collected and fragment views, you pass it 1 child, which is a Vec or Fragment. These are not flattened.

This just has to do with the way the view macro constructs children. Here's a working version of the collected approach that I created by expanding the macro for the working enumerated version:

#[component(transparent)]
fn CollectedNestedRoutes() -> impl IntoView {
    let nested = Route(
        RouteProps::builder()
            .path("/")
            .view(SimpleNavComponent)
            // this is very similar to the way the view macro constructs children, 
            // but allows you to construct the vec however you'd like rather than just adding each child
            .children(ToChildren::to_children(|| {
                Fragment::lazy(|| {
                    vec![1, 2]
                        .into_iter()
                        .map(|n: i8| view! { <DeepNestedRouteSelector url=n /> })
                        .collect()
                })
            }))
            .build(),
    );
    view! {
        <Route path="/" view=|| view! {<Html lang="en-US" /><Outlet />}>
            {nested}
            <Route path="/comp3" view=SimpleComponent3 />
            <Route path="/comp4" view=SimpleComponent4 />
        </Route>
    }
}

In case it's helpful in reducing boilerplate, by the way, any component with no props is just a function with no arguments -- so you can replace every instance of something like view=|| view! { <SimpleNavComponent/> } with just view=SimpleNavComponent.

from leptos.

gbj commented on June 14, 2024

I'm not entirely sure what your example is supposed to show or how it relates to the problem in the application.

In particular, it seems like your discussion of .render_to_string() is an XY problem; .render_to_string() shouldn't be displaying anything in the case of these transparent Route components, which are intended just to build a RouteDefinition. It seems like maybe you're trying to use render_to_string() for debugging purposes here (right?) and it's not working as expected, but that that's not the actual issue.

With very complex or dynamic routing setups like the one you're trying to create, I would suggest ditching the <Route/> component etc. and just building a nested RouteDefinition struct manually. This is what <Route/> returns in any case, and the reason things are marked #[component(transparent)] is to allow them just to return that RouteDefinition.

Alternately, if you provide a minimal reproduction (not your entire application) that illustrates the issue and try to explain more of the expected vs actual behavior I can try to help figure it out.

from leptos.

vitordhers commented on June 14, 2024

Yes, as you correctly noticed, I was using render_to_string() in order to debug the components inside routes.
But apparently, my issue appears when trying to consolidate components into views and nesting them.

Differently from what I thought, the problem doesn't come from having components between nested Routes (once they are marked as #component(transparent)), but from both trying to collect_into_view them, and from converting them into a Fragment (and then proceeding to map it to view).

Since both approaches mentioned above yield the infamous component with id #-#-#-# not found, ignoring it for hydration error, and as mentioned at Hydration Errors chapter from Leptos book, I felt free to inquire further on this matter.

Please feel free take a look on this minimal reproduction repository, as I believe it illustrates the issue better. So, as you can infer, the expected behavior is to have all 4 components routes listed and accessible in the application when iterating (or casting into Fragment) the DeepNestedRouteSelector component.

I've seen your suggestion of implementing the RouteDefinition manually, but for me, it didn't look so simple to do, specially when it comes on having a concise id for ensuring correct hydration. I've also noticed that you're considering changing visibility on new_route_id function (which could help in my case, I assume), so I'd like to request, if possible -- could you please provide me with an example of implementing RouteDefinition manually?

Finally, thanks for your effort on developing Leptos, it's a great framework, indeed.

from leptos.

vitordhers commented on June 14, 2024

Greg, it really did the trick, thanks a lot.

from leptos.

leptos_router parent Route attr view is not generating view for dynamic routes about leptos HOT 4 CLOSED

Comments (4)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent