After review, it turns out that MMIController does not have any state and therefore should not inherit from BaseController (or anything, for that matter).
Scenario
No response
Design
No response
Technical Details
No response
Threat Modeling Framework
No response
Acceptance Criteria
A constant called name exists which holds the namespace for actions and events.
MMIController does not inherit from a superclass (it does not have state, so it is not a controller).
super() is removed from the constructor.
MMIController uses this.messagingSystem to refer to the messenger instead of this.messenger for consistency with controllers.
MMIController no longer takes metaMetricsController as a constructor option.
It no longer reads the state directly from this controller, but uses the MetaMetricsController:getState action through the messenger to do so instead.
MMIController no longer takes networkController as a constructor option.
It no longer reads the state directly from this controller, but uses the NetworkController:getState action through the messenger to do so instead.
It no longer calls setActiveNetwork directly on the controller, but calls the NetworkController:setActiveNetwork messenger action instead.
It no longer calls setProviderType on the controller — this method is deprecated — but calls the NetworkController:setActiveNetwork messenger action instead.
❌ MMIController still takes mmiConfigurationController, keyringController, preferencesController, appStateController, transactionUpdateController, custodyController, permissionController, and signatureController as well as getState, getPendingNonce, updateTransactionHash, setChannelId, and setConnectionRequest. In theory we should use the messenger for these, but we'd need to add actions to the corresponding controllers to support this, and this would be too much work.
Supporting types exist.
The MMIControllerActions and MMIControllerEvents types exist.
The AllowedActions and AllowedEvents types exist.
The MMIControllerMessenger type exists and expects AccountsController:getAccountByAddress, AccountsController:setAccountName, AccountsController:listAccounts, AccountsController:getSelectedAccount, and AccountsController:setSelectedAccount.
The type of the messagingSystem property is corrected from any.
The tests are updated to follow suit.
❌ The use of beforeEach is not corrected, as this would take too long. We can solve this in another PR.
❌ MMIController is not renamed, as it would mess with the diff too much. We can do this in a different PR.
Stakeholder review needed before the work gets merged
[X] Engineering (needed in most cases)
[ ] Design
[ ] Product
[ ] QA (automation tests are required to pass before merging PRs but not all changes are covered by automation tests - please review if QA is needed beyond automation tests)
What is this about?
Following the Wallet Framework team's OKRs for Q3 2024, we want to bring
MMIController
up to date with our latest controller patterns.After review, it turns out that
MMIController
does not have any state and therefore should not inherit fromBaseController
(or anything, for that matter).Scenario
No response
Design
No response
Technical Details
No response
Threat Modeling Framework
No response
Acceptance Criteria
name
exists which holds the namespace for actions and events.MMIController
does not inherit from a superclass (it does not have state, so it is not a controller).super()
is removed from the constructor.MMIController
usesthis.messagingSystem
to refer to the messenger instead ofthis.messenger
for consistency with controllers.MMIController
no longer takesmetaMetricsController
as a constructor option.MetaMetricsController:getState
action through the messenger to do so instead.MMIController
no longer takesnetworkController
as a constructor option.NetworkController:getState
action through the messenger to do so instead.setActiveNetwork
directly on the controller, but calls theNetworkController:setActiveNetwork
messenger action instead.setProviderType
on the controller — this method is deprecated — but calls theNetworkController:setActiveNetwork
messenger action instead.MMIController
still takesmmiConfigurationController
,keyringController
,preferencesController
,appStateController
,transactionUpdateController
,custodyController
,permissionController
, andsignatureController
as well asgetState
,getPendingNonce
,updateTransactionHash
,setChannelId
, andsetConnectionRequest
. In theory we should use the messenger for these, but we'd need to add actions to the corresponding controllers to support this, and this would be too much work.MMIControllerActions
andMMIControllerEvents
types exist.AllowedActions
andAllowedEvents
types exist.MMIControllerMessenger
type exists and expectsAccountsController:getAccountByAddress
,AccountsController:setAccountName
,AccountsController:listAccounts
,AccountsController:getSelectedAccount
, andAccountsController:setSelectedAccount
.messagingSystem
property is corrected fromany
.beforeEach
is not corrected, as this would take too long. We can solve this in another PR.MMIController
is not renamed, as it would mess with the diff too much. We can do this in a different PR.Stakeholder review needed before the work gets merged
References