Handle missing playerId in buildViewWithOptions#11461
Handle missing playerId in buildViewWithOptions#11461aesmaili wants to merge 1 commit intoflutter:mainfrom
Conversation
Handle the case where buildViewWithOptions is called with a playerId that is not or no longer in the active players map. Return a Container() instead of throwing a StateError.
|
It looks like this pull request may not have tests. Please make sure to add tests or get an explicit test exemption before merging. If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix? Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. If you believe this PR qualifies for a test exemption, contact "@test-exemption-reviewer" in the #hackers channel in Discord (don't just cc them here, they won't see it!). The test exemption team is a small volunteer group, so all reviewers should feel empowered to ask for tests, without delegating that responsibility entirely to the test exemption group. |
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
There was a problem hiding this comment.
Code Review
This pull request adds a check to buildViewWithOptions to return an empty widget if the playerId is not present in the _players map. The review feedback suggests using SizedBox.shrink() instead of Container() for idiomatic Flutter code, optimizing the map lookup to avoid redundant calls, and adding a unit test to verify the logic change.
| if (!_players.containsKey(playerId)) { | ||
| return Container(); | ||
| } | ||
| final VideoPlayerViewState viewState = _playerWith(id: playerId).viewState; |
There was a problem hiding this comment.
Using const SizedBox.shrink() is preferred over Container() for returning an empty widget as it is more lightweight and idiomatic in Flutter. Additionally, this approach avoids a redundant map lookup by retrieving the player instance once and checking for null, rather than using containsKey followed by _playerWith (which performs another lookup and throws).
| if (!_players.containsKey(playerId)) { | |
| return Container(); | |
| } | |
| final VideoPlayerViewState viewState = _playerWith(id: playerId).viewState; | |
| final _PlayerInstance? player = _players[playerId]; | |
| if (player == null) { | |
| return const SizedBox.shrink(); | |
| } | |
| final VideoPlayerViewState viewState = player.viewState; |
References
- Code should follow the relevant style guides (Flutter/Dart) which prefer SizedBox.shrink() for empty widgets. (link)
| if (!_players.containsKey(playerId)) { | ||
| return Container(); | ||
| } |
There was a problem hiding this comment.
This logic change should be accompanied by a unit test to verify that buildViewWithOptions correctly handles missing player IDs by returning an empty widget instead of throwing an exception. Per the repository style guide, all code changes should be tested to ensure correctness and prevent regressions.
References
- Code should be tested. Changes to plugin packages should have appropriate tests. (link)
|
Thanks for the contribution! You haven’t checked off any of the items in the PR checklist above, so I’m assuming this is a work in progress and am marking it as a Draft. Please review the checklist, updating the PR as appropriate, and when that’s complete please feel free to mark the PR as ready for review. |
Handle the case where buildViewWithOptions is called with a playerId that is not or no longer in the active players map. Return a Container() instead of throwing a StateError.
Replace this paragraph with a description of what this PR is changing or adding, and why. Consider including before/after screenshots.
List which issues are fixed by this PR. You must list at least one issue.
Pre-Review Checklist
[shared_preferences]///).If you need help, consider asking for advice on the #hackers-new channel on Discord.
Note: The Flutter team is currently trialing the use of Gemini Code Assist for GitHub. Comments from the
gemini-code-assistbot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.Footnotes
Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩2