Adding blocking and unblocking

[simonheb]

I was missing blocking and unblocking functionality.

Since muting was inside post_follow, I added blocking (and unblocking) to the same file. It's tested and worked for me.

[llrs]

Thanks! Not sure about adding new features with API v1, but it will be useful as a reminder. Could you add a test (add some existing "random" user). The code change seems minimal and without major issues (I think you need to document again the package though, as it fails on the CI checks due to this).

[hadley]

I'm uncertain if its a good idea to continue to add even more features to this already large function. Maybe it would be better to have new functions?

[llrs]

Yes, I had drafted a comment myself regarding this. However, I also hesitate to create new functions until #572 isn't merged and renaming all functions following previous discussions (I don't find the issue/PR were we discussed this now).

[simonheb]

not sure I understand the comment about v1? what is your preferred way to deal with functionally that does not yet exist?

I appreciate the feedback about not bloating this one function. Since I do not know what the general plans are regarding the overall structure I will not push for further additions.

[simonheb]

I've added the tests and documented it. Should work now.

[llrs]

There is a new API v2, currently rtweet is using API v1. There are many differences between the way to call data, the endpoints and the data returned.

Currently my efforts are to set up the package in better shape for adding support for API v2 as Twitter is clearly moving to use and update only API v2. I don't know how long it will take but API v1 will at some point be deprecated (years probably). Adding features is great, specially if they require few time and checks on my side. But this is also depends on how are they implemented and in relation to other functions. Just don't add features because they are cool but because you use them (or want to use them) and we'll find a way to get them included.

On this particular case it is true that post_follow is already doing many different so I think it is better to move it to its own function block_user(user, unblock = FALSE).

[simonheb]

But afaik the API v2 is not yet accessible outside of the early access program. Or am I misinterpreting this?

Yes, I implemented the blocking because I needed it for my app. I will move this into a new function like you suggested.

[simonheb]

ok, all [un]blocking functionality is now in R/post-block.R, in a separate function, as @hadley suggested.

[llrs]

The early access program is quite open to developers and lately they are doing events and explaining how to work with academictwitteR.
The package received a comment from one of the developers of Twitter around a year ago (see #402), so it is acceptable to provide support and move to the new API.

[simonheb]

Ok, interesting. I've been fiddling around with some code (e.g. to add support for fetching alt-text/captions for tweets with images, as I am using rtweet to run the bot @CaptionClerk). I was considering merging this functionality into rtweet, but maybe it's better if I wait until this has moved to the v2. I could also try to help with this, just give me a hint on where my contributions could be useful.

[llrs]

@simonheb Maybe you can tackle #566 (I had a PR on the wrong direction #567)

[hadley]

Should these be user_block() and user_unblock()? Or block_user() and unblock_user()?

[simonheb]

I agree that block_user() and unblock_user() are more intuitive. Will change this.

[llrs]

About the naming convention we discussed this on #480. I think user_block() and user_unblock() makes more sense and it is following the first suggestion from this comment and the first suggestion from Hadley (sorry you need to rename this functions again).

[simonheb]

ok no worries, fair point. I was not aware of #480. would it additionally make sense to rename the file post-block.r to something else?

[llrs]

Oh, I hadn't tough about renaming files, probably it would be nice to have matching files (so user-block.R). But don't worry if you don't, soon I'll start a new PR to rename all functions and then I'll see if renaming files makes sense.

[simonheb]

Okay, then I wont rename this. Probably best to keep this separate

[ronnicolasp]

Please allow me to join in! Can I contribute?

[llrs]

Hi @ronnicolasp, what do you want to join? What do you want to contribute?

[llrs]

I updated the PR with recent changes, added some tests and changed the user on the examples.
I'm still not decided about the names, the point on #480 about tab completion is compelling (user_block, user_block_destroy) but at the same time I wish it felt more natural to the users (user_block, user_unblock).