Skip to content
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

FED-1889 Null Safety: Audit public utility components #855

Merged
merged 18 commits into from
Dec 1, 2023

Conversation

aaronlademann-wf
Copy link
Contributor

  • Prop nullability, upgrade props/state to late for public components, update class component prop defaulting
    • ErrorBoundary
    • ResizeSensor
    • AbstractTransition
    • WithTransition
    • FluxUiComponent
    • ConnectFluxPropsMixin
    • ReduxProviderPropsMixin
    • ReduxMultiProvider (storesByContext)

Since they are internal implementation details that are never set to null.
No reason for these local vars that are initialized immediately to be nullable / typed on the left side.
I’m not actually sure this would cause a problem, but it seemed like an awkward way to set the default IMO.
#boyscoutin
Since it is an internal implementation detail that is never set to null.

This also required that the `initiallyShown` abstract getter become non-nullable.
Since it is an internal implementation detail that is never set to null.
Same with the actions params that get passed around `connectFlux` utils
@aviary-wf
Copy link

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.

Copy link
Contributor

@greglittlefield-wf greglittlefield-wf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just two small comments, one of em a question. This looks great!

/// There is no strict rule on the [ActionsT] type. Depending on application
/// structure, there may be [Action]s available directly on this object, or
/// this object may represent a hierarchy of actions.
@override
ActionsT? actions;
late ActionsT actions;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm thinking it a little more, making actions required might be a little tricky.

While it'll be present in most cases, there are usages that only wire up a component to redraw on the store, because the actions aren't used. Internally, it looks like ~5% of flux component usages had a store with no actions.

So our options are either:

  • Make it optional
  • Make it required, and plan on migrating consumers to also set ..actions = (either to an actions class that will be unused, or to set ..actions = null and potentially update the TActions generic of the consuming component to be with FluxUiPropsMixin<MyStore, Null>)

5% isn't a lot, so I'm leaning toward making it required, but it'll be a little bit of a pain to update those usages.

Thoughts?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like making it required.

@@ -68,7 +67,7 @@ class ReduxMultiProviderComponent
get propTypes => {
keyForProp((p) => p.storesByContext): (props, info) {
final storesByContext = props.storesByContext;
if (storesByContext != null && storesByContext.isEmpty) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like there's a failing test:

❌ [Chrome, Dart2Js] test/over_react_redux_test.dart: ReduxMultiProvider works as expected when storesByContext is null (failed)
  Expected: emits the propType warning some element contains 'RequiredPropError: Prop ReduxMultiProviderProps.storesByContext is required.'
    Actual: <Closure: () => TestJacket<Component> from: () => {
                        let t9;
                        return jacket$.mount(react.Component, redux_multi_provider.ReduxMultiProvider().call((t9 = dom_components.Dom.div(), (() => {
                          t9.addTestId("content");
                          return t9;
                        })()).call("foo")));
                      }>
     Which: has propType warning with value [
              'Warning: Failed prop type: Expected a value of type \'Map<Context<dynamic>, Store<dynamic>>\', but got one of type \'Null\''
            ]

That test should probably just be removed, since when we add required prop validation it'll fail for that case when invoking the builder.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed the test in 136eb83

…-safety_public-util-components

# Conflicts:
#	lib/src/component/resize_sensor.dart
#	test/over_react_redux/fixtures/connect_flux_counter.dart
#	test/over_react_redux/fixtures/flux_counter.dart
@aaronlademann-wf aaronlademann-wf changed the base branch from null-safety to v5_wip December 1, 2023 17:51
@aaronlademann-wf aaronlademann-wf changed the title Null Safety: Audit public utility components FED-1889 Null Safety: Audit public utility components Dec 1, 2023
@greglittlefield-wf greglittlefield-wf marked this pull request as ready for review December 1, 2023 18:13
Copy link
Contributor

@greglittlefield-wf greglittlefield-wf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes look good, +10 assuming CI passes

@greglittlefield-wf greglittlefield-wf merged commit 5efd453 into v5_wip Dec 1, 2023
7 of 10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants