New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make it possible to specify depth on RouterView component #2511

Closed
dmmikkel opened this Issue Nov 30, 2018 · 1 comment

Comments

Projects
None yet
2 participants
@dmmikkel

dmmikkel commented Nov 30, 2018

What problem does this feature solve?

In order to render children of a route you must nest RouterView components inside each other. In certain projects with advanced layouts this forces the wrong components to be responsible for the layout.

I propose that RouterView accepts an optional property that overrides the depth. I have already implemented and tested this feature in our project.

The benefits of this is

  • Removes the need for nesting RouterViews
  • Makes it possible for a single component to be responsible for layout when using child views
  • In devtools it is easier to find the router views as they are siblings
  • Is 100% optional and does not break any existing code

What does the proposed API look like?

routes: [
  { path: '/', component: Foo,
    children: [
      { path: 'child', component: Bar,
        children: [
          { path: 'another-child', component: Baz }
        ]
      }
    ]
  }
]

<RouterView :depth="0"/>
<RouterView name="some-name" :depth="0"/>
<RouterView :depth="1"/>
<RouterView :depth="2"/>
@posva

This comment has been minimized.

Member

posva commented Nov 30, 2018

If you need router-views at the same level, they are pretty much named views, which you can combine with nesting to have common prefixes.

I'm really against complexifying the named + nested views as people struggle a lot with it and most use case I see are just for path reuse (refactoring). Also, putting depth with a number isn't explicit enough to create a relationship between the route and the view. It looks more like a generated value.

If someone wants to use nested route paths (a/b, a/c), it (most of time) makes sense to nest views because the user expects to only portions of the view to change

Right now, what can be done is this:

{
  path: '/a/nested',
  components: {
    default: Foo,
    a: Bar,
    b: Baz
  }
},
{
  path: '/b/nested2',
  components: {
    default: Bar,
    // no a
    b: Baz
  }
}

Sometimes a param can also make things much easier

The problem is that we repeat parts of the url, and this problem repeats in other cases, some use children to overcome this, but it's not the way it was meant to be used. What I would like to cover is that, not having to repeat path sections, by using helpers or by designing a different API for that

I don't want people to think this api will be implemented this way or even worse, let them work on it and create a PR that I will have to reject. If we create something like adjacent views that map to different part of a URL, the API shouldn't use children

@posva posva closed this Nov 30, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment