Add query routing for different subpages about wharf-web

[applejag]

We have no good reason to try to also be building our own component library into this project because good libraries already exsist.

True. We had this discussion internally before, and we landed on reusing as much as possible. We definetly don't want to start a rewrite snowball effect here

What might be some other good ways of navigating through the interface? We might consider rewiring the backing interface to use a better subset of components that make using routes easier.

I've not spotted any features in PrimeNG that natively supports this, but we could place these different pages under different routes all together, instead of trying to mix the current tab-view with routes.

Like having the following:

URL	Desc
wharf.example.com/projects/123	Project builds list
wharf.example.com/projects/123?page=2	Project builds list, page 2
wharf.example.com/projects/123/configuration	Project configuration
wharf.example.com/projects/123/schedule	Project build schedules
wharf.example.com/projects/123/schedule?page=2	Project build schedules, page 2

And then let the "native Angular routing" deal with the rest. The exception is the page query parameters, but I feel more inclined in having them as query params than path params.

I think that impl would be simpler

[fredx30]

I am partial to supporting different kinds of solutions that ->

let the "native Angular routing"

it seems like the way to go.
Ill retract the source PR to a draft and add a on-hold for that untill we run some form of brainstorming session on this i think we could come up with some much better results that that PR. I hope that discussion can be postponed till after the auth project has been finished.

[fredx30]

@jilleJr I have a sample up @ #36 . Currently its using numberd indexes on the tabs. As the tabview component always uses numberd index rather than string keys it seems easiest. If we want stringifies keys i think we would have to maintain static maps for each implemented component.

I considered the possibility of further modifiying the extended tab-view class such that it inherently keeps track of its in the query params. I am not much in favor of extending classes in that form as it makes updates from the base class more difficult.

[applejag]

@fredx30 We might want to make our own custom tabbed view. It's not that complicated the way we use it, and if we make it our own then we can make sure we use <a> tags instead of buttons with the Angular routing so that we get the browser-native anchor tag features such as right click context menu and CTRL+LMB

[fredx30]

It seems like we would be trying to build on a paradigm that the component library we have never was meant to suppport. I think going on the path of trying to create generic components is an anti-pattern. We have no good reason to try to also be building our own component library into this project because good libraries already exsist.

What might be some other good ways of navigating through the interface? We might consider rewiring the backing interface to use a better subset of components that make using routes easier.

[applejag]

I am partial to supporting different kinds of solutions that ->

let the "native Angular routing"

it seems like the way to go.
Ill retract the source PR to a draft and add a on-hold for that untill we run some form of brainstorming session on this i think we could come up with some much better results that that PR. I hope that discussion can be postponed till after the auth project has been finished.

Sounds like a plan!

[applejag]

Potentially use this as reference: #36

It was using query params, so maybe with a grain of salt.