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 thought about solutions to this myself. I wonder if it would be better to have a suite of functions that generate search strings instead?
It seems like it would be hard to know when we should modify the string and when we should leave it alone, especially for edge cases. But if we move the responsibility to the user, things get a lot simpler. Something like
And so on, etc. Sure it lacks the brevity of search = "tablet", but it also lacks the ambiguity, and reduces user error significantly. Inline they're a little ugly, but also not the worst.
Add support for two "simple" use cases for the
search
argument inaw_freeform_report
.This is based on the premise that a common use case will be simply filtering for a single value.
Currently, to do the simplest of searches requires nesting a single quote within double quotes:
search = "'tablet'"
Add support for passing a simple string to
search
and then have that string be searched as aCONTAINS
on the first dimension in the results:So,
search = "tablet"
would actually executesearch = "CONTAINS 'tablet'")
(theCONTAINS
isn't required in the API call, since that's the default).Also, possibly (?) extend this support to a vector format if the user really wants a simple CONTAINS on multiple dimensions:
search = c("tablet", "search")
would actually executesearch = c("CONTAINS 'tablet'", "CONTAINS 'recliner'"))
The text was updated successfully, but these errors were encountered: