Skip to content
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

Fix static champion by ID #65

Merged
merged 5 commits into from
Jun 18, 2024

Conversation

hanscauwenbergh
Copy link
Contributor

Changes:

@Nico-Mayer
Copy link
Contributor

@hanscauwenbergh, I have some concerns about your proposed changes. The current implementation seems correct as we verify if the given ID matches any ID in the champions array. Then, we invoke the c.GetChampion function which requires a name argument, subsequently returning the correct champion. Your suggested alteration might potentially break this functionality.

One potential improvement we might consider is to avoid redundant calls to c.GetChampion. Fetching champion data twice seems unnecessary and could be optimized. However, I'd need to delve deeper into this to confirm.

@hanscauwenbergh
Copy link
Contributor Author

@Nico-Mayer Mm, thanks for the reply. It looks to me the c.GetChampion(name string) is wrong as the DataDragon endpoint seems to expect the ID, not the name.

For Wukong (ID: MonkeyKing, name: Wukong, see link)GetChampion("Wukong") returns an error, while GetChampion("MonkeyKing") returns the expected data.

Shall I update the argument's name and update the call sides?

@Nico-Mayer
Copy link
Contributor

@hanscauwenbergh Ah, I now see what you mean, and I think you're right. While the current implementation works for most champions, it will fail in the case with Wukong that you mentioned. Therefore, we need to update the argument names and possibly some existing tests. @KnutZuidema might be able to provide more insight on this.

@KnutZuidema
Copy link
Owner

KnutZuidema commented May 22, 2024

@hanscauwenbergh does it always work with the Champion ID? I'm a bit fuzzy on the relationship between Key, Name and ID.
Before merging this I'd like to understand this a bit better and document it if possible.
Right now, the function GetChampionByID does not make a lot of sense: it matches the input parameter id on the field champion.Key and then uses the champion.ID to fetch a champion by name using GetChampion.

@Nico-Mayer
Copy link
Contributor

@KnutZuidema @hanscauwenbergh This change would be a breaking one, so it might be better to remove the GetChampion function altogether. Instead, we can create three distinct functions: GetChampionByID, GetChampionByName, and GetChampionByKey. This would make their purposes clearer.

From what I understand, the relationship between Key, Name, and ID is as follows: the Key is an integer representing the champion's release order, the ID is a code name that can be similar to the Name field but dont has to be, and the name is the actual name of the champion.

@KnutZuidema
Copy link
Owner

Thank you for the explanation @Nico-Mayer 🙏🏼

I think the bug here is that I assumed that the DDragon endpoint would use the champion name as a parameter, but it uses the ID instead. That means the implementations of GetChampion and GetChampionByID should actually be the inverse of what they currently are:

  • GetChampionByID should either return the cached value or fetch it directly from the DDragon API
  • GetChampion should determine the ID from listing all champions and defer to GetChampionByID

@hanscauwenbergh
Copy link
Contributor Author

@KnutZuidema Appreciate the input, I've updated the code according to your suggestion but let me know if it'd need any further changes 🙂

@KnutZuidema KnutZuidema enabled auto-merge (squash) May 30, 2024 20:38
auto-merge was automatically disabled June 15, 2024 16:09

Head branch was pushed to by a user without write access

@KnutZuidema KnutZuidema merged commit 757298b into KnutZuidema:master Jun 18, 2024
2 of 3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants