Reusing screens

[Lootwig]

Is there a more elegant way to have the same screen reachable from different locations than defining the same GoRoute & builder multiple times with different paths?

[Hesamedin]

I didn't get what do you mean @Lootwig. Please give an example.
I reach the same screen from different locations using: context.pushNamed('screen_a') or context.pushNamed('screen_b', params: {'id': 'product_id'})

[Lootwig]

Is the location parameter of the GoRoute ignored in that case? If so, why is it a mandatory parameter in the first place?

[leoshusar]

Did you mean path parameter? It's is still used under the hood (and in the browser bar). Named location just searches for it.
When you are on /home/page, you can do context.push('/my/totally/random/location') (or pushNamed('somewhere')) and it will work just fine.

[Lootwig]

I know I could simply try this out, but it may be useful to have a place online where this is documented: what is the resulting path, then? Are the two concatenated, just the location appended, the pushed one replaces the underlying one...?

[MrLightful]

@Lootwig as far as I understand, yes, you need to include GoRoute inside all individual routes of higher level.

But I also have a question about this topic, would appreciate it if @Hesamedin or @leoshusar can give some advice. So far it looks a bit cumbersome working with the named routes with push. For example, I have 3 screens and a notifications feed screen. From each of the 3 pages, you can push to the notifications screen.

Okay, I define notification's GoRoute inside of GoRoute of these screens. It's fine. But I want to generalize the routing and reuse the routing name. And be able to pushNamed('notifications') from the current location. But the package doesn't allow to reuse names. This makes sense when we are talking about absolute paths of goNamed, but doesn't make much sense when we are talking about pushNamed.

The problem is that although I am okay with defining GoRoute in multiple places where it is needed, it is much more messy to come up with unique names for each of them (and I do want to use pushNamed and not push).

Am I missing something? Is there a way to do what I want?

[MrLightful]

I see that it can cause lots of problems if we allow reusing names, but maybe we could have something like tag or localName that can be reused and would be used by relative pushing by name, regardless of the current location/GoRoute block?

[MrLightful]

An alternative could be that we have this reusable GoRoute at the root level of the routes list of GoRouter. And when we push it, it pushes to/appends the current's location path. But I guess this pretty much completely redefines the way push works.

[leoshusar]

If I understand it correctly, you have 3 screens and one notification screen independent on those 3 screens? Or do you want to push from e.g. screen 2 to notifications and show notifications related to screen 2?

If it's the latter one, I see two solutions here.

First: define one route for notifications, not nested in those 3 screen routes, and pass what notifications do you want to see in query parameter or route param.
So those notification routes can look like /notifications/my-screen-2.

Second: have those notifications nested in all screens. Since I'm not a fan using magic strings throughout my code, I have constants for all my named routes.
So I can do context.pushNamed(AppRoutes.userNotifications). Then in that constant I can have whatever string doesn't collide with other names.
Or if I have many complex routes, I sometimes also split it to multiple routes classes, so I have AppRoutes and e.g. UserRoutes. In this case I can have UserRoutes.notifications.

Is this what you were asking for?