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
Stateless Widget template has warnings #3347
Comments
Thanks! I think the fix here is to add the following to both const $1({Key? key}) : super(key: key); This resolves the issue in a newly-created project. However, in an existing project that is not opted into null-safety, this will result in errors on the To fix this properly, I think the snippets should come from the server (dart-lang/sdk#37831) where it can tell whether null-safety is enabled. I think in the meantime the current lint warning may be better than producing hard errors for some users, though I'm interested in others thoughts (@eseidel @devoncarew). |
@bwilkerson I'm thinking about how to move these to the server without breaking anything (or causing duplicates). I think a possible plan would be first to ship some change sin Dart-Code:
Once that has rolled out, the server can be updated so that if the client capabilities say server-snippets are supported:
In the future, once we're sure the original Dart-Code changes have reached enough users, we could remove the client capability or change the default so that LSP clients do not need to explicitly opt-in to it with a custom flag (beyond advertising support for the snippet syntax). In the server we'd have two advantages over having them in the client:
I'm not sure how non-LSP clients could safely enable the snippets without something additional in the protocol (or sniffing the client version) though. If enabled for clients that don't know about them, there could end up being dupes. |
FYI @goderbauer, I believe these come from the new flutter_lints package included in the create template. (Not good or bad, just connecting folks.) |
Does the IntelliJ plugin able to do this? Or it still needs some improvements? |
Based on the changes at flutter/flutter-intellij#5405, I think IntelliJ probably has a similar dilemma. The merged templates do not include a |
Yes currently it does have that issue. So it would be great if the plugin can have the same ability to detect NNBD. |
Sorry for the delay, I somehow missed the email when you first referenced me. I'm absolutely in favor of moving this functionality into the server. However, I'm not convinced that code completion is the right place to surface this. If VS Code doesn't have any other way of providing this functionality then I suppose that's probably how we'll need to handle it for LSP clients, but I think that IntelliJ will need a separate API. (If that's all true then we can worry about IntelliJ separately.) What about other LSP clients? Do we want to be able to enable this in other clients? In order to do so would we need to make it unconditional (I assume that many other clients won't be able to use a custom protocol. If that's the case, then perhaps we should use the server's version (or a custom capability flag) to signal that these snippets will be provided and not require the client to send a "supports server-provided snippets" capability. I'm also not sure at this point whether/how to provide this in Cider. Perhaps the next step would be to create an issue in the sdk repo to make it easier to involve other interested parties. |
Since NNDB is the future and this transition period is temporary, should we consider moving all these things to use nndb by default and maybe only then (separately?) consider if they should be configurable (via server or otherwise) to non-nndb? I'm not sure what the % of projects with null-safety enabled is (or even if we have that stat). |
While we don't have a way to configure it, I would also be in favor of generating null-safe code. It is what we recommend for new projects and we also want to nudge people to migrate their existing projects. |
It is currently the only way - snippets are included through the completion APIs (there is a specific completion kind for them). If that doesn't seem best for IntelliJ, having it separate in the server and combining them for LSP in its completion handler sounds reasonable to me.
Yep, my plan was to invert the default soon after shipping a Dart-Code that uses the flag - although as long as the server provides a flag back to the client saying when it will include them, we can probably default to opt-out right away as long as we ship a Dart-Code that can read that flag first (and allow a little time to assume the significant majority are updated). I'm less keen on using versions though - it's different to how other LSP things work and may make it harder for other clients to control this if they wanted. Perhaps a user setting would actually work better - that way the user can toggle it themselves and we can default to on if not supplied. That avoids polluting capabilities and also allows changing it without restarting the editor.
Makes sense, will do! In the meantime, I think I agree with @eseidel and @goderbauer that updating to the null-safe versions shipped in the editor probably makes sense. It'll cause errors for people that aren't migrated, but I think it's clear why and the fix is relatively easy. Even if the analyzer gained support today, it would be a while before it reached the stable releases. I'm still keen to move to the server though - one of my biggest complaints is that in VS Code we don't have enough context to provide them based on the location, so they show up in bad places (and given we have snippets with names like |
There was an existing SDK issue about this, so I added some notes and references back here -> dart-lang/sdk#37831 |
I don't see support for user settings in LSP, so I assume that this approach would require changes in every client. I'd rather have the support be provided via code completion by default than to make it hard for other clients to provide this support. |
@bwilkerson sorry, it's called configuration in LSP not settings: It's not guaranteed that all clients support it, but I suspect it's very common. It's already being used it for a few things: |
To clarify - I agree it should be provided by code completion and (at least ultimately) defaulted to on for LSP. It should not require any work in the LSP clients, they should just get it for free by implementing the standard LSP messages. But to avoid disruption for Dart-Code, there will need to be some way for:
If we want to avoid a capability (in each direction) I think we could use a configuration setting. We could add that to Dart-Code now and set to |
I don't have a preference between those two options; I'm happy to let you decide. |
I'd lean towards the setting - the capability wouldn't make as much sense if/when the default is true (sending a capability to disable something doesn't feel like a capability), and should another editor (or user) decide they did want to disable them, it's more complicated with a custom capability than just a basic user setting. For the original issue here, I've updated the shipped snippets to assume null-safety for the next release. The change adds a |
…ed snippets in future See #3347 (comment).
Describe the bug
A clear and concise description of what the bug is.
If you use the stateless widget template (which I think comes from Dart-Code?) it now ends up with warnings as of the latest Flutter default template?
To Reproduce
flutter create
to start a new empty project.Expected behavior
Should not have any analyzer warnings.
First it gives you a warning about missing "key" parameter in constructor:
"Use key in widget constructors."
Then, once you fix that, then it gives you a new warning:
"Prefer declaring const constructors on
@immutable
classes."Versions (please complete the following information):
The text was updated successfully, but these errors were encountered: