feat: Added RouterComponent

[st-pasha]

Description

This PR adds the RouterComponent (see the docs for the description of its functionality).

Screen.Recording.2022-06-26.at.1.35.32.PM.mov

Checklist

• The title of my PR starts with a Conventional Commit prefix (fix:, feat:, docs: etc).
• I have read the Contributor Guide and followed the process outlined for submitting PRs.
• I have updated/added tests for ALL new/updated/fixed functionality.
• I have updated/added relevant documentation in docs and added dartdoc comments with ///.
• I have updated/added relevant examples in examples.

Breaking Change

• [-] Yes, this is a breaking change.
• No, this is not a breaking change.

Related Issues

Prerequisite: #1781
Closes #1375

[spydon]

Looks very good, looking forward to using it!
I think the example can be simplified quite a bit by using already existing Flame components though, to keep it more on point.

[spydon]

Maybe there is a better term than "Route", but I don't think it's the "Scene".

I think that Route is fine, and I think that we can probably introduce a scene concept later (which basically is just an empty component at the moment).

[alestiago]

I think this would benefit from #1799 . Where the Navigator would be an InheritedComponent. Similar to how Flutter deals with navigation.

[spydon]

I think that it looks good!
I'm thinking whether it is worth having generics on the NavigatorComponent so that it can be used in a more safe way than just plain strings. The cons that I see of that though is:

• It might be harder for the user to get into using it at first
• That generic would also spread to the Route.

[st-pasha]

I think this PR has no action items left, @spydon WDYT?

[spydon]

I think this PR has no action items left, @spydon WDYT?

If I remember correctly, there was a discussion about adding generics to the routes so that enums for example could be used, and then have a default implementation that just handled strings?

[st-pasha]

If I remember correctly, there was a discussion about adding generics to the routes so that enums for example could be used, and then have a default implementation that just handled strings?

My understanding was that because enums/strings have no common super-type, then using generics here would be counter-productive as it will lead for less type-safety (dynamic as the inferred type).

An additional problem with generic types is that it wouldn't be able to accommodate some of the existing features like generated route names.

[spydon]

My understanding was that because enums/strings have no common super-type, then using generics here would be counter-productive as it will lead for less type-safety (dynamic as the inferred type).

An additional problem with generic types is that it wouldn't be able to accommodate some of the existing features like generated route names.

Right, that was it, now I remember.

[spydon]

@st-pasha is there a plan for how to support routes opening overlays? I feel that is pretty important so that users aren't locked in to create menus etc as flame components.

[st-pasha]

Yeah, we have issue #1762 for that.

[erickzanardo]

I am still not sure about the Navigator name, internally me and @spydon discussed a little bit and the RouterComponent name could also be a good fit and I think I like it more.

Either way, gonna leave my approval in here.

[spydon]

I am still not sure about the Navigator name, internally me and @spydon discussed a little bit and the RouterComponent name could also be a good fit and I think I like it more.

Either way, gonna leave my approval in here.

For me both RouterComponent and NavigatorComponent are fine, but if you prefer RouterComponent maybe we should go with that then so that we can get this merged. :)