Add Action0 and Action1 that will be able to be made null-safe

[evanweible-wf]

No description provided.

[aviary-wf]

Security Insights

No security relevant content was detected by automated scans.

Action Items

• Review PR for security impact; comment "security review required" if needed or unsure
• Verify aviary.yaml coverage of security relevant code

---

Questions or Comments? Reach out on Slack: #support-infosec.

[evanweible-wf]

My thought is that we'd either:

• keep this type around as a common base type, but could change it to an interface
• use Action1 as the common base type where needed

[sorenthompson-wk]

should this be 'Action0'

[greglittlefield-wf]

Just one comment and question, otherwise the approach generally looks good to me, and I can't think of any issues or potential issues that aren't also present in the other approach (Action/Action2).

[greglittlefield-wf]

We may want to consider making this extends Action<Null> instead, to help prevent consumers from accidentally passing in values without knowing they'll be discarded.

Example: https://dartpad.dev/?id=97af2f0dd8c7919807bd6864ab085794

The relevant pieces from that ^

main() {
  {
    final action = VoidAction0();
    action();     
    action(null);
    action('foo');
    //     ^^^^^
    // No error or other indication that there's a potential issue with 
    // this usage.
    //
    // The value being passed in is discarded, but the consumer may not know that.
  }

  {
    final action = NullAction0();
    action();
    action(null);
    action('foo'); 
    //      ^^^^^
    // Error: The argument type 'String' can't be assigned to the parameter type 'Null'.
  }
}

class VoidAction0 extends Action1<void> {
  @override
  Future call([void payload]) => super.call(null);
}

class NullAction0 extends Action1<Null> {
  @override
  Future call([Null payload]) => super.call(null);
}

[greglittlefield-wf]

Was there a reason this was deprecated and triggerOnAction1 added, other than cleanliness and improved naming consistency? Those seem like good enough reasons, but I was curious if there was some other factor

[evanweible-wf]

Nope that was it

[evanweible-wf]

Talked through this as a team and decided that this still isn't good enough to justify the change/extra work, so we'll stick with #188