-
Notifications
You must be signed in to change notification settings - Fork 230
feat(preferences): add app settings for new proxy options COMPASS-8141 #6099
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
Conversation
@@ -22,7 +28,7 @@ describe('PersistentStorage', function () { | |||
}); | |||
|
|||
afterEach(async function () { | |||
await fs.rmdir(tmpDir, { recursive: true }); | |||
await fs.rm(tmpDir, { recursive: true, force: true }); |
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.
Drive-by: This fixes a deprecation warning
); | ||
}, | ||
}, | ||
}, |
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.
This is one of the main two things that I'd like feedback on – how do we feel about this approach to separating secrets from non-secrets in preferences? This is unfortunately not something I considered a lot in the tech design, and I did try another approach first (splitting these into separate preference entries and doing the encryption/decryption in the code that accesses these), but so far it's something I think works pretty well
return async (dispatch) => { | ||
dispatch({ type: ActionTypes.OpenSettingsModal }); | ||
dispatch({ type: ActionTypes.OpenSettingsModal, tab }); |
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.
... and this the other thing, I guess, although I don't know much about what potential alternatives would look like – this is moving the "open tab" state to redux from the React component, and this will enable us to open a specific tab in the modal from other parts of Compass (which is planned for the next PR)
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.
Yeah, that's definitely the way to go about it. We can also now change the welcome modal to link directly to privacy tab if we want to
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.
Oh, yeah, that makes a ton of sense 🙂 Done in 20a2084!
@@ -472,7 +472,8 @@ async function getCompassExecutionParameters(): Promise<{ | |||
); | |||
const binary = testPackagedApp | |||
? getCompassBinPath(await getCompassBuildMetadata()) | |||
: require('electron'); | |||
: // eslint-disable-next-line @typescript-eslint/no-var-requires | |||
(require('electron') as unknown as string); |
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.
Really unsure why this started popping up as an issue for me tbh – feels like it should always have been complaining about this
@@ -245,7 +245,7 @@ describe('Automatically connecting from the command line', function () { | |||
await browser.waitForConnectionResult('success'); | |||
await browser.execute(() => { | |||
// eslint-disable-next-line @typescript-eslint/no-var-requires | |||
require('electron').ipcRenderer.call('test:show-connect-window'); | |||
require('electron').ipcRenderer.invoke('test:show-connect-window'); |
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.
Similarly here, this is unrelated but was required for me to be able to run e2e tests at all changed this to use as any
to ignore a TS error that started showing up for some reason
}; | ||
case ActionTypes.CloseSettingsModal: | ||
return { | ||
...state, | ||
isModalOpen: false, | ||
tab: undefined, |
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.
Small nit: because of how Settings modal (or rather any modal in leafygreen) works it's usually more preferable to reset modal related state before open and not on close. The reason for this is that the modal is still on the screen, animating away when this state changes, causing slightly weird jumps in UI during the animation. So as a suggestion, instead of resetting it here, do this in the handler for the OpenSettingsModal
action unless there is a value provided in the open action
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.
Thanks for explaining! Absolutely makes sense, done in 2d77051 :)
|
||
export const reducer: Reducer<State> = (state = INITIAL_STATE, action) => { | ||
export const reducer: Reducer<State, Actions> = ( |
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 know it's a pain in the butt, but Redux docs recommend against unions for action type and we generally follow this rule by using isAction helper
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.
Ah, right. I literally forgot that that's what we do in Compass tbh 🙈 Just saw that action
wasn't typed and wanted to fix that, but I'll gladly remove this again and use isAction
instead, will do that in the next commit.
It does make me wonder, should we maybe prefer typing our reducers with Reducer<State, Action>
(instead of the implied default Reducer<State, AnyAction>
)? That would still make sure that we're not accidentally relying on the any
-ness of the action
parameter we're using
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.
Done in 8236817 👍
}; | ||
case ActionTypes.ChangeFieldValue: | ||
if (state.loadingState !== 'ready') return { ...state }; |
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.
Nit: no need for shallow cloning if state is not changed
if (state.loadingState !== 'ready') return { ...state }; | |
if (state.loadingState !== 'ready') return state; |
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.
Done in 8236817 👍
return async (dispatch) => { | ||
dispatch({ type: ActionTypes.OpenSettingsModal }); | ||
dispatch({ type: ActionTypes.OpenSettingsModal, tab }); |
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.
Yeah, that's definitely the way to go about it. We can also now change the welcome modal to link directly to privacy tab if we want to
): SettingsThunkAction<void, SelectTabAction> => { | ||
return (dispatch) => { | ||
dispatch({ type: ActionTypes.SelectTab, tab }); | ||
}; | ||
}; |
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.
Small nit: doesn't need to be a thunk action. Nothing wrong with it, just you usually might want to use those only if you need to dispatch multiple events from one action, access current state before dispatching, or have access to the thunk "extra arg". None of these are the case here
): SettingsThunkAction<void, SelectTabAction> => { | |
return (dispatch) => { | |
dispatch({ type: ActionTypes.SelectTab, tab }); | |
}; | |
}; | |
): SelectTabAction => { | |
return { type: ActionTypes.SelectTab, tab } | |
}; |
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.
Sure – done in b3a9e6f 👍
"extends": "@mongodb-js/tsconfig-devtools/tsconfig.common.json", | ||
"compilerOptions": { | ||
"moduleResolution": "node16" | ||
} |
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.
... so that the '@mongodb-js/devtools-proxy-support/proxy-options'
import works (which in turn also causes the small change to the mongodb-explain-compat
package.json).
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.
Woah, last time I tried to turn it on, a bunch of other things broke, which are maybe gone now? This means that we can also remove weird workarounds for /provider
re-exports everywhere, awesome!
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.
Ah, shoot, just saw the last commit 😬
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.
Fwiw, npm run bootstrap
passed just fine – but this failed during the e2e test phase. Probably not hard to fix if we want to, though
This isn't hooked up to any actual proxy logic yet, to be clear 🙂