@mx-cartographer/experiences 9.4.26 → 9.4.27
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md
CHANGED
|
@@ -1,3 +1,8 @@
|
|
|
1
|
+
## [9.4.27] - 09-16-2026
|
|
2
|
+
|
|
3
|
+
- **FIXED** - Insights V2 `FeeDetected` and `LargeTransaction` CTAs opened the "Something went wrong" drawer instead of the transaction. [ditto!19](https://gitlab.com/mxtechnologies/mx/experiences/projects/ditto/-/merge_requests/19) renamed `primary_cta_block` from `view_charge` to `transaction_details`, naming the block for the drilldown it opens rather than the button copy (which tupac owns and can change). Neither name was registered here — `actionBlocksKey.TRANSACTION_DETAILS_ACTION_BLOCK` carried `TransactionDetailsBlock`, a name no backend ever sent. `ActionBlockLayer` resolves the CTA by exact match and `hasDrawerBlock()` returns true for any non-empty string, so an unregistered name opens the drawer onto the error state rather than failing silently. Points the registry key at the name ditto now sends, and updates the `FeeDetected`/`LargeTransaction` mock payloads to match. No alias is kept for `view_charge`: ditto no longer sends it and it was never registered (MEW2-3254)
|
|
4
|
+
- **NOTE** - The registry key is global, so the two Storybook-only `BarchartBlockPayload.json` fixtures that still name `TransactionDetailsBlock` (`BillAmountNotStandard`, `SavingsAccountBalancesSummary`) now point at an unregistered key and will open the error drawer in Storybook. Deliberately left out of scope; no contract test covers `BarchartBlockBeats`, so this does not fail CI (MEW2-3254)
|
|
5
|
+
|
|
1
6
|
## [9.4.26] - 09-16-2026
|
|
2
7
|
|
|
3
8
|
- **FIXED** - Account filter accessibility (MEW-3452)
|
|
@@ -2,7 +2,7 @@ var _ = {
|
|
|
2
2
|
PLACEHOLDER_ACTION_BLOCK: "PlaceholderActionBlock",
|
|
3
3
|
MAKE_TRANSFER_ACTION_BLOCK: "make_transfer",
|
|
4
4
|
TRANSCATION_HISTORY_ACTION_BLOCK: "transaction_history_block",
|
|
5
|
-
TRANSACTION_DETAILS_ACTION_BLOCK: "
|
|
5
|
+
TRANSACTION_DETAILS_ACTION_BLOCK: "transaction_details"
|
|
6
6
|
};
|
|
7
7
|
export {
|
|
8
8
|
_ as actionBlocksKey
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"actionBlocksKey.es.js","names":[],"sources":["../../../src/insights-v2/mappings/actionBlocksKey.ts"],"sourcesContent":["// Keys for the drawer drilldown registry in `blocks.ts`, extracted into their own module.\n//\n// Why: chart blocks (e.g. BarchartBlock, DoubleBarChartBlock) need\n// `TRANSCATION_HISTORY_ACTION_BLOCK` to tag a chart bar's drilldown context, but they are\n// themselves re-exported through `../blocks` -> `mappings/blocks.ts` imports from that same\n// barrel to build its `blocks` registry. Importing the key straight from `mappings/blocks.ts`\n// closed that loop into a circular import: evaluating `mappings/blocks.ts` pulled in the\n// `blocks` barrel, which (before it got to `ComponentBlocks`/`AccountBlock`) loaded\n// `BarchartBlock`, which imported back into the still-initializing `mappings/blocks.ts` —\n// tripping a \"Cannot access 'AccountBlock' before initialization\" TDZ error in Storybook/Vite.\n//\n// Keeping the keys here (no dependency on `mappings/blocks.ts`) lets chart blocks reference\n// them without re-entering that module.\nexport const actionBlocksKey = {\n PLACEHOLDER_ACTION_BLOCK: 'PlaceholderActionBlock',\n MAKE_TRANSFER_ACTION_BLOCK: 'make_transfer',\n TRANSCATION_HISTORY_ACTION_BLOCK: 'transaction_history_block',\n TRANSACTION_DETAILS_ACTION_BLOCK: '
|
|
1
|
+
{"version":3,"file":"actionBlocksKey.es.js","names":[],"sources":["../../../src/insights-v2/mappings/actionBlocksKey.ts"],"sourcesContent":["// Keys for the drawer drilldown registry in `blocks.ts`, extracted into their own module.\n//\n// Why: chart blocks (e.g. BarchartBlock, DoubleBarChartBlock) need\n// `TRANSCATION_HISTORY_ACTION_BLOCK` to tag a chart bar's drilldown context, but they are\n// themselves re-exported through `../blocks` -> `mappings/blocks.ts` imports from that same\n// barrel to build its `blocks` registry. Importing the key straight from `mappings/blocks.ts`\n// closed that loop into a circular import: evaluating `mappings/blocks.ts` pulled in the\n// `blocks` barrel, which (before it got to `ComponentBlocks`/`AccountBlock`) loaded\n// `BarchartBlock`, which imported back into the still-initializing `mappings/blocks.ts` —\n// tripping a \"Cannot access 'AccountBlock' before initialization\" TDZ error in Storybook/Vite.\n//\n// Keeping the keys here (no dependency on `mappings/blocks.ts`) lets chart blocks reference\n// them without re-entering that module.\nexport const actionBlocksKey = {\n PLACEHOLDER_ACTION_BLOCK: 'PlaceholderActionBlock',\n MAKE_TRANSFER_ACTION_BLOCK: 'make_transfer',\n TRANSCATION_HISTORY_ACTION_BLOCK: 'transaction_history_block',\n TRANSACTION_DETAILS_ACTION_BLOCK: 'transaction_details',\n}\n"],"mappings":"AAaA,IAAa,IAAkB;AAAA,EAC7B,0BAA0B;AAAA,EAC1B,4BAA4B;AAAA,EAC5B,kCAAkC;AAAA,EAClC,kCAAkC;AACpC"}
|