frontend: move web config access into config context/provider#3916
frontend: move web config access into config context/provider#3916smokyisthatyou wants to merge 24 commits into
Conversation
|
nice, please make one more change/commit. Currently each component still does a get request when using getConfig. Instead it could call getConfig once on startup and keep the "config" object in the context. getConfig could then either read out the local "config" object, or context could expose "config" object along with setConfig. I am not sure what is better. With this all components that depend on "config" object can read from the context without doing an additional api call. We want the source of truth still to be the backend, so in the context it should update the "config" object after setConfig and fetch from the api. Also the api function in utils should be moved into frontends/web/src/api/config.ts |
|
concept ACK |
|
|
||
| if (cancelledAccounts?.includes(code)) { | ||
| alertUser(t('account.insuranceExpired')); | ||
| // remove the pending notification from the frontend settings. |
There was a problem hiding this comment.
please keep the comment
30401e1 to
ea60d60
Compare
ea60d60 to
4da6264
Compare
|
@thisconnect moving this from draft, rebased |
|
@thisconnect ptal whenever you have time 🙏 |
e991fa0 to
8fb8728
Compare
ed28dd9 to
925a212
Compare
|
@jadzeidan while working on this pr i think i introduced an old behaviour of the app that was opening the guide on first run. i implemented the code thinking it was the current expected flow, but @thisconnect pointed out this was actually deprecated in v4.40. personally i’m not a huge fan of the auto-opening guide for aesthetic reasons, though I can see the utility. |
|
thanks @smokyisthatyou for finding this 😄 I agree that guide shouldn't open automatically, so let's keep the "new" behaviour. |
d730016 to
cacf20f
Compare
cacf20f to
bd2bd6c
Compare
|
@thisconnect rebased |
📝 WalkthroughWalkthroughThis PR refactors the application's configuration management from a utility-based pattern to a React context-based system. A new typed API module ( ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
491ab75 to
0feada1
Compare
- Introduce ConfigProvider and ConfigContext and wrap app with provider - Fetch config once when the app loads and expose config + setConfig via useConfig - Refactor config consumers to read from context instead of calling getConfig per component
Stop auto-opening the guide when no frontend config is present. This prevents the guide overlay from blocking interactions on fresh starts.
- Add TFrontendConfig with known frontend settings flags and keep index signature - Update consumers to use typed config.frontend keys and drop casts/guards
- Add TBackendConfig and related types to api/config and use them in TConfig - Introduce TConfigUpdate so setConfig can accept partial backend/frontend updates - Update utils/config and ConfigProvider/Context to use TConfigUpdate merge + pendingConfig - Drop remaining backend casts in offline-error, electrum-servers, and RatesProvider
Type known frontend/backend config keys in api/config, remove duplicate advanced-settings types and unsafe casts, tighten TConfigUpdate and normalization, and add mockConfig for unit tests.
this avoids calling getConfig/setConfig directly and redundant config fetches
Drop the onChangeConfig callback chain; children already update config via useConfig().
- Simplify darkmode unset spread in DarkmodeProvider - Remove redundant userLanguage cast in i18n detector after truthiness guard. - Align feetargets expertFee access with context nullability (direct frontend read in effect, optional config in render). - Simplify remember-wallet dialog config check to optional chaining.
0feada1 to
1e34610
Compare
type getConfig with required top-level keys; guard only undefined config (and nested fields like proxy) instead of optional frontend/backend objects.
thisconnect
left a comment
There was a problem hiding this comment.
very nice almost there
swap.tsx was recently merged, please also useConfig there instead of useLoad(getConfig)
| }; | ||
| let pendingConfig: TConfigUpdate = {}; | ||
|
|
||
| export const emptyBackendConfig = (): TConfig['backend'] => ({} as TConfig['backend']); |
There was a problem hiding this comment.
We trust the backend returns what is defined in api files.
| }; | ||
|
|
||
| export const EnableAuthSetting = ({ backendConfig, onChangeConfig }: TProps) => { | ||
| export const EnableAuthSetting = ({ backendConfig }: TProps) => { |
There was a problem hiding this comment.
nit: use config?.backend from useConfig(); a few lines below and drop passing config with backendConfig prop.
| const dismissGuideIfPresent = async (driver) => { | ||
| await driver.execute(() => { | ||
| const overlays = document.querySelectorAll('div'); | ||
| for (const el of overlays) { |
There was a problem hiding this comment.
Please use data-testid on the dialog component's overlay so you dont have to traverse the DOM here.
The react testing library style would more be to find web accessible elements by role atc. https://testing-library.com/docs/queries/about/#priority
but refactoring the diaog/overlay seems a bit out of scope of this PR so best to just add data-testid in this dialog.
| }, | ||
| }); | ||
| } else { | ||
| // darkmode is different from OS, save to config |
There was a problem hiding this comment.
please keep the comment
| if (config.frontend.selectedExchangeRegion) { | ||
| // pre-select config region | ||
| setSelectedRegion(config.frontend.selectedExchangeRegion); | ||
| setSelectedRegion(String(config.frontend.selectedExchangeRegion)); |
There was a problem hiding this comment.
| setSelectedRegion(String(config.frontend.selectedExchangeRegion)); | |
| setSelectedRegion(config.frontend.selectedExchangeRegion); |
| } | ||
| }; | ||
| useEffect(() => { | ||
| updateRatesConfig(); |
There was a problem hiding this comment.
updateRatesConfig function is only used here, also the function returns a promise but that is not needed here. I think it is fine to just move the 5 lines logic of the function into the effect here.
| <EnableAuthSetting /> | ||
| <EnableTorProxySetting proxyConfig={config?.backend.proxy} /> | ||
| <RestartInTestnetSetting /> | ||
| <CustomGapLimitSettings /> |
There was a problem hiding this comment.
It would be nice to get rid of the remaining props where config is passed (frontendConfig and proxyConfig)
| const nextConfig = Object.assign(currentConfig, { | ||
| backend: Object.assign({}, currentConfig.backend, pendingConfig.backend, object.backend), | ||
| frontend: Object.assign({}, currentConfig.frontend, pendingConfig.frontend, object.frontend) | ||
| }); |
There was a problem hiding this comment.
I dont understand why there is different behavior for merging frontend and backend. Or if you found a bug and this fixes something.
As this PR is already vvery big I'd prefer to keep the merging with Object.assign and you drop the new commit that add mergeBackend/mergeFrontend.
Add ConfigContext + ConfigProvider in frontends/web and refactor React components/hooks to consume getConfig/setConfig through useConfig() instead of importing utils/config directly. Keep non-React config consumers on the shared utils/config implementation path, and update related hook dependency arrays.
Before asking for reviews, here is a check list of the most common things you might need to consider:
cc @thisconnect