Tibble output via tibblify

[krlmlr]

The tibblify package allows for a much more robust approach than jsonlite::fromJSON(simplifyVector = TRUE) . We can infer a schema from the data (as R code) and then use that schema when coercing the data to a tibble. This gives type stability at the highest level possible, while automating the generation of boilerplate code.

I used the following workflow:

• Query objects from the demo API (currently only teams and spaces)
• Use tibblify::tibblify() to automatically convert to a tibble, double-check
• Use tibblify::get_spec() to get the specification (=schema)
• Implement a cuf_() function
• Add a test for that function
• Rinse and repeat

This PR is not how PRs should be done. Unfortunately, the commits build one upon another. Can you please review the commits individually and let me know which you don't agree with?

How do we proceed? Would you like to pick up from here, do you need more help?

@mgirlich: I'm not sure why I had to do 7a93fc7 manually, why this wasn't inferred from the data.

[psolymos]

Thank you @krlmlr this looks like a nice way of tibblifying the responses. Let me check your additions and try to do the same for a few more endpoints to see if anything unexpected comes up with the approach.

I also like the testing to be based on the mock Apiary server. This can be added to the cu_ functions too.

I am also wondering if adding the cuf_ functions can be automated using your workflow to add new functions and tests. I would like to either (1) keep related functions in the same file, or (2) be able to sort them to see those next to each other (cu-xxx.R and cu-xxx-tb.R for alphabetical sorting).

[krlmlr]

Thanks.

I added a few tests for cu_*() .

I only have a semi-automatic way of adding the cuf_*() wrappers -- see script/tibblify.R. Most likely we need to refine what tibblify::get_spec() returns; we also want to e.g. convert ClickUp times to proper times. I kept related functions in the same file.

[psolymos]

The date handling can be done as lcol_dat("dob", .parser = ~ cu_date_from(.x)) [not tested, just inferred from docs].

Do you think the inverse-tibblify could work for POST requests? Or should we restrict the scope here to GET requests?

[krlmlr]

Let's focus on GET first, need to understand the best structure for POST and friends.

[krlmlr]

One more thing: It might be useful to export the step that converts a cu_*() list to a tibble in a separate function, to aid debugging and reprexing.

[mgirlich]

@krlmlr Probably it was actually inferred from the data but just not printed as there was a bug in the printing :-/ Can you try out with the dev version?

[krlmlr]

I think the following getters would be most important in the beginning:

• [x] cu_get_folders()
• [x] cu_get_lists()
• [x] cu_get_tasks()
• [x] cu_get_time_entries_within_date_range()
• [x] cu_get_singular_time_entry()
• [x] cu_get_list_members()

[krlmlr]

I'll take another stab here.

[krlmlr]

I added https://github.com/krlmlr/clickrup/blob/f-data-frame/script/README.md that describes the process and the next steps.

[krlmlr]

It looks like a few more days of work to complete this, including a test workspace and automated tests.

[krlmlr]

It looks like the mock API is still available, via https://private-anon-bcbe6af027-clickup20.apiary-mock.com/api . Need to double-check the access token.