Feature Request: ?global? object for spec file

[bms63]

Background

IS there a way to make my adds_spec file into some type of object that the xportr_ functions can access without have to call it over and over again.

Have:

 adds %>% 
  select(adds_spec$variable) %>% 
  xportr_order(adds_spec) %>% 
  xportr_label(adds_spec) %>% 
  xportr_format(adds_spec)

want:

 adds %>% 
  select(adds_spec$variable) %>% 
  xportr_order() %>% 
  xportr_label() %>% 
  xportr_format()

I've seen you all do some skulduggery awesomeness with R so wondering if this is something we can set up for users or show users how to do in an articel. @elimillera

Proposal

See #16 (comment)

We discussed folding in an additional aspect with this issue: reducing duplication of arguments in a pipeline. Right now, the metadata and possibly the domain must be specified at every step of a pipeline. The goal I have in mind is to be able to run something like this:

adsl_data %>%
xportr_set(metadata_obj, optional_domain) %>%
xportr_type() %>%
xportr_length() %>%
...etc.`

Questions

• How to reduce burden on user?
• Warnings and Errors when not used properly

Definition of Done

• Create function that reduces burden of repetitive entries in xportr functions
• Downstream functions are not impacted, i.e. xportr_ functions can be used without this function
• Unit Tests created and documentation written

[elimillera]

Possible idea: Attach metadata to object in 'xportr' calls

[bms63]

This is sort of similar to @EeethB proposal in #16. If we want this update, shall shall we use this for the creating the function? I think the other issue that has the proposal is a bit different.

[EeethB]

Yes 🤦 I did not notice there was a separate issue for this part. Thanks for pointing it out!

[vedhav]

Yesss! This is a great idea.
Since different xportr_* functions use different specs (xportr_order uses ds_vars specs while the xportr_label uses var_spec) I like the idea of xportr_set() to set all the metadata in one place.

My question is, Does it make the life of the end user easier if we ask them to set all the metadata at once?
Because currently, users have the flexibility to use xportr with just var specs and not worry about other specs (if they don't plan to use other specs). As I don't use this in my work I'm not sure of things like this and the overhead associated with setting all the metadata at once.

Of course, we can make the xportr_set() more robust to work with partial spec and throw errors when a particular function is run without the required spec set by the xportr_set(). And, this seems like a good way to group all the spec-related functions and doc together which is super clean so I'm all in for this :)

[bms63]

@elimillera Since we have the people-power right now - I added this to the Milestone for xportr 3.0 release

[bms63]

@atorus-research/xportr-development-team Hi all, I spruced up this issue a bit. @EeethB hoping you are still wanting to tackle this one! :)