Simplify FilteringParams

[abdulhaq-e]

Simplify FilteringParams

[abdulhaq-e]

There must be two types of filtering; server side and client side. For the server side, it's better not to force users using the library to a specific format. So perhaps we can somehow allow users to replace generateFilteringParams. For the default, I suggest using the recommended format from JSON API specs which is:

?filter[api]=value

So now the interface should look like:

export interface FilteringParam {
    value?: any;
    api?: string;
}

The api should include the field and operator. For example, in Django I have something like:
?filter[comment__author__age__gt]=20

For client side, I think we must force some domain specific language. That's why I created three other parameters: field, type, path although I forgot how I used them due to lack of documentation :. I think the above server side filter will translate to the following client side filter:

query = {
    params: {
        filtering: [{type: 'gt', path: 'comment.author', field: 'age', value: 20}] 
    }
}

I agree that the above filtering can be made cleaner and as you suggested elsewhere: allow users to override the operators and define their own ones.

What do you think we should target first? Allowing users to have a custom generateFilteringParams?

[remmeier]

true that a lot of flexiblity is needed in this area. After all they just provide a recommendation, not a specification. The generateFilteringParams sounds good. Having the type/operator seems quite common even tough it is not in the official recommendation.

Nevertheless I still hoping a bit for a similar API between client and server side filtering, at least for the typical use cases that come close to the official recommendation. Meaning that client side filtering would translate "filter[comment.author]" to a path "attributes.comment.author". Or maybe both should be supported, a server and client side filtering meachnism and a possiblity to translate the former to the later. Otherwise more work needs to be done in the UI to work with one or the other.

[abdulhaq-e]

Please have a look at #38 and #39 . I think what remains is the mapping from client side names to server side names. I already have apiName in the attribute definition. Maybe you want to have a go at implementing the mapping. NgrxJsonApi is aware of resourceDefinition which can then be used in generateFilteringParams for mapping.

[abdulhaq-e]

Only mapping remains. I'll close this since most of it has been done.