The KeyringController currently depends upon four methods from the PreferencesController being passed in as constructor arguments. These methods are called to synchronize state, and to update preferences in response to certain keyring actions.
Essentially those operations don't belong in the KeyringController. It's not responsible for the PreferencesController state, the PreferencesController is. Conventionally a controller manages its own state, and that's it. The conventional approach here would be to update the PreferencesController to listen for relevant keyring related events, and react to them as appropriate internally. This keeps responsibilities clearly delineated between each controller. Event-based syncing is also safer than active syncing, in that we don't have to be concerned about forgetting to sync when we need to.
The
KeyringControllercurrently depends upon four methods from thePreferencesControllerbeing passed in as constructor arguments. These methods are called to synchronize state, and to update preferences in response to certain keyring actions.Essentially those operations don't belong in the
KeyringController. It's not responsible for thePreferencesControllerstate, thePreferencesControlleris. Conventionally a controller manages its own state, and that's it. The conventional approach here would be to update thePreferencesControllerto listen for relevant keyring related events, and react to them as appropriate internally. This keeps responsibilities clearly delineated between each controller. Event-based syncing is also safer than active syncing, in that we don't have to be concerned about forgetting to sync when we need to.