Powered by the new and amazing `unnecessary_ignore` lint.
We're not enabling this lint by default because being able to
temporarily use ignores that don't ignore anything is a powerful tool to
enable migrations. We should turn this lint on locally periodically,
though, and clean up all outdated ignores.
This auto-formats all *.dart files in the repository outside of the
`engine` subdirectory and enforces that these files stay formatted with
a presubmit check.
**Reviewers:** Please carefully review all the commits except for the
one titled "formatted". The "formatted" commit was auto-generated by
running `dev/tools/format.sh -a -f`. The other commits were hand-crafted
to prepare the repo for the formatting change. I recommend reviewing the
commits one-by-one via the "Commits" tab and avoiding Github's "Files
changed" tab as it will likely slow down your browser because of the
size of this PR.
---------
Co-authored-by: Kate Lovett <katelovett@google.com>
Co-authored-by: LongCatIsLooong <31859944+LongCatIsLooong@users.noreply.github.com>
This is simply removing unnecessary parenthesis from various places. This change is because of a change to the unnecessary_parentesis lint that will trigger there. Here is the CL https://dart-review.googlesource.com/c/sdk/+/390161.
- https://github.com/dart-lang/linter/issues/4996
If anything else is needed please let me know.
I'd like to ask for this PR to wait a bit until the bots are run again on that CL so that I can be sure nothing else will trigger, I will come back here and update this whenever everything is complete. Thanks!
This pull request aims to improve code readability, based on feedback gathered in a recent design doc.
<br>
There are two factors that hugely impact how easy it is to understand a piece of code: **verbosity** and **complexity**.
Reducing **verbosity** is important, because boilerplate makes a project more difficult to navigate. It also has a tendency to make one's eyes gloss over, and subtle typos/bugs become more likely to slip through.
Reducing **complexity** makes the code more accessible to more people. This is especially important for open-source projects like Flutter, where the code is read by those who make contributions, as well as others who read through source code as they debug their own projects.
<hr>
<br>
The following examples show how pattern-matching might affect these two factors:
<details> <summary><h3>Example 1 (GOOD)</h3> [click to expand]</summary>
```dart
if (ancestor case InheritedElement(:final InheritedTheme widget)) {
themes.add(widget);
}
```
Without using patterns, this might expand to
```dart
if (ancestor is InheritedElement) {
final InheritedWidget widget = ancestor.widget;
if (widget is InheritedTheme) {
themes.add(widget);
}
}
```
Had `ancestor` been a non-local variable, it would need to be "converted" as well:
```dart
final Element ancestor = this.ancestor;
if (ancestor is InheritedElement) {
final InheritedWidget inheritedWidget = ancestor.widget;
if (widget is InheritedTheme) {
themes.add(theme);
}
}
```
</details>
<details> <summary><h3>Example 2 (BAD) </h3> [click to expand]</summary>
```dart
if (widget case PreferredSizeWidget(preferredSize: Size(:final double height))) {
return height;
}
```
Assuming `widget` is a non-local variable, this would expand to:
```dart
final Widget widget = this.widget;
if (widget is PreferredSizeWidget) {
return widget.preferredSize.height;
}
```
<br>
</details>
In both of the examples above, an `if-case` statement simultaneously verifies that an object meets the specified criteria and performs a variable assignment accordingly.
But there are some differences: Example 2 uses a more deeply-nested pattern than Example 1 but makes fewer useful checks.
**Example 1:**
- checks that `ancestor` is an `InheritedElement`
- checks that the inherited element's `widget` is an `InheritedTheme`
**Example 2:**
- checks that `widget` is a `PreferredSizeWidget`
(every `PreferredSizeWidget` has a `size` field, and every `Size` has a `height` field)
<br>
<hr>
I feel hesitant to try presenting a set of cut-and-dry rules as to which scenarios should/shouldn't use pattern-matching, since there are an abundance of different types of patterns, and an abundance of different places where they might be used.
But hopefully the conversations we've had recently will help us converge toward a common intuition of how pattern-matching can best be utilized for improved readability.
<br><br>
- resolves https://github.com/flutter/flutter/issues/152313
- Design Doc: [flutter.dev/go/dart-patterns](https://flutter.dev/go/dart-patterns)
## Description
This adds `find.backButton()` in the Common Finders to allow finding different types of standard UI elements. It works by attaching a key made from an enum value in a new enum called `StandardComponentType` to all of the standard widgets that perform the associated function.
I also substituted the finder in several places where it is useful in tests.
This allows writing tests that want to find the "back" button without having to know exactly which icon the back button uses under what circumstances. To do it correctly is actually quite complicated, since there are several adaptations that occur (based on platform, and whether it is web or not).
## Tests
- Added tests.
Relands https://github.com/flutter/flutter/pull/150808
The original version of the pr [accidentally deleted the back button](https://github.com/flutter/flutter/pull/150808#discussion_r1655444210), which didn't block the app building but made the test hang because it couldn't back out of the demo pages.
Repro-ed the failure, and then tested that
```
new_gallery_opengles_impeller__transition_perf
new_gallery__transition_perf
new_gallery_impeller_old_zoom__transition_perf
new_gallery__crane_perf
new_gallery_impeller__transition_perf
```
All pass on my pixel 7 pro, with ` dart bin/test_runner.dart test -t <test>`, after re-adding the mistakenly deleted content.
Did not test on an iOS device (I don't have one), but those tests were failing for the same reason from what I can tell:
```
> reply@study
[2024-06-26 12:49:21.884543] [STDOUT] stdout: [ ] scrolling to demo
[2024-06-26 12:49:22.412479] [STDOUT] stdout: [ +527 ms] tapping demo
[2024-06-26 12:49:28.075978] [STDOUT] stderr: [+5663 ms] VMServiceFlutterDriver: tap message is taking a long time to complete...
```
Which is the same error, and which makes sense - they got stuck because they couldn't back out of the page.
Sorry for the churn ð
Reverts: flutter/flutter#150808
Initiated by: gmackall
Reason for reverting: Causing the new_gallery tests to hang.
I can repro now though, so should be able to find a fix shortly
Original PR Author: gmackall
Reviewed By: {christopherfujino, johnmccutchan, jtmcdole, jonahwilliams}
This change reverts the following previous change:
Removes the `dual_screen` package from `new_gallery`. Unblocks the fourth attempt to land https://github.com/flutter/engine/pull/53001.
### fixes#136139
<br>
<details open> <summary><b>getting sentimental in the PR description</b> (click to collapse)<br><br></summary>
The past 7 months have been quite the journeyâI made some huge blunders and some huge accomplishmentsâa very fun time overall.
I really appreciate the people who took the time to perform code review for my refactoring shenanigans: **christopherfujino**, **andrewkolos**, **LongCatIsLooong**, **gspencergoog**, **loic-sharma**, **Piinks**, **bernaferrari**, **bartekpacia**, **bleroux**, **kevmoo**, **rakudrama**, **XilaiZhang**, **QuncCccccc**, **MominRaza**, and **victorsanni**.
And a huge shoutout to 2 individuals:
- @justinmc, for offering to sponsor me for commit access (words could not describe my excitement)
- @goderbauer, for being super duper proactive and consistent with code review
<br>
</details>
This pull request makes 13 "switch statements â switch expressions" PRs in total, reducing the LOC in this repo by **1,974**!
From now on, I'll make sure to request a test exemption for each refactoring PR ð
PR #147801 introduced some convenient `AnimationStatus` getters, but I just realized that `AnimationController` now has 2 getters for the same thing: `isAnimating` and `isRunning`.
The intent of this pull request is to correct that mistake, and implement the getters in the appropriate places.
This PR is step 12 in the journey to solve issue #136139 and make the
entire Flutter repo more readable.
Most of it involves implementing switch expressions, and there's also a
few other random things that I wanted to clean up a bit.
Some cause of jank on both Skia and Impeller are these massive images. We should just resize them so that the noise is reduced and we can see other performance issues.
Fixes https://github.com/flutter/flutter/issues/147797
Tested: this is a test!
Here's another PR with a couple of typos fixed. As you can see there was a typo in _fileReferenceI**n**dentifiers_, in class _ParsedProjectInfo._ Maybe we should do some check on that since I'm not sure if that property is used somewhere outside Flutter?
This pull request aims for improved readability, based on issue #146600.
```dart
// before
Set<Color> _distinctVisibleColors() {
final Set<Color> distinctVisibleColors = <Color>{};
if (top.style != BorderStyle.none) {
distinctVisibleColors.add(top.color);
}
if (right.style != BorderStyle.none) {
distinctVisibleColors.add(right.color);
}
if (bottom.style != BorderStyle.none) {
distinctVisibleColors.add(bottom.color);
}
if (left.style != BorderStyle.none) {
distinctVisibleColors.add(left.color);
}
return distinctVisibleColors;
}
// after
Set<Color> _distinctVisibleColors() {
return <Color>{
if (top.style != BorderStyle.none) top.color,
if (right.style != BorderStyle.none) right.color,
if (bottom.style != BorderStyle.none) bottom.color,
if (left.style != BorderStyle.none) left.color,
};
}
```
Most of the repo should be covered in this PR (aside from `flutter_tools/`, since there was a lot going on in there).
Fixes https://github.com/flutter/flutter/issues/143482
This brings in the gallery more or less as is:
* Removed localizations
* Ensure tests still run (locally verified, will switch CI later).
* Removed deferred components
* Fixup pubspec
