quick fix for diagnostic_describe_all_properties

[pq]

Follow-up from: flutter/flutter#41513 (comment).

@jacob314: feel free to chime in w/ any implementation notes here. Any heuristics for code generation would be greatly appreciated!

---

Property subclasses to support

• BooleanProperty -- bool (23aca57)
• ColorProperty -- for Color (0a63bd4)
• EnumProperty -- for any enum class (512d763)
• IntProperty -- int (512d763)
• DoubleProperty -- double (512d763)
• IterableProperty -- any iterable (0a63bd4)
• StringProperty -- string (512d763)
• TransformProperty -- Matrix4 (0a63bd4)
• DiagnosticsProperty for any T that doesn't match one of the other cases (69b612b)

[bwilkerson]

@goderbauer Could you send us a couple of before/after pairs? That would likely be very helpful for informing what the fix should do.

[jacob314]

I can provide all the before and after pairs.
https://api.flutter.dev/flutter/foundation/DiagnosticsProperty-class.html
gives a list of all subclasses.
ColorProperty -- for Color
EnumProperty -- for any enum class
IntProperty -- int
DoubleProperty -- double
IterableProperty -- any iterable
StringProperty -- string
TransformProperty -- Matrix4
DiagnosticsProperty for any T that doesn't match one of the other cases.

For each case the quick fix is to either add a line at the end of the existing debugFillProperties method or to override the debugFillProperties method and then add the property.
For example, for an int property you would add the line
properties.add(IntProperty('myPropertyName', myPropertyName));
method or add a new one. The big time savings for the quick fix is otherwise we were finding it was a real pain to for every single property navigate to the debugFillProperties method to add the property. Sometimes it wasn't obvious where the method was and almost all of these migrations are mechanical.

[bwilkerson]

That should be fairly easy to automate. Given the amount of work there is it sounds like we should also consider enabling that via dartfix, which could apply the fix in bulk.

[jacob314]

There would still be a bit of manual work to make sure the properties have the right default values and determine whether each property shouldn't be added or not so lets hold up on dartfix integration.

…

On Sat, Sep 28, 2019 at 9:35 PM Brian Wilkerson ***@***.***> wrote: That should be fairly easy to automate. Given the amount of work there is it sounds like we should also consider enabling that via dartfix, which could apply the fix in bulk. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#38633?email_source=notifications&email_token=AAJLQPG72DULJTHGEATY3L3QMAWCBA5CNFSM4I3OJ24KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD73H6ZQ#issuecomment-536248166>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJLQPBXVM2KNZZRA6P2OBLQMAWCBANCNFSM4I3OJ24A> .

[bwilkerson]

How do you manually determine the default value for a property? Is it possible to statically determine the right default value for a property? Maybe by looking at the field's initializer and/or the constructors?

How do you manually determine which properties to add? I would have assumed that the lint was able to do this in order to not produce false positives. If that's not the case then we should at least be able to add an 'ignore' comment for properties that shouldn't be added. If you do that, then those diagnostics will be suppressed and given that fixes are only applied where a diagnostic is reported, we should still be able to use dartfix after marking the properties that shouldn't be added.

[pq]

Video demonstrating the simple/common case...

🤘

/cc @jacob314

[pq]

For reference: dart-lang/linter#1420.