pdevito3
commented
1 month ago 👋 after briefly looking through the sieve FilterTerm object it could probably be done with a new stage of processing, but likely wouldn't be trivial.
Also, I'm honestly still not sure I get how the object representation gets used in these scenarios? Why/how would the UI state be tied directly to some output like this? I would think the UI is able to pass the input to the query and then take back the expected data. How does this object come into play?
It probably won't be high on my list, but I'm open to this if it's added in a maintainable way and you (or someone else want to take it on).
Regardless, would love to hear more about how this use case works
Hey!
First off, great job on the library! I haven't gotten around to using it yet, but it looks promising. As I was exploring its features, I noticed you mentioned being inspired by Sieve. Having used Sieve myself, I noticed a feature that seems to be missing in your library.
In Sieve, filters and sorting could seamlessly translate into a C# object (like in the SieveModel with GetFiltersParsed, for instance). However, in your library, although the approach is similar, the execution differs. Filters and sorting are directly translated into an Expression object, which, while efficient for its intended use, lacks versatility beyond its current scope.
I want to utilize the expressions provided by your methods for my EF query. Yet, I also want to use the parsing for my frontend. I need filters ans sorts in object format to show in the ui which filters are currently applied. However, as it stands, due to the structure of parsing, it doesn't seem feasible.
I believe this relates to issue #1.
I'm wondering if there's a way to achieve functionality similar to Sieve's parser, where translation directly yields a C# object, or if your library tends to lean towards only generating LINQ expressions.
I'm looking forward to hearing your thoughts on this!