-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
feat: implement remote feature flag controller #12427
base: main
Are you sure you want to change the base?
Changes from all commits
00a3bd1
b4f9cc8
cdd4a58
1787680
5299891
6204914
6f8d208
608f05b
a8ec092
01df041
c8c2af0
ca33006
27b32a3
d7aed0d
b80145d
9a67929
934a13a
faa6cb0
20c3b42
d22d1cb
ba1802e
5e97075
c838b21
426655e
ebc940e
8014b45
9a35568
8c305c1
c8495e5
d7d384c
b784e89
38292f7
7661b90
f5b754f
7bdcc81
e54d05d
b4fb866
f20e31a
6f709eb
82e2c88
54424a6
96ca13b
b5d9a6a
e12bfb6
50795f0
0126119
674962d
d451f5c
5cfbd03
9cd1bf0
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To keep things consistent, let's follow the pattern that resembles that of what is currently in There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In this case, it's debatable whether or not we should just put all of the functions in index or utils file. IMO, creating the utils file and re-exporting via index allows us to be more flexible in the future, where index can export other things such as constants, etc. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. addressed on f5b754f There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nit: Maybe better to name this directory There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm concerned about the potential tech debt we add when the team's name-based namings enter the codebase. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Well, we could think of it as "feature areas" instead perhaps, which roughly correlate to teams but are more long-lasting. The purpose (as I understood it) of moving controller-related code to dedicated files was that it allowed us to assign more appropriate code owners (i.e. teams) and reduce code review burden and regression risk that comes from modifying core modules like But the problem is that there are very few changes that affect just a controller. If we co-located multiple controllers owned by the same team, it would be more effective in minimizing cross-team impact/reviews for changes to how controllers interact with each other. If each controller is separate, then their interactions would be via Single-controller directories don't seem helpful to me in reducing review burden or regression risk. (Note: still not a blocker for me, just explaining my reasoning) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I recognize the benefits of organizing the codebase in a feature-based structure. It helps with ownership and better outlines the relationship between components. Namings that carry meaning for the codebase / product are long-lasting and do not need to be revisited if there's any maintainer's restructuring. Responsibility areas can then be attributed to each team. I'll leave it as is for now and follow up with an update when there's a decision on feature area names. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,2 @@ | ||
export { createRemoteFeatureFlagController } from './utils'; | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,8 @@ | ||
import { RemoteFeatureFlagControllerMessenger, RemoteFeatureFlagControllerState } from '@metamask/remote-feature-flag-controller'; | ||
|
||
export interface RemoteFeatureFlagInitParamTypes { | ||
state?: RemoteFeatureFlagControllerState; | ||
messenger: RemoteFeatureFlagControllerMessenger, | ||
disabled: boolean | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Q: not sure if this change makes the mock in the test obsolete and how this test doesn't need any changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch, the tests for this hook need to be updated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm surprised the test is passing given the changes in the hook... so maybe rewrite the test in a more robust way. A change like this should make it fail otherwise it probably means it's not testing anything but the mocks...