[DAL] Add MRT Data Store Context and Hooks for Template Usage - #3834
Conversation
|
Git2Gus App is installed but the |
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
There was a problem hiding this comment.
Do we want to keep the .md file if so should we move it to the template-retail-react-app/docs/ folder?
There was a problem hiding this comment.
Sorry.. this file wasn't supposed to be included, it was something I was working on for someone else.
| const MrtDataStoreContext = createContext({ | ||
| customSitePreferences: {}, | ||
| customGlobalPreferences: {} | ||
| }) |
There was a problem hiding this comment.
nit: should we keep the exiting pattern of using React.createContext() or updating to consolidate one pattern?
| customSitePreferences: window.__MRT_DATA_STORE__.customSitePreferences || {}, | ||
| customGlobalPreferences: window.__MRT_DATA_STORE__.customGlobalPreferences || {} |
There was a problem hiding this comment.
nit: Should we use the same constants we use in the react-rendering?
pwa-kit/packages/pwa-kit-react-sdk/src/ssr/server/react-rendering.js
Lines 443 to 446 in 04f4023
There was a problem hiding this comment.
Another good catch. Fixed.
| windowGlobals[DATA_STORE_WINDOW_GLOBAL] = { | ||
| [DATA_STORE_BOOTSTRAP_SITE_PREFERENCES_KEY]: customSitePreferences ?? {}, | ||
| [DATA_STORE_BOOTSTRAP_GLOBAL_PREFERENCES_KEY]: customGlobalPreferences ?? {} | ||
| __siteId: siteId, // Include siteId so client can construct keys |
There was a problem hiding this comment.
nit: Should use a constant like DATA_STORE_BOOTSTRAP_SITE_ID_KEY = '__siteId' form constants.js instead of the '__siteId' string directly file and re-use it in these two places?:
|
It looks we no longer need pwa-kit/packages/pwa-kit-runtime/src/utils/data-store/constants.js Lines 20 to 27 in debad80 |
| expect(data[DATA_STORE_WINDOW_GLOBAL]).toEqual({ | ||
| [DATA_STORE_BOOTSTRAP_SITE_PREFERENCES_KEY]: {}, | ||
| [DATA_STORE_BOOTSTRAP_GLOBAL_PREFERENCES_KEY]: {} | ||
| __siteId: undefined, |
There was a problem hiding this comment.
Same comment from @adamraya on this line as well
Replace `__siteId` literal with new `DATA_STORE_BOOTSTRAP_SITE_ID_KEY` constant across the bootstrap writer, client reader, and the rendering test. Remove the now-unused `DATA_STORE_BOOTSTRAP_SITE_PREFERENCES_KEY` / `DATA_STORE_BOOTSTRAP_GLOBAL_PREFERENCES_KEY` exports and their imports in the data-store test files.
`compile-folder.js` and `compile-pseudo.js` were spawning `formatjs` via `exec` and returning before the callback fired. In the generated test project, npm postinstall finishes while formatjs is still writing `app/static/translations/compiled/en-XA.json`, leaving the file empty when tests run and breaking `locale.test.js > loading the pseudo locale` on Node 24 CI runners. Switch to `execSync` so the postinstall blocks until formatjs has finished.
… and changelog entry Reverts: - bf3aed5 Add CHANGELOG entry for translation compile script fix - 0636c23 Make translation compile scripts wait for formatjs to finish The locale.test.js failure on Node 24 CI is caused by `@formatjs/cli@>=6.15.0` shipping native binaries that silently emit "Warning: Pseudo-locale transformations not yet implemented" and produce a single-element array instead of the expected 3-element pseudo-localized output. That root cause is fixed in #3842 (pin `@formatjs/cli` to 6.9.0 + verdaccio config to stop proxying monorepo packages). Reverting both commits since they were addressing the wrong symptom; we'll merge develop in once #3842 lands.
…dal-hooks # Conflicts: # packages/pwa-kit-runtime/CHANGELOG.md
PR's vendor.js is 395.33 KB gzip (was 394.78 KB on develop) — the new MrtDataStoreProvider context, useCustomSitePreferences / useCustomGlobalPreferences hooks, and the bootstrap-key wiring add ~0.55 KB to the shipped client bundle. Raise the budget by 2 kB so compile variance doesn't flake CI without giving up the guardrail.
Summary
Adds React Context provider and hooks to make MRT Data Store custom preferences easily accessible in template applications. The provider is automatically integrated into
the SSR rendering pipeline, requiring no manual setup from developers.
Changes
New Features (pwa-kit-react-sdk)
Context & Provider
Hooks
Tests
Usage Example
No setup required - provider is automatically integrated into the rendering pipeline!
Testing the Demo
Enable MRT Data Store in config/default.js:
app: {
mrtDataStore: {
enabled: true
}
}
Run with local data:
MRT_DATA_STORE_DEFAULTS='{"custom-global-preferences":{"theme":"dark"},"RefArch-custom-site-preferences":{"maxItems":10}}' PWAKIT_MRT_DATA_STORE_ENABLED=true npm start
Visit http://localhost:3000/demo-mrt-data-store
Files Changed
pwa-kit-react-sdk:
template-retail-react-app:
Separate Bug Fix (for another branch)
Bug: Signature Mismatch Between Client and Server Functions
Problem: Client and server versions of getCustomSitePreferences and getCustomGlobalPreferences have incompatible signatures:
Solution: Make both versions async and accept same parameters for consistency.
Files to change (pwa-kit-runtime):