FEDX-414 Add APIs and update deprecations in preparation for 7.0.0 release

[greglittlefield-wf]

Motivation

react-dart 7.0.0 will contains some breaking changes to APIs that are not yet deprecated in the 6.x line.

The 7.0.0 WIP branch also relies some API additions that aren't present in 6.x, so we'll want to backport them to ensure consumers can transition to these new APIs before setting their lower bounds to 7.0.0.

Solution

• Deprecate APIs to be removed in 7.0.0
• Update existing outdated deprecations for APIs that say they'll be removed in 7.0.0, but won't yet be removed
  • These were mostly Component and its associated APIs, which we don't have a timeline for removing
• Backport APIs htmlMain and useRefInit
• Add draft changelog entry for 7.0.0.
  • I had this written up but not committed anywhere, and figured I'd add it now to help provide context during review of this PR. We can refine this entry later as part of the PRs for the 7.0.0 changes.

QA steps

• Verify CI passes

[aviary3-wk]

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.

[aaronlademann-wf]

Couple questions, but I'm +1 here

[aaronlademann-wf]

This is pretty much guaranteed to break Component subclasses where lifecycle methods reference those fields, correct?

[greglittlefield-wf]

They'll be initialized for most lifecycle methods, except for "static" ones like defaultProps, getDerivedStateFromProps, and getDerivedStateFromError where you shouldn't ever reference props/state.

Besides those "static" lifecycle methods, they'll be initialized by the time we get to lifecycle methods.

The sequence during component mount is:

• The Dart component class is instantiated
  • non-late class fields are initialized
  • Default constructor is called
• props are initialized
• getInitialState or initialState is called
• state is initialized
• All non-static lifecycle methods (componentWillMount, componentDidMount, render, etc.) are called

For example:

class FooComponent extends Component2 {
  FooComponent() {
    // props would have always been null here, but in 7.0.0 accessing it throws
    print(props);
  }
  render() => 'foo';
}

class FooComponent extends Component2 {
  // props would have always been null when this is initialized, but in 7.0.0 accessing it throws
  final something = (props ?? {})['something'];
  render() => 'foo';
}

class FooComponent extends Component2 {
  getDerivedStateFromProps(Map nextProps, Map prevState)  {
    // props would have always been null here, but in 7.0.0 accessing it throws
    print(props);
  }
}

Basically, this shouldn't ever happen unless you're doing something wrong. And if you were doing it wrong, you'd probably get a null exception when trying to read off of them. I think I originally had a note to that effect in here, but scrapped it since I couldn't get wording I was happy with. I'll take a stab at re-adding it.

[aaronlademann-wf]

is this removal intentional?

[greglittlefield-wf]

Good catch, nope; I'll re-add it

[aaronlademann-wf]

I'm a little unclear why certain methods are deprecated, and others are not.

[greglittlefield-wf]

I think we deprecated only the ones related to the legacy context, and for the rest deprecating Component itself seemed sufficient.

[aaronlademann-wf]

+1

[aaronlademann-wf]

+1 / +10

• Passing CI

[greglittlefield-wf]

@Workiva/release-management-p

[rmconsole-wf]

+1 from RM