Possible to add entryid to the get_entry_picks function?

[wiscostret]

Hi, you´ll need to provide more detail, because this doesn´t make much sense. ´entryid´ is a parameter you are supplying the function, so not sure if/why/where you´re looking for the function to return that parameter.

[vibhormbic91]

You're right. I should have provided more context. I'm sorry about that.In most cases, this function will be used when somebody includes this in a loop and is trying to pull the information for a lot of FPL managers. In those cases, they have to manually add a column every time. This slows the process down a touch. Not a huge effect when you use it for a handful of FPL managers but when you use it for say, 1000 FPL managers, the effect starts to show up. If you can include that in the function, I believe the utility will increase. Not a huge thing, though.Either way, thanks for all the work you've put into this. I use the package every week and I appreciate everything you've done. Vibhor AgarwalJunior Analyst, Research & DevelopmentTampa Bay Rays+1 (646) 633-2198

On Monday, 27 July, 2020, 09:17:30 am GMT-4, Rasmus Christensen <notifications@github.com> wrote:  

Hi, you´ll need to provide more detail, because this doesn´t make much sense. ´entryid´ is a parameter you are supplying the function, so not sure why/where you´re looking for the function to return that parameter.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[wiscostret]

Thanks for the clarification Vibhor. This is indeed a good use case, but one where I think the suggested update may be of limited help given the function design. It´s simple to add, but not sure how helpful it is.

At present the function returns the full "list of lists" for player picks - active_chips, automatic_subs, entry_history and picks. I believe all of this data should be available through fplscrapR.

If ´entryid´ was added to this list of lists by the function, you´d likely still need a bit of data manipulation to make it useful for a loop because you have to select out the particular list you are interested in. For instance with the suggested update, if you want a data frame with the player picks only and the entryid:

picks <- get_entry_picks(1076,1)

my_df <- data.frame(picks$picks, picks$entryid)

This isn´t much better, if at all, than what you can do now, I think, even if you run a 1000-page loop:

picks <- get_entry_picks(1076,1)

my_df <- data.frame(picks$picks, teamid=1076)

An alternative solution is to add in the entryid to each of the lists, e.g. to the picks list and to the automatic_subs lists, but some of these lists have their own list of lists as well, so it spirals a bit from there. Could also create a new function (e.g. get_entry_player_picks()) that returns only the player picks list ($picks), and lets the function add an entryid column. I have thought about this solution a lot, since it is a general issue with the FPL API structure, but as of yet the package generally favours returning the list of lists that users can then manipulate themselves, rather than having a larger number of specifically-targeted functions.

[vibhormbic91]

Thanks for the detailed clarification. The solution you're recommending is similar to how I pulled this information. If that's how you will have to do it in the function as well, then yes, there's no difference. I thought we could potentially pull it from the FPL API directly. No worries. Feel free to close the issue request, in that case. Thanks again. Vibhor AgarwalJunior Analyst, Research & DevelopmentTampa Bay Rays+1 (646) 633-2198

On Tuesday, 28 July, 2020, 04:18:32 am GMT-4, Rasmus Christensen <notifications@github.com> wrote:  

Thanks for the clarification Vibhor. This is indeed a good use case, but one where I think the suggested update may be of limited help given the function design. It´s simple to add, but not sure how helpful it is.

At present the function returns the full "list of lists" for player picks - active_chips, automatic_subs, entry_history and picks. I believe all of this data should be available through fplscrapR.

If ´entryid´ was added to this list of lists by the function, you´d likely still need a bit of data manipulation to make it useful for a loop because you have to select out the particular list you are interested in. For instance with the suggested update, if you want a data frame with the player picks only and the entryid: picks <- get_entry_picks(1076,1)

my_df <- data.frame(picks$picks, picks$entryid)

This isn´t much better, if at all, than what you can do now, I think, even if you run a 1000-page loop: picks <- get_entry_picks(1076,1)

my_df <- data.frame(picks$picks, teamid=1076)

An alternative solution is to create a new function (e.g. get_entry_player_picks()) that returns only the player picks list ($picks), and lets the function add an entryid column. I have thought about this solution a lot, since it is a general issue with the FPL API structure, but as of yet the package generally favours returning the list of lists that users can then manipulate themselves, rather than having a larger number of specifically-targeted functions.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[wiscostret]

Thanks again for the comments. I agree it really should be in the API - the FPL team have decidedly not structured it to be used by outsiders (in fact, they seem to actively discourage people from using it), which is a strange business approach but eh. Let me know any future issues or suggestions!