Add guidance to use composable functions instead of filter-as-segment feature#520
Add guidance to use composable functions instead of filter-as-segment feature#520
Conversation
OlgaPodo
requested review from
darrelmiller,
dkershaw10,
garethj-msft and
mikepizzo
|
|
||
| Doing this is beneficial due to the robust nature of OData filter expressions: clients will be able to dismiss risky users based on any supported filter without the service team needing to implement a new `dismiss` overload that filters based on the new criteria. | ||
| However, there are some concerns about the discoverability of using the filter-as-segment feature, as well as the support of [parameter aliasing](https://docs.oasis-open.org/odata/odata/v4.01/odata-v4.01-part2-url-conventions.html#sec_ParameterAliases) that's required. | ||
| As a result, functions should be introduced that act in the same way as the filter-as-segment: |
There was a problem hiding this comment.
I think naming a specific function as "filter" is very confusing for users who expect a standard $filter behavior. I believe it does not follow our naming guidelines without having a product-specific prefix. Unless we will treat this function similarly to delta?
There was a problem hiding this comment.
namespace qualification of functions is optional in msgraph.
There was a problem hiding this comment.
customFilter or filterFunction
OlgaPodo
added
Graph Guidelines
| @@ -0,0 +1,61 @@ | |||
| # Filter as segment | |||
|
|
|||
There was a problem hiding this comment.
Why is this positioned as an article? i think it make sense to create a pattern and clearly specify when this solution is a good one.
There was a problem hiding this comment.
This should probably just be included as another scenario of #512
We might rename 512 slightly to reflect this, but doesn't seem like this should be a separate pattern, when the pattern is "replacing a complex filter with a function".
|
|
||
| Doing this is beneficial due to the robust nature of OData filter expressions: clients will be able to dismiss risky users based on any supported filter without the service team needing to implement a new `dismiss` overload that filters based on the new criteria. | ||
| However, there are some concerns about the discoverability of using the filter-as-segment feature, as well as the support of [parameter aliasing](https://docs.oasis-open.org/odata/odata/v4.01/odata-v4.01-part2-url-conventions.html#sec_ParameterAliases) that's required. | ||
| As a result, functions should be introduced that act in the same way as the filter-as-segment: |
There was a problem hiding this comment.
customFilter or filterFunction
5 participants
Discussed previously, this PR adds the guidance to avoid the filter-as-segment OData feature and instead use a composable function which accepts an expression parameter for those scenarios where operations on filtered collections are desirable.