TwitterSharp
TwitterSharp copied to clipboard
Xwilarg
implemented NextTweetsAsync for GetTweetsFromUserId
The PR itself looks good to me but the main issue is that it would break the compatibility with the previous version What do you think of it, @marcogruhl ?
if breaking compatibility is a big issue here, could add this, but was attempting to keep the next token functionality the same for User and Tweet Lists:
public Func<Task<Tweet[]>> LoadNextTweetsAsync;
and set the function inside GetTweetsFromUserIdAsync,
LoadNextTweetsAsync = data.Meta.NextToken == null ? null : async () => await NextTweetsAsync(query, data.Meta.NextToken, Endpoint.UserTweetTimeline);
The PR itself looks good to me but the main issue is that it would break the compatibility with the previous version What do you think of it, @marcogruhl ?
It looks good to me too. It extends the functionality and make it more consistent with the other functions. That said, i dont like, that only one function is "updated". If there are breaking changes we should do it for all functions with next_token consistently. Maybe also do it more general. E.g. Combine NextTweetsAsync and NextUsersAsync into one function with generic return. But this can be done later without breaking changes ...
I just came across the idea to use an optional out parameter for the next token to avoid breaking changes. not completely aware if this works. i remember similar discussions for the rateLimits. That said, this PR could be the start of a new major release and i will refactor the rateLimit functionality!? So every answer had data, ratelimit and data (array or object) @bmclane sorry for the unconviniances @Xwilarg what do you think about the major release idea?
We could use that to make a new major, it would be interesting to see if there is any other breaking change we want to push with it tho
No worries @marcogruhl, I added the previous token to finish the next/previous token handling.
I guess we can make a new branch for the 3.0 and merge it there instead of master
Happy new year!
between the days i found some time to try some ideas for V3. you can look at it under my branch (based on @bmclane #46 ): GeneralRequest
My intention for this is to make a "general request" like GetEndpoint(id) => Request(id, Endpoint) so we can implement every endpoint with mostly one line of code.
I would define the primary goals for V3:
- Full App-Scope implementation
- RateLimit response with every request
secondary goals:
- Full User-Scope implementation
- 3-legged OAuth
so far:
- Full tweet endpoints implementation
- working general requests
- less breaking implementation of @bmclane PR (inherit from List
for Page/Response (RArray) object - problems with user scope (auth)
- remove RateLimit eventhandler or keep it in parallel?
Any thoughts about this?
Happy New Year, I think it's a good idea
I'm also using this topic to ask you if you would like to speak directly about that on some others platform such as Discord, I think it would help to move things quicker especially on a topic such as this one that goes over the scope of the current PR
Happy New Year, I think it's a good idea
I'm also using this topic to ask you if you would like to speak directly about that on some others platform such as Discord, I think it would help to move things quicker especially on a topic such as this one that goes over the scope of the current PR
send you a friend request. maybe we can open a channel with @bmclane and others (later hopefully 😅)
Looking forward to having usage of the next_time for my use case.
If there is a branch for this I'm happy to trial this in my own app.
