You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some of our classes that were previously labeled as controllers have empty state, making them non-controllers.
As part of Wallet Framework team's Q2 2024 OKRs (O3KR1), we're currently in the process of upgrading these non-controllers to use the messenger pattern without inheriting from BaseController.
As downstream usage of the ComposableController includes passing in these non-controllers as child controllers, we should define a consistent behavior for handling non-controller input.
a) We could simply reject non-controllers both at the type-level and at runtime, or
b) we could accept non-controllers as child controllers but handle them so that the ComposableController instance doesn't subscribe to their non-existent stateChange events (i.e. The following message should not be logged to console for non-controllers: "Error: Event missing from allow list: ExampleController:stateChange"), and
b-1) exclude the non-controllers from the composed state object entirely, or
b-2) include the non-controllers as properties in the composed state object, with empty objects assigned to the names of the non-controllers.
MajorLift
changed the title
[composable-controller] Non-controllers with empty state should be rejected or handled as redundant parameters
[composable-controller] Non-controllers with empty state should be rejected or excluded from composed state
Jun 21, 2024
MajorLift
changed the title
[composable-controller] Non-controllers with empty state should be rejected or excluded from composed state
[composable-controller] Enable handling of input that includes non-controllers with empty state
Nov 14, 2024
Explanation
Some of our classes that were previously labeled as controllers have empty state, making them non-controllers.
As part of Wallet Framework team's Q2 2024 OKRs (O3KR1), we're currently in the process of upgrading these non-controllers to use the messenger pattern without inheriting from
BaseController
.As downstream usage of the
ComposableController
includes passing in these non-controllers as child controllers, we should define a consistent behavior for handling non-controller input.ComposableController
instance doesn't subscribe to their non-existentstateChange
events (i.e. The following message should not be logged to console for non-controllers: "Error: Event missing from allow list: ExampleController:stateChange
"), andProof of concept
ComposableController
fix with no type error suppression metamask-mobile#10374 (comment)ComposableController
fix with no type error suppression metamask-mobile#10374 (comment)The following logic could be moved into the
ComposableController
constructor:References
BaseController
#4432@metamask/composable-controller
from^3.0.0
to^9.1.0
metamask-mobile#10441 (overridden with@ts-expect-error
)The text was updated successfully, but these errors were encountered: