Enhance QueryString in blazor

[Thaina]

I would like blazor to provide better management and handler for querystring of current page url

[FromQuery] attribute for two way binding

It should allow binding to a field and/or property, so that it would always binded with query string with the same name as the property

@code {
        [FromQuery]
	int size = 0;
        [FromQuery("queryName")]
	int internalName = 0;
        [FromQuery("date","yyyyMMddHHmmss")] // with format?
	DateTimeOffset internalName = DateTimeOffset.Now;
}

NavigationManager

Should provide API for URI manipulation and history

public static Uri WithQuery(this Uri uri,string name,string value)
{
    // anything better with the same result?
    var query = HttpUtility.ParseQueryString(uri.Query);
    query[name] = value;
    return new UriBuilder(uri){ Query = query.ToString() }.Uri;
}

void GetAbsoluteUri(this NavigationManager manager) => manager.ToAbsoluteUri(manager.Uri);

// navigateTo(uri.WithQuery())
void SetQuery(this NavigationManager manager,string name,object value);
void SetQuery(this NavigationManager manager,params (string name,object value)[] values);

string GetQuery(this NavigationManager manager,string name);

/////////

// localhost/?q=0 >>> localhost/?q=1
navManager.SetQuery("q",1);
navManager.SetQuery("q",int.Parse(navManager.GetQuery("q")) + 1);

Underlyingly should just call history.pushState if available

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[TanvirArjel]

I have created a library called TanvirArjel.Blazor which extending the NavigationManager to facilitate the query string handling in Blazor and many more. Here is the source code:

https://github.com/TanvirArjel/TanvirArjel.Blazor/blob/main/src/TanvirArjel.Blazor/Extensions/NavigationManagerExtensions.cs

[terrajobst]

I wonder if the NavigationManager APIs are needed at all. It seems desirable that when I bind a property to a query string parameter that changing the property can also cause the query string to change. This design also avoids users having to format the values as strings. However, I can see an argument that this behavior should be opt-in. One option is to use a secondary attribute, another is to extend the attribute:

@code {
    [QueryParameter("q", IsTwoWay=true, ReplaceHistory=true)]
    string Query { get; set; }
 
    [QueryParameter(IsTwoWay=true)]
    int Page { get; set; }
}

Now imagine my search form's input is data bound to the Query property and is synced on each key stroke. The URL is now updated on every keystroke but the history is replaced instead of getting pushed a new state each time. Neato!

Further imagine I have paging buttons that handle navigating to different pages in my result. Again, just updating the Page property will be reflected in the URL but each time I navigate, I get a new state, so back and forward buttons work as you'd expect. Double neato!

[AmSmart]

@terrajobst This looks good!

[Thaina]

I wonder if the NavigationManager APIs are needed at all. It seems desirable that when I bind a property to a query string parameter that changing the property can also cause the query string to change

Sometimes we might need to have dynamic name of querystring, that was api to allow that

var jobj = JObject.Parse(@"{ "name0" : "value0","name1" : "value1","name2" : "value2" }"); // actually got from RPC

foreach(var prop in jobj.Properties())
    navManager.SetQuery(prop.Name,prop.Value);

[ghost]

Thanks for contacting us.

We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[terrajobst]

Sometimes we might need to have dynamic name of querystring, that was api to allow that

That makes sense to. Sadly, it seems the team isn't going to prioritize this 😢

[Thaina]

@terrajobst I think they have planned alright. It actually pretty solid so there are not much to talk about but I don't think they missed it

[terrajobst]

Nice! I just misunderstood the comment from the bot. Please ignore me, I don't know what I'm talking about :-)

[MackinnonBuck]

Related querystring work has been completed as tracked in #33338.