@capillarytech/creatives-library 9.0.13-alpha.0 → 9.0.13-alpha.1

package/v2Components/TemplatePreview/coderabbits_comments

@@ -1,171 +0,0 @@
-@coderabbitai
-coderabbitai Bot
-2 days ago
-⚠️ Potential issue | 🟠 Major | ⚡ Quick win
-
-Guard non-string channel values before calling toUpperCase().
-
-Current normalization crashes for truthy non-string channel values instead of returning null.
-
-Proposed fix
--export const getChannelAdapter = (channel) => adapters[(channel || '').toUpperCase()] || null;
-+export const getChannelAdapter = (channel) => {
-+  const key = typeof channel === 'string' ? channel.toUpperCase() : '';
-+  return adapters[key] || null;
-+};
-🤖 Prompt for AI Agents
-Verify each finding against current code. Fix only still-valid issues, skip the
-rest with a brief reason, keep changes minimal, and validate.
-
-In `@app/v2Components/FormBuilder/Functional/channels/registry.js` at line 12, The
-getChannelAdapter function does not guard against non-string values for the
-channel parameter. When a truthy non-string value (like a number or object) is
-passed, calling toUpperCase() on it will crash. Add a type check to ensure the
-channel value is a string before attempting to call toUpperCase() on it. If
-channel is not a string, return null directly. This prevents the crash while
-maintaining the existing behavior for null, undefined, and string values.
-
- 
-
-
-coderabbitai Bot
-2 days ago
-⚠️ Potential issue | 🟠 Major | ⚡ Quick win
-
-Guard MULTICOLS row dereference to prevent schema-driven crashes.
-
-Line 38/39 assumes every row exists. A null row from schema data will throw before form initialization completes.
-
-Proposed fix
--      (section.inputFields || []).forEach((row) => (row.cols || []).forEach(visit));
--      (section.actionFields || []).forEach((row) => (row.cols || []).forEach(visit));
-+      (section.inputFields || []).forEach((row) => (row?.cols || []).forEach(visit));
-+      (section.actionFields || []).forEach((row) => (row?.cols || []).forEach(visit));
-🤖 Prompt for AI Agents
-Verify each finding against current code. Fix only still-valid issues, skip the
-rest with a brief reason, keep changes minimal, and validate.
-
-In `@app/v2Components/FormBuilder/Functional/core/schema/initializeFormState.js`
-around lines 37 - 40, The MULTICOLS case in the section type handling does not
-guard against null or undefined row values before accessing the cols property,
-which will cause a crash if schema data contains null rows. Add a null check for
-each row within the forEach callbacks for both inputFields and actionFields
-processing to ensure the row exists before attempting to access row.cols,
-preventing dereferencing of null values during form initialization.
-
-
-
-
-coderabbitai Bot
-2 days ago
-⚠️ Potential issue | 🟠 Major | ⚡ Quick win
-
-Preserve original numeric tab indices when decoding legacy formData.
-
-Line 52 compacts tab keys into a dense array. For sparse legacy keys (e.g., only 1 present), toLegacy writes them back as 0, changing payload shape and base-tab addressing.
-
-Proposed fix
-📝 Committable suggestion
-‼️ IMPORTANT
-Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
-
-Suggested change
-  const orderedIndices = Object.keys(tabsByIndex)
-    .map(Number)
-    .sort((a, b) => a - b);
-  const tabs = orderedIndices.map((index) => tabsByIndex[index]);
-  const foundBase = tabs.findIndex((tab) => tab?.base);
-  const baseTabIndex = foundBase === -1 ? 0 : foundBase;
-  const orderedIndices = Object.keys(tabsByIndex)
-    .map(Number)
-    .sort((a, b) => a - b);
-  const tabs = [];
-  orderedIndices.forEach((index) => {
-    tabs[index] = tabsByIndex[index];
-  });
-  const foundBase = orderedIndices.find((index) => tabsByIndex[index]?.base);
-  const baseTabIndex = foundBase === undefined ? 0 : foundBase;
-🤖 Prompt for AI Agents
-Verify each finding against current code. Fix only still-valid issues, skip the
-rest with a brief reason, keep changes minimal, and validate.
-
-In `@app/v2Components/FormBuilder/Functional/core/store/toLegacyFormData.js`
-around lines 49 - 56, The issue is that the code compacts sparse tab indices
-into a dense array by mapping orderedIndices to a new tabs array, which loses
-the original numeric indices and changes the payload shape when converting back
-to legacy format. Instead of creating a compacted tabs array using
-orderedIndices.map, preserve the sparse structure by keeping the original
-numeric keys from tabsByIndex and adjusting the baseTabIndex calculation to work
-with the actual tab indices rather than array positions.
-
-
-@coderabbitai
-coderabbitai Bot
-2 days ago
-⚠️ Potential issue | 🟡 Minor | ⚡ Quick win
-
-Fix TagList prop contract types/defaults in FormBuilderShell.
-
-selectedOfferDetails and waitEventContextTags are typed opposite to how app/v2Containers/TagList/index.js consumes them (array and object respectively), which weakens contract checks and can hide wrong-shape regressions.
-
-Suggested fix
- FormBuilderShell.propTypes = {
-@@
--  selectedOfferDetails: PropTypes.object,
-+  selectedOfferDetails: PropTypes.array,
-@@
--  waitEventContextTags: PropTypes.array,
-+  waitEventContextTags: PropTypes.object,
-@@
- FormBuilderShell.defaultProps = {
-@@
--  selectedOfferDetails: undefined,
-+  selectedOfferDetails: [],
-@@
--  waitEventContextTags: [],
-+  waitEventContextTags: {},
-Also applies to: 361-364
-
-🤖 Prompt for AI Agents
-Verify each finding against current code. Fix only still-valid issues, skip the
-rest with a brief reason, keep changes minimal, and validate.
-
-In `@app/v2Components/FormBuilder/Functional/FormBuilderShell.js` around lines 348
-- 350, The PropTypes definitions for selectedOfferDetails and
-waitEventContextTags in the FormBuilderShell propTypes are typed incorrectly
-compared to how they are consumed in the TagList component. Change
-selectedOfferDetails from PropTypes.object to PropTypes.array, and change
-waitEventContextTags from PropTypes.array to PropTypes.object. Apply the same
-type corrections to any other instances of these props mentioned in the file
-(lines 361-364).
-
-
-@coderabbitai
-coderabbitai Bot
-2 days ago
-⚠️ Potential issue | 🟠 Major | ⚡ Quick win
-
-Characterization can unintentionally run Functional instead of Classic.
-
-Line 22 imports the entry-gated FormBuilder (../index), and that gate can route SMS to Functional based on feature access. For a Classic golden suite, this makes the target non-deterministic and can hide Classic regressions.
-
-Suggested fix
--import FormBuilder from '../index';
-+import ClassicFormBuilder from '../Classic';
-@@
--const ComponentToRender = injectIntl(FormBuilder);
-+const ComponentToRender = injectIntl(ClassicFormBuilder);
-Also applies to: 47-47
-
-🤖 Prompt for AI Agents
-Verify each finding against current code. Fix only still-valid issues, skip the
-rest with a brief reason, keep changes minimal, and validate.
-
-In `@app/v2Components/FormBuilder/tests/sms.characterization.test.js` around lines
-22 - 23, The imports on line 22 and line 47 use the entry-gated FormBuilder from
-../index which can route SMS to Functional based on feature access. For the
-Classic characterization test to be deterministic and properly test Classic
-behavior, import the Classic FormBuilder implementation directly rather than
-going through the gated entry point. Replace the imports from ../index with
-direct imports to the Classic FormBuilder implementation to ensure the test
-always uses the Classic version.