Closed maxlapides closed 1 month ago
@srawlins
More or less a duplicate of https://github.com/dart-lang/sdk/issues/48401
I would like to keep the
super.key
on the private widgets, but I also want to keep theunused_element
rule enabled. Is there any way to achieve this?
No I don't think so. If you want to keep an unused parameter on your private widget, you will keep getting an unused_element
report.
How does this relate to user_super_parameters
? If you remove the named parameter (and pass null
directly) do you get a user_super_parameters
report?
@srawlins It's related to the super parameters because this breaks unused_element
:
class _MyWidget extends StatelessWidget {
const _MyWidget({super.key});
@override
Widget build(BuildContext context) {
return Container();
}
}
But this does not:
class _MyWidget extends StatelessWidget {
const _MyWidget({Key? key}) : super(key: key);
@override
Widget build(BuildContext context) {
return Container();
}
}
This doesn't really have much to do with the lint rule use_super_parameters
, but rather just the new Dart 2.17 super parameters syntax.
Oops, that second example should also have an unused_element
report, since no argument is ever given.
It's super common in Flutter to have this key
parameter on all widgets, regardless of whether the key
parameter is ever used. It would be great to be able to disable unused_element
just for the key
s in Flutter.
I can update the title of this issue to make that the ask.
@srawlins That would be great, thanks!
@srawlins @maxlapides this issue looks perfectly legit to me, why would you want to shut a warning about an unused element ?
Implementing super with key
is legit on a public widget because you could want to export it as a library widget in which case you want to make sure you offer the possibility to give a key to anyone using your widget. However in the case of a private widget, if you are not using the key
when calling your widget, why declare the key
?
To go further, I don't think that the new super parameters syntax has an issue, on the contrary I think that the old syntax should also trigger this unused_element
warning on private widgets, to me that's the real issue 🙂
I agree with the previous comment. There's no reason to have the key
parameter on a private widget if nobody is using it. If you need to pass the key, you can always add it to the private widget since you're in full control of the code.
For a public widget (that may get exported from a library you don't have control over) you want to make sure it can always take a key. If the key parameter is omitted, you'd have to ask the library author to release a new version with the key parameter added.
I'm not strongly opposed to removing the key
parameters on the private widgets, but I do think there's a reasonable argument to be made that it is less work to have the super.key
on all the private widgets because it's generated by a code snippet. Then, it's always available when you need it later, you don't need to go add it manually by editing a file that you may not have otherwise needed to touch.
I agree with Max. It's common for widgets to have key parameter whether they are public or private.
And it seems there have been an exception for the key parameter in unused_element
rule because this
const _MyWidget({Key? key}) : super(key: key);
looks legit for it.
Also it's more likely to forget to add the key whenever I want to make my private widget a public.
If there is not a report for unused_element for const _MyWidget({Key? key}) : super(key: key);
, then I believe there is a bug in unused_element.
I understand your point of view although I disagree :
key
on public widgets but there is a linter rule specifically designed for this case : use_key_in_widget_constructors
which will make sure you never forget a key on public widgets 😉Generally speaking, the unused_*
and unnecessary_*
rules come from a policy of rejecting the "but I might need it later" argument in favor of highlighting all unused and unnecessary code. I think these rules will always report as much unused and unnecessary code as is technically correct.
If a dev or a team firmly believes some code should remain, however unused, they can disable the rules or suppress them by various means. If disabling "unused_element" across a codebase is too big a hammer, we may split a diagnostic out, as per https://github.com/dart-lang/sdk/issues/48401, for unused parameters, as this argument has come up a few times, "but I might need it later."
Clearly, this behavior is controversial. The reactions speak for themselves I think. There's a decent amount of upvotes on both sides of the argument.
That's the issue.
This feature is controversial, yet it got added to one of the most used lints. As such, disabling the lint globally is unreasonable. Adding // ignore
for all cases is unreasonable too.
This ends up negatively impacting a large number of people with no real solution.
Extracting this behavior into a new lint rule would lead to a happy ending for everyone. Those who like this can keep it. Those who don't can disable it.
In https://github.com/flutter/tests/pull/172, I believe this is the cause of dart fix
removing a parameter that never gets set, which results in compilation errors since the program is depending on the parameter to initialize a default value fo ra final variable.
Any updates?
The IntelliJ IDEA plugin generates a widget with super.key
for extracted widgets (Cmd + Ctrl + W), which I need to manually adjust each time now to Key? key
just to bypass the lint.
I'd love to have either a separate lint that ignores this specific case, as mentioned above, or at the very least have an option for the IDEA plugin to generate Key? key
in the widget constructors.
No updates.
I'd love to have either a separate lint that ignores this specific case, as mentioned above
That's probably the direction we'll go.
Oops, I think we implemented that. You can now // ignore_for_file: unused_element_parameter
or ignore unused_element_parameter
in your analysis_options.yaml
, and you're good to go... I don't think there is anything else to do here.
@dnfield the dart fix
issue would be a separate issue.
@srawlins Great, unused_element_parameter
is exactly what I'm looking for! Could you please show how I can use it in analysis_options.yaml
to ignore this for the entire project? I can't seem to figure out the syntax :)
No worries, I always forget it too :)
Here's the syntax: https://dart.dev/guides/language/analysis-options#ignoring-rules
@srawlins Strangely, I am getting this warning 'unused_element_parameter' isn't a recognized error code. dart(unrecognized_error_code)
:
analyzer:
errors:
unused_element_parameter: ignore
Ah ok if that doesn't work then there is remaining work. I have an idea.
Any news?
No news.
Had to revert the fix; broke various flutter things. See https://github.com/flutter/flutter/issues/131096
@srawlins Strangely, I am getting this warning
'unused_element_parameter' isn't a recognized error code. dart(unrecognized_error_code)
:analyzer: errors: unused_element_parameter: ignore
Works to me with:
analyzer:
errors:
unused_element: ignore
Don't worry, I'm just a reminder: we still need a solution to this problem
@srawlins Strangely, I am getting this warning
'unused_element_parameter' isn't a recognized error code. dart(unrecognized_error_code)
:analyzer: errors: unused_element_parameter: ignore
Works to me with:
analyzer: errors: unused_element: ignore
This worked for me on flutter version 3.19.4
Any news?
The splitting CL is reverted; re-opening.
3.6.0-149.0.dev includes the fix, in case someone wants to try it. However, it's still reverted on main
so the next dev release will likely not contain the fix anymore.
@iinozemtsev this is still reverted on main, right? re-open?
oh, I didn't expect that pushing into a fork can close the issue, sorry!
Oh, I see, haha! Thanks much!
Assumptions:
user_super_parameters
lint rule is enabledunused_element
analyzer rule is enabledThis code chunk produces an analyzer issue:
"A value for optional parameter 'key' isn't ever given. Try removing the unused parameter."
But, when the same widget is not private, there is no issue:
I would like to keep the
super.key
on the private widgets, but I also want to keep theunused_element
rule enabled. Is there any way to achieve this?