You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've got a derived Flop schema that specifies a custom field for filtering. The challenge I'm presented with, is that I want to apply a default where-constraint when no filter is chosen at all (e.g. the respective query parameter in the url is not set). There is no one-to-one relation between the chosen filter value in the UI and the actual where-constraints (hence the need for custom logic, and why a regular field won't work). In my case, not choosing a filter value in the UI should also apply a where-constraint. I don't want to apply the default filter if a certain value is chosen for the filter (this is just to say that the default filter is not always present).
I'm not sure how to go about this. Right now I manipulate the query myself, after inspecting the Flop.filters field (I run Flop.validate/2 explicitly, and then later Flop.run/3 with the modified query). In addition, I added a custom field with a no-op filter (just returning the unmodified the input query). This basically is a hack to shoehorn my custom logic into the Flop way of passing in filter values.
Am I missing something obvious here? I think Flop chooses somewhere deliberately that a custom field filter is not triggered, if there is no value detected. This probably works 99% of the times.
I welcome any suggestion to improve my existing solution.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hey,
I've got a derived Flop schema that specifies a custom field for filtering. The challenge I'm presented with, is that I want to apply a default where-constraint when no filter is chosen at all (e.g. the respective query parameter in the url is not set). There is no one-to-one relation between the chosen filter value in the UI and the actual where-constraints (hence the need for custom logic, and why a regular field won't work). In my case, not choosing a filter value in the UI should also apply a where-constraint. I don't want to apply the default filter if a certain value is chosen for the filter (this is just to say that the default filter is not always present).
I'm not sure how to go about this. Right now I manipulate the query myself, after inspecting the
Flop.filters
field (I runFlop.validate/2
explicitly, and then laterFlop.run/3
with the modified query). In addition, I added a custom field with a no-op filter (just returning the unmodified the input query). This basically is a hack to shoehorn my custom logic into the Flop way of passing in filter values.Am I missing something obvious here? I think Flop chooses somewhere deliberately that a custom field filter is not triggered, if there is no value detected. This probably works 99% of the times.
I welcome any suggestion to improve my existing solution.
Beta Was this translation helpful? Give feedback.
All reactions