refresh
in cafun_create
: it will be TRUE
I think not wanting to cache something but instead expecting your cache-aware functions to behave just as "regular" R functions is by far the more typical use case.
Example updated (inst/examples/ex-cafun_main.R
)
Update README.md
inst/examples/ex-cafun_main.R
observes
in cafun_create
)cachefun_create
to caf_create
, cachefun_reset_cache
to caf_reset
.caf_create
more explicitly from those of the actual cafuns create by it. Also, probably a good idea to follow the example of {plyr}
to start meta args with a dot (.refresh
, .verbose
).caf_refresh
.{shiny}
to Imports
test-cafun_main.R
to account for changes.test-cafun_main.R:20180205-1
inst/examples/ex-cachefun_main.R
.caf_create
to R/_scripts/keep_as_reference
.BACKLOG.md
). The challenge here will be to keep track of the auto-increment state ;-) Think about this a bit more - especially regarding how to leverage/integrate with GitHub issue and labeling system.README.md
{shiny}
reactivity (made sure that cache results are automatically invalidated if cache value of dependency changes)caf_create
: observes
is a simple list nowcaf_create
if observes
is supplied (fun
is wrapped by reactive
)cafun
to caf
in caf_reset
cafun
to caf
to make things more concise and consistentcaf_create
caf_create
and the caf created by caf_create
in order to allow the correct handling of unnamed argument specification when calling the resulting caf. This should also make everything play nicely with the tidyverse approach.fun
to .fun
in def of caf
that is created inside caf_create
to be more consistent regarding "meta args" (e.g. .refresh
).verbose
and .verbose_default
) as I think one can do without them and they just cost compute time.test-caf_main.R
to reflect changes.ex-caf_main.R
to reflect changes.Add the following code to your website.
For more information on customizing the embed code, read Embedding Snippets.