-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tibble output via tibblify #5
base: master
Are you sure you want to change the base?
Conversation
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 I am also wondering if adding the |
Thanks. I added a few tests for I only have a semi-automatic way of adding the |
The date handling can be done as Do you think the inverse-tibblify could work for POST requests? Or should we restrict the scope here to GET requests? |
Let's focus on |
One more thing: It might be useful to export the step that converts a |
@krlmlr Probably it was actually inferred from the data but just not printed as there was a bug in the printing :-/ |
I think the following getters would be most important in the beginning:
|
I'll take another stab here. |
I added https://github.com/krlmlr/clickrup/blob/f-data-frame/script/README.md that describes the process and the next steps. |
It looks like a few more days of work to complete this, including a test workspace and automated tests. |
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. |
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:
tibblify::tibblify()
to automatically convert to a tibble, double-checktibblify::get_spec()
to get the specification (=schema)cuf_()
functionThis 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.