Eliminate fetch_survey_obj step except for developers?

[sfirke]

The typical user won't get anything from the result of fetch_survey_obj, it's just an extra step. It's been very useful to me in developing the package but is a relic of that process.

What's the best way to smooth that out? We could keep it two steps behind the scenes, and leave those functions accessible for those who want them, but chiefly promote a new function that would call both in one step. So maybe get_responses(1234567890).

a) is this the way to proceed? b) what should these three functions be called (currently fetch_survey_obj, parse_survey, and the third doesn't exist)? Ideally we'd establish some kind of coherent naming scheme.

[dpashouwer]

Really like the idea of having a third function that does both fetch_survey_obj and parse_survey. This would make it very simple for users; 1) browse_survey() to identify survey id, 2) use survey id in get_responses, then you have a tibble and are ready to start.

[dpashouwer]

Re naming scheme: If we want to follow the googlesheets package "gs_" scheme, maybe...
sm_ls(): Instead of current browse_surveys()
sm_fetch_survey_obj(): Instead of fetch_survey_obj()
sm_read(): Instead of parse_survey()

then,

sm_get_responses(): Both sm_fetch_survey_obj() + sm_read(). Like you mention, this would be the standard usage.

[sfirke]

I think I like the sm_ convention. Let's go with the user-facing function names you suggest, sm_ls() ("list surveys"?) and sm_get_responses(). Note that get_responses() is already a key internal function within the package so we'll need to rename that.

For developer functions, I could see splitting the parse_survey function into fetch_responses() and sm_assemble() with assemble being 95% of the current parse_survey. That would give us for debugging:

• sm_fetch_survey_obj() - get the survey object including the questions
• sm_fetch_responses() - get the respondents list
• sm_assemble() - this function takes the results of the first two functions and assembles them.

Then under the hood, sm_get_responses() calls the first two, then the third.

This wouldn't be a huge rewrite.

One outstanding question would be whether those 3 dev-facing functions should be exported, or internal. If internal we could still call them with ::: or get them via devtools load_all. I think anyone who could use these functions would be able to use them as internal function, so we can hide them from the user?