-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
[Feature] Bind Navigation Parameters directly to ViewModel #1746
Comments
LMAO @aritchie I love this issue if for no other reason than that hashtag! So just a thought it's pretty common to camelCase NavigationParameter keys... with a TitleCased property name... so should this be doing an equals or equals ignore case? |
This is an interesting proposal. And isn't limited to XF. If this feature gets implemented i'd suggest to introduce some attributes to control the binding.
I'm not sure which of the following attempts is the better one, but there may be properties which aren't always present in the navigation parameters. The first option could be the The second options is exactly the other way around. Optional Properties are marked with an @dansiegel To solve the camelCase, TitleCase issue: an overload acceptiong an |
I think the nav parameter matching should be case sensitive when using “by convention/no parameter attribute” binding. A next evolutionary step with by to do a BindFrom - find all public get properties from previous view model and bindto navigating viewmodel. These prop names should match 1-1. As for the attributes, I don’t think ignore is a good idea. Perhaps a secondary argument for implicit by convention binding vs explicit attribute only would be better (opt in/opt out style). [NavParameter(Name=“optional”, Required=true/false)] should accomplish a well rounded set of goals for the initial release. |
have to admit this is growing on me... just not as proposed... unless I've misunderstood your goal... your goal seems to be to quickly initialize your ViewModel based on the Navigation Parameters which brings us into the realm of issue #1724 What I'm thinking is this might look instead more like: public class ViewAViewModel : IAbracadabra
{
[AutoProperty("title")]
public string Title { get; set; }
} The idea here is that we instead introduce an empty marker interface to ensure it's opt-in... then the NavigationService can automatically set the ViewModel the same as what you have proposed... thoughts? |
You got it. Parameter name should be implied if not set (name optional). Also, a IsRequired=bool. Though, The problem with the attribute opt-in effect is that you aren’t really saving code. You’re trading apples to apples. |
@aritchie so you're thinking this should throw exceptions if you have an IsRequired and it doesn't exist? |
I would say that if you use the Maybe something like
|
In cases where attributes are used yes. My big thing is only using attributes in required scenarios otherwise you end up trading Parameter.GetValue for [AutoProperty] |
Correct. Out of the box it just works when this condition is true (no attribute needed)
This condition would pass: This condition would fail: Use of attributes required when
Given:
This condition would pass: How does that look? |
Dead sexy |
why make it case-sensitive? Url parameters are usually camel-cased, or hyphenated, so why make it required to have an attribute in order for camel-cased, or hypen-cased, parameters to be mapped to proper-cased(title-cased) property names? |
@powerdude I actually have the same feeling, but it's a tough decision as you never know how parameters and properties are being used and named in an app. It's a hard choice to make. |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Description
Add the ability to "bind" parameters from the INavigationParameters without having to pull them out yourself. This can save quite a bit of code in heavy parameterized navigation strategies.
Example
Expected Behavior
INavigationParameters.BindTo will loop through all parameters that were passed, find an equivalently named property and set it. This saves the user having to do:
Potential Additional Downstream Features
#WeQuit - yes, I can do the tests, docs, & PR 👍 Let me know if you're interested
Here's a rough implementation to start the thinking process
The text was updated successfully, but these errors were encountered: