Skip to content
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

feat: Navigation will set parameters #1584

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

Conversation

linkdotnet
Copy link
Collaborator

This closes #1580

The basic idea here is to have a router that takes care of everything. There are a few open points. I will mark them here. We can discuss this next Friday, I just had some time to do the feature today and wanted to finish it as much as possible.

@linkdotnet linkdotnet requested a review from egil October 12, 2024 15:00
continue;
}

// Shall we await this? This should be synchronous in most cases
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here another "TODO"

@linkdotnet linkdotnet force-pushed the navigation-properties branch 2 times, most recently from c0bfe13 to 97cff02 Compare October 13, 2024 09:20
@linkdotnet linkdotnet force-pushed the navigation-properties branch from c3daea1 to b2137f1 Compare November 3, 2024 10:00
@linkdotnet
Copy link
Collaborator Author

linkdotnet commented Nov 3, 2024

Just some paper-trail for our future selfs:
To make that work with bids of ASP itself,we need:

  • RouteTable - that does all the nice URL segment parsing for us
  • That depends on TreeRouter, which is internal for the Blazor case (see: #ifdef !COMPONENTS).
  • That objects has then again a dependency that is internal for us as well: UrlMatchingTree

Assumption here is that we don't need the TreeRouter in the first place and can solely rely on RouteTable.Route method or even alternatively the internal static ProcessParameters method.

RouteTable.Route takes the TreeRouter unfortunately - so we are stuck to the limbo described above. The static version already wants a RouteData object - so the "parsed" version where the segments are already parsed to a IReadOnlyDictionar<string, object> (aka the heavy lifting!).

While properly all of that (at least three reflection invocations plus some more setup to create RouteView, HttpContext*, ...) works, I am not sure if writing the code itself (aka this PR) is so much worse.

* The RouteContext that is used by the TreeRouter inside Route does want a HttpContext. I am not sure if I am missing something - but why does it want this in the first place? It is not even used inside that object - and gets just gets it passed in from somewhere. So we also might have to setup a HttpContext here (at least so that it doesn't throw the ArgumentNotNullException in its ctor).

CC: @egil
Not sure if I missed something here or went offtrack.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Parameter not read from route
1 participant