Open gilliganondata opened 3 years ago
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
s_simple("tablet")
# [1] "CONTAINS 'tablet'"
s_exact("tablet")
# [1] "MATCH 'tablet'"
s_begins_with("tab")
# [1] "BEGINS-WITH 'tab'"
s_any_exact(c("one", "two", "three"))
# [1] "(MATCH 'one') OR (MATCH 'two') OR (MATCH 'three')"
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.
aw_freeform_table(
dimensions = c("device", "page"),
search = c(s_simple("tablet"), s_exact("/mypage.html"))
)
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'"))