-
Notifications
You must be signed in to change notification settings - Fork 192
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
chore: make environment adaptor globally available #855
Conversation
- eliminates the need for the envAdaptor context - Paves the way for envAdaptor usage in sagas
APIX Tests0 files - 1 0 suites - 80 0s ⏱️ - 2m 28s Results for commit 6a1973d. ± Comparison against base commit 474ee93. This pull request removes 320 tests.
|
ensures registration happens after mounting, during the initialization phase, and not on every rerender
registerEnvAdaptor(envAdaptor) | ||
setInitializing(false) | ||
|
||
return () => unregisterEnvAdaptor() |
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 think this is only needed in the dev portal because in the standalone mode unmounting means a reload happened. May also be applicable in extensions. In any case, better to have it than not to. @bryans99
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.
Better to have in my opinion if only to future proof
registerEnvAdaptor(envAdaptor) | ||
setInitializing(false) | ||
|
||
return () => unregisterEnvAdaptor() |
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.
Better to have in my opinion if only to future proof
@@ -71,10 +72,10 @@ const ApiExplorer: FC<ApiExplorerProps> = ({ | |||
declarationsLodeUrl = `${apixFilesHost}/declarationsIndex.json`, | |||
headless = false, | |||
}) => { | |||
const [initializing, setInitializing] = useState(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.
Ideally this should be the redux.
I would expect an initializeExplorer action (perhaps loadExplorer instead), Consider sending the env as the property of the action (okay cos not storing in the reducer) and have a saga call the register. Have an unloadExplorer called when the component is unloaded.
The initialize/loadExplorer action gives us an opportunity to load the versions and initial spec as well.
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 point. The PR following this addresses this.
packages/api-explorer/src/components/DocMarkdown/DocMarkdown.tsx
Outdated
Show resolved
Hide resolved
packages/api-explorer/src/components/SelectorContainer/SdkLanguageSelector.tsx
Outdated
Show resolved
Hide resolved
Is Bryn's feedback going to be address in a different PR, or will this PR be updated for it? |
I addressed and resolved all comments already except for 1 which is part of a follow up PR. |
The "initialization" status will be part of the next PR. All other feedback has been addressed.
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.
Looks good for this 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.
LGTM aside from comment around Loader. That can be fixed in the future
> | ||
<ErrorBoundary logError={envAdaptor.logError.bind(envAdaptor)}> | ||
<EnvAdaptorContext.Provider value={{ envAdaptor }}> | ||
{initializing ? ( |
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.
Sorry to jerk you around but I just realized that Loader instantiates its own version of component provider. What you had before was okay.
Having said that, I think there is opportunity to eliminate the need for ComponentsProvider in Loader at some point in the future so leave this as is.
Once redux in place, I think we can eliminate the need for the Loader in the StandaloneApiExplorer and ExtensionApiExplorer and push the logic down to here.
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 looking Bryn. I agree, let's leave the change in. I'll eliminate the use of Loader
from the standalone and extension top level components once it's possible.
This eliminates the need for the envAdaptor context and paves the way for envAdaptor usage in sagas