Skip to content
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

Validations added for BannerLeftContent and BannerLeftAppearance of C… #561

Merged
merged 4 commits into from
Mar 12, 2025

Conversation

swapnils118
Copy link

…reateBannerPage using formik and yup

Describe your changes

Added form and schema validation to BannerLeftContent.jsx and BannerLeftAppearance.jsx components using formik and yup.
New components created:

  • bannerHelper.js
  • BannerLeftAppearance.css

Components modified:

  • CreateBannerPage.jsx
  • BannerLeftContent.jsx
  • BannerLeftAppearance.jsx

Issue number

#455

Screenshots attached:

content appearance

Copy link
Contributor

coderabbitai bot commented Mar 7, 2025

Walkthrough

This pull request updates both frontend and backend components related to banner functionality. It integrates Formik for managing and validating form inputs in multiple banner components, revises styling in corresponding CSS/SCSS modules, enforces stricter URL validation on the backend, and introduces a new helper module for validation schemas.

Changes

File(s) Summary
docker-compose.yml Adjusted indentation for the command section in the frontend service; no change to command logic.
frontend/.../BannerLeftAppearance/BannerLeftApperance.jsx
frontend/.../BannerLeftAppearance/BannerLeftApperance.module.scss
frontend/.../BannerLeftAppearance/BannerLeftAppearance.module.css
Refactored the component to integrate Formik for form management with Yup validation using an imported schema; enhanced error handling; restructured CSS styling and added new CSS classes for banner appearance.
frontend/.../BannerLeftContent/BannerLeftContent.jsx
frontend/.../BannerLeftContent/BannerLeftContent.module.scss
Incorporated Formik with a new validation schema (newBannerSchema) for managing and validating banner URL fields; updated error handling and prop types.
frontend/.../CreateBannerPage.jsx Standardised string literals from double quotes to single quotes; maintained existing functionality.
frontend/src/utils/bannerHelper.js Introduced a new file containing URL validation logic and Yup schemas (newBannerSchema and appearanceSchema) for form validation.
backend/src/utils/banner.helper.js Updated URL and actionUrl validation logic to enforce non-empty values with checks for absolute or relative URL patterns.

Sequence Diagram(s)

Loading
sequenceDiagram
    participant U as User
    participant BLA as BannerLeftAppearance Component
    participant FM as Formik Handler
    participant V as appearanceSchema (Yup)
    
    U->>BLA: Enter color values
    BLA->>FM: Set field values (backgroundColor, fontColor)
    FM->>V: Validate color inputs
    V -->>FM: Return validation result
    alt Valid Input
      FM->>BLA: Update state and render updated appearance
    else Invalid Input
      FM->>BLA: Display error messages
    end
Loading
sequenceDiagram
    participant U as User
    participant BLC as BannerLeftContent Component
    participant FM as Formik Handler
    participant V as newBannerSchema (Yup)
    participant BE as Backend Validator
    
    U->>BLC: Enter URL and Action URL
    BLC->>FM: Set field values (url, actionUrl)
    FM->>V: Validate URLs
    V -->>FM: Return validation result
    alt Valid Input
      FM->>BLC: Process form submission
      BLC->>BE: (Optional) Validate URL formats on backend
      BE -->>BLC: Return validation status
    else Invalid Input
      FM->>BLC: Display error messages
    end

Possibly related PRs

Suggested reviewers

  • gorkem-bwl
  • erenfn
✨ Finishing Touches
  • 📝 Generate Docstrings

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

‼️ IMPORTANT
Auto-reply has been disabled for this repository in the CodeRabbit settings. The CodeRabbit bot will not respond to your replies unless it is explicitly tagged.

  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Sorry, something went wrong.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 3

🧹 Nitpick comments (6)
frontend/src/scenes/banner/CreateBannerPage.jsx (1)

10-10: Naming Note: Appearance vs. Apperance!
The import statement for BannerLeftAppearance uses './BannerPageComponents/BannerLeftAppearance/BannerLeftApperance'. Consider standardizing the spelling to BannerLeftAppearance for consistency and clarity—no one wants to trip over a misspelt rhyme when the beat is on!

frontend/src/scenes/banner/BannerPageComponents/BannerLeftAppearance/BannerLeftAppearance.css (1)

16-23: Consider adding responsive width property.

The fixed width of 241px might not adapt well to different screen sizes. Consider using relative units or media queries for better responsiveness.

-  width: 241px;
+  width: 100%;
+  max-width: 241px;
frontend/src/utils/bannerHelper.js (1)

35-42: Hex color validation should support short format (#RGB).

The regex only supports 6-digit hex colors (#RRGGBB) but should also allow 3-digit format (#RGB) for convenience.

backgroundColor: Yup.string()
-  .matches(/^#[0-9A-Fa-f]{6}$/, 'Invalid value for Background Color')
+  .matches(/^#([0-9A-Fa-f]{3}|[0-9A-Fa-f]{6})$/, 'Invalid value for Background Color')
  .required('Background Color is required'),
fontColor: Yup.string()
-  .matches(/^#[0-9A-Fa-f]{6}$/, 'Invalid value for Font Color')
+  .matches(/^#([0-9A-Fa-f]{3}|[0-9A-Fa-f]{6})$/, 'Invalid value for Font Color')
  .required('Font Color is required'),
frontend/src/scenes/banner/BannerPageComponents/BannerLeftAppearance/BannerLeftApperance.jsx (1)

14-36: Consider adding enableReinitialize to Formik.

When prop values change externally, Formik won't update the form values unless enableReinitialize is set to true. This is important for components receiving props from parent components.

<Formik
  initialValues={{ backgroundColor, fontColor }}
+ enableReinitialize
  validationSchema={appearanceSchema}
  validateOnBlur={false}
  validateOnMount={false}
  onSubmit={async (values, { setSubmitting }) => {
frontend/src/scenes/banner/BannerPageComponents/BannerLeftContent/BannerLeftContent.jsx (2)

43-49: Consider adding form submission handling

Your Formik setup looks good with initialValues and schema validation, but I don't see an onSubmit handler. Is this form meant to be submitted somewhere? If not, that's cool, but if it is - you'll need to add that handler.

Also, you've got validateOnBlur set to false but then manually trigger validation in onBlur handlers - might wanna just set validateOnBlur to true instead.

<Formik
  initialValues={{ url, actionUrl }}
  validationSchema={newBannerSchema}
  enableReinitialize={true}
  validateOnMount={false}
-  validateOnBlur={false}
+  validateOnBlur={true}
>

99-113: Consider unifying state management with Formik

Your implementation works, but you're maintaining two sources of truth - Formik's internal state and your component props state. This could lead to synchronization issues.

You might want to let Formik handle the form state completely and update your parent component only when necessary (like on submit or field blur).

<CustomTextField
  TextFieldWidth="241px"
  error={!!errors.actionUrl}
  value={actionUrl}
  name="actionUrl"
- onChange={handleSetActionUrl}
+ onChange={(e) => {
+   handleSetActionUrl(e);
+   handleChange(e);  // Add Formik's handleChange
+ }}
  onBlur={(e) => {
    handleBlur(e);
-   validateField('actionUrl');
  }}
/>
📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 14e2bbc and 58f6afe.

⛔ Files ignored due to path filters (1)
  • frontend/dist/index.html is excluded by !**/dist/**
📒 Files selected for processing (10)
  • .env (1 hunks)
  • docker-compose.yml (2 hunks)
  • frontend/src/components/HintPageComponents/HintLeftContent/HintLeftContent.css (1 hunks)
  • frontend/src/scenes/banner/BannerPageComponents/BannerLeftAppearance/BannerLeftAppearance.css (1 hunks)
  • frontend/src/scenes/banner/BannerPageComponents/BannerLeftAppearance/BannerLeftApperance.jsx (1 hunks)
  • frontend/src/scenes/banner/BannerPageComponents/BannerLeftAppearance/BannerLeftApperance.module.scss (1 hunks)
  • frontend/src/scenes/banner/BannerPageComponents/BannerLeftContent/BannerLeftContent.jsx (3 hunks)
  • frontend/src/scenes/banner/BannerPageComponents/BannerLeftContent/BannerLeftContent.module.scss (1 hunks)
  • frontend/src/scenes/banner/CreateBannerPage.jsx (5 hunks)
  • frontend/src/utils/bannerHelper.js (1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (1)
  • GitHub Check: build (22.x)
🔇 Additional comments (19)
.env (1)

2-2: ENV Configuration Updated to Development!
Switching NODE_ENV from production to development sets the proper vibe for debugging—just like freestyling under pressure when your palms are sweaty. Everything looks solid here.

docker-compose.yml (2)

55-57: Frontend Volumes Commented Out!
Commenting out the volume mappings for the frontend service is a deliberate move to avoid syncing local directories inside the container. Just ensure this aligns with your development workflow—keep it smooth like a tight rap verse even if your knees are weak!


70-75: Updated Frontend Startup Command!
The conditional logic in the bash -c command now accurately distinguishes between the development and non-development environments. Just make sure the beat drops exactly as you expect when switching contexts.

frontend/src/components/HintPageComponents/HintLeftContent/HintLeftContent.css (1)

30-30: End-of-File Newline Added!
Though a small change, ending the file with a newline keeps things clean and prevents potential diff noise—like keeping your flow crisp when every line counts.

frontend/src/scenes/banner/CreateBannerPage.jsx (4)

27-30: Default State Values Set with a Strong Beat!
Initializing url and actionUrl with 'https://' (and setting default strings for actions) ensures your form’s initial values are in tune with the new validation schema. Keep that flow tight, just like a smooth verse.


47-54: Fetched Banner Data Mode: On Point!
The useEffect handling for edit mode now sets state values with safe fallbacks. When the pressure is high, these defaults are your insurance—ensure they harmonize with your Yup schema in bannerHelper.js.


70-82: onSave Logic Drops the Beat!
The onSave function compiles bannerData with clear, conditional values. Lower-casing button actions and setting toast messages makes the output as crisp as a well-delivered rap—just double-check that the messages match your intended tone.


90-129: Component Rendering is Ready to Rock!
Your JSX layout in BannerPage utilizes GuideTemplate smartly, separating preview and form content with fluid transitions. Everything meshes like a perfectly timed rhyme—ensure data flows as expected when the spotlight hits.

frontend/src/scenes/banner/BannerPageComponents/BannerLeftAppearance/BannerLeftApperance.module.scss (1)

3-18: Container Rework Brings the Style!
The newly structured .container class and its nested elements now flex and align like a crew in perfect sync. This rework supports the updated Formik form handling, keeping your style as fresh as a new beat drop.

frontend/src/scenes/banner/BannerPageComponents/BannerLeftAppearance/BannerLeftAppearance.css (2)

1-7: Good organization of container styling.

The flex container setup for banner appearance is well structured with appropriate direction and alignment properties. Using CSS variables like --main-text-color is a good practice for maintaining consistency across the application.


25-33: Well-structured error styling.

The error message styling is well thought out with appropriate font properties and color. The absolute positioning ensures the error messages don't disrupt the layout flow.

frontend/src/scenes/banner/BannerPageComponents/BannerLeftContent/BannerLeftContent.module.scss (1)

3-20: Nice SCSS organization with proper nesting.

The restructured container class with nested selectors follows good SCSS practices. This improves code readability and maintenance.

frontend/src/scenes/banner/BannerPageComponents/BannerLeftAppearance/BannerLeftApperance.jsx (2)

44-47: Good synchronization between Formik and parent state.

The component properly synchronizes Formik's internal state with the parent component's state by calling both setFieldValue and the respective setter functions from props.

Also applies to: 63-66


52-56: Error handling implementation is well done.

The conditional rendering of error messages with appropriate styling provides good user feedback when validation fails.

Also applies to: 71-75

frontend/src/scenes/banner/BannerPageComponents/BannerLeftContent/BannerLeftContent.jsx (5)

7-8: Good addition of form validation libraries

Nice job adding Formik and the validation schema! These are great tools for form management that'll make validation way more robust.


50-81: Form structure looks clean and well-organized

The Form component structure is looking solid. You've organized the repetition, action, and position controls in a logical way.


84-97: URL field validation implemented properly

Good job implementing validation for the URL field with proper error handling. Just make sure the "error-message" class is defined somewhere in your CSS.


114-117: Form structure wrapped up nicely

The closing tags are properly placed, and the overall structure of your Formik implementation looks clean.


132-132: PropType definition is correct

You've properly defined the buttonRepetition prop type as a string, which matches how it's used in the component.

@gorkem-bwl
Copy link
Contributor

UI wise looks good to me. What is all about the skeleton here? For some reason I missed that part previously.

image

@swapnils118
Copy link
Author

swapnils118 commented Mar 7, 2025

This skeleton reflects as if there is content on the page and the banner will either be on top or bottom w.r.t the content.
@gorkem-bwl

@erenfn erenfn changed the base branch from master to develop March 8, 2025 17:39
Copy link
Collaborator

@erenfn erenfn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make sure that you fork from develop and open your PRs to the develop branch.

Because of a validation in banner backend for Action Url we get 'Relative URL must start with /' error when we start with https://. Can you also change that validation to accept urls that start with https:// and http:// ?

@swapnils118
Copy link
Author

swapnils118 commented Mar 8, 2025

Because of a validation in banner backend for Action Url we get 'Relative URL must start with /' error when we start with https://. Can you also change that validation to accept urls that start with https:// and http:// ?

@erenfn So, I tried implementing the validation to accept url's starting with https:// and http:// which is absolute and relative respectively, what I found is irrespective of the validation logic in frontend, we are only able to pass either absolute or relative url in the two fields. So, I inspected the logic implemented for backend and what I found is

  • Both the fields should be optional. (So, I removed pre-initializing the fields with either type of protocol)
  • We are accepting only relative url's for Action Url field.

Solution to this:

  • We could let both the fields(URL and Action URL) empty without any pre-filled protocol methods.
  • We could modify the backend logic to be consistent for both the fields to accept either absolute or relative url's.

Issues Addressed:

  • .css file fixed to .module.css
  • Changes to volumes module under frontend fixed.

Waiting for your approval to fix it in any way you want and push the final code.

@swapnils118 swapnils118 requested a review from erenfn March 9, 2025 20:40
@erenfn
Copy link
Collaborator

erenfn commented Mar 9, 2025

Then let's go with:

  • URL should be required and Action URL can be optional.

  • Both should allow relative and absolute urls

…file fixed, BannerLeftAppearance.module.css file added
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

♻️ Duplicate comments (3)
frontend/src/utils/bannerHelper.js (2)

42-53: 🛠️ Refactor suggestion

Form validation ain't conditional based on action type - this ain't right

Your schema's validatein' URLs regardless of the action selected. If someone picks 'no action', they shouldn't need to provide valid URLs, ya feel me? Knees weak, arms heavy with unnecessary validation.

const newBannerSchema = Yup.object().shape({
  action: Yup.string().oneOf(
    ['no action', 'open url', 'open url in a new tab'],
    'Invalid value for action'
  ),
  url: Yup.string()
+   .when('action', {
+     is: (action) => action !== 'no action',
+     then: () => Yup.string()
          .test('url', 'Invalid value for URL', validateUrl)
          .max(2000, 'URL must be at most 2000 characters'),
+     otherwise: () => Yup.string()
+   }),
  actionUrl: Yup.string()
+   .when('action', {
+     is: (action) => action === 'open url' || action === 'open url in a new tab',
+     then: () => Yup.string()
          .test('actionUrl', 'Invalid value for Action URL', validateUrl)
          .max(2000, 'URL must be at most 2000 characters'),
+     otherwise: () => Yup.string()
+   }),
});

32-40: ⚠️ Potential issue

Yo, the URL validation logic needs a check for empty strings, dawg

The validateUrl function doesn't handle empty strings which could make your form validation choke. If a user submits without entering a URL, this function's gonna throw an error faster than dropping mom's spaghetti.

const validateUrl = (url) => {
+  if (!url) return false;
  try {
    new URL(url);
    return true;
  } catch {
    return RELATIVE_URL_REGEX.test(url);
  }
};
frontend/src/scenes/banner/BannerPageComponents/BannerLeftAppearance/BannerLeftApperance.jsx (1)

19-27: ⚠️ Potential issue

The onSave function is missing like mom's spaghetti - it'll crash at submit time

You're calling onSave() in the form submission handler, but this function ain't defined anywhere! Your app's gonna throw up an error when someone tries to submit this form.

onSubmit={async (values, { setSubmitting }) => {
  try {
-    onSave();
+    // Either define onSave function or handle submission directly
+    // If onSave should be a prop:
+    if (typeof onSave === 'function') {
+      onSave(values);
+    }
  } catch (error) {
    console.error(error);
  } finally {
    setSubmitting(false);
  }
}}
🧹 Nitpick comments (3)
frontend/src/utils/bannerHelper.js (1)

3-30: Clean up your commented code, bro - it's like old spaghetti stains

There's a ton of commented-out code versions of URL validation. It's making this file harder to read than rap lyrics without punctuation. Keep your code clean by removing these unused validation attempts.

Consider removing all these commented-out functions and regexes since you've settled on an implementation.

frontend/src/scenes/banner/BannerPageComponents/BannerLeftAppearance/BannerLeftApperance.jsx (1)

7-12: Props documentation would be nice - what's the expected format?

The component takes several props but there's no documentation about their expected types or formats. Adding some JSDoc comments would help other devs understand what to pass in without their knees getting weak trying to figure it out.

/**
+ * @param {string} backgroundColor - Hex color code for background
+ * @param {Function} setBackgroundColor - Function to update background color
+ * @param {string} fontColor - Hex color code for font
+ * @param {Function} setFontColor - Function to update font color
+ */
const BannerLeftAppearance = ({
  backgroundColor,
  setBackgroundColor,
  fontColor,
  setFontColor,
}) => {
backend/src/utils/banner.helper.js (1)

19-28: URL validation could be DRYer

You've got similar validation logic for both URL and actionUrl. Could refactor this to use the existing validateRelativeUrl function that's already defined later in the file (lines 73-83).

Consider reusing the existing validateRelativeUrl function to avoid duplicated validation logic.

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 58f6afe and 5d1f276.

⛔ Files ignored due to path filters (1)
  • frontend/dist/index.html is excluded by !**/dist/**
📒 Files selected for processing (6)
  • backend/src/utils/banner.helper.js (1 hunks)
  • docker-compose.yml (1 hunks)
  • frontend/src/scenes/banner/BannerPageComponents/BannerLeftAppearance/BannerLeftAppearance.module.css (1 hunks)
  • frontend/src/scenes/banner/BannerPageComponents/BannerLeftAppearance/BannerLeftApperance.jsx (1 hunks)
  • frontend/src/scenes/banner/CreateBannerPage.jsx (5 hunks)
  • frontend/src/utils/bannerHelper.js (1 hunks)
✅ Files skipped from review due to trivial changes (1)
  • frontend/src/scenes/banner/BannerPageComponents/BannerLeftAppearance/BannerLeftAppearance.module.css
🚧 Files skipped from review as they are similar to previous changes (2)
  • docker-compose.yml
  • frontend/src/scenes/banner/CreateBannerPage.jsx
🔇 Additional comments (5)
frontend/src/utils/bannerHelper.js (1)

55-63: You got commented-out optional validation too - decide what you want

There's a commented-out version of the appearance schema that makes fields optional. Based on PR comments about flexibility, maybe you actually want this version? Your palms are sweaty trying to decide between required and optional fields.

Double-check with your team whether the appearance fields should be required or optional based on the discussion in PR comments.

frontend/src/scenes/banner/BannerPageComponents/BannerLeftAppearance/BannerLeftApperance.jsx (2)

5-5: Check your CSS file extension, homie - module.css vs module.scss

You're importing from 'BannerLeftAppearance.module.css' but the PR summary mentions 'BannerLeftAppearance.css'. Make sure your import path matches the actual file name or your styles are gonna be missing like lyrics you forgot.

Verify that the file 'BannerLeftAppearance.module.css' exists in the correct location.


14-79: Form doesn't actually submit anything - what's the point?

The Formik setup has an onSubmit handler but there's no submit button and the form doesn't seem to be submitted anywhere. Is this intentional? Form's heavy with validation but has no way for users to actually submit it.

Is this form meant to auto-save? If so, consider using Formik's enableReinitialize prop and watching for value changes instead of having an unused submit handler.

backend/src/utils/banner.helper.js (2)

31-42: Action URL validation looks good for both relative and absolute URLs

The validation for actionUrl properly handles both relative and absolute URLs, allowing for flexibility as discussed in the PR comments. You're not throwing up on your sweater with this implementation.


32-42: Validation inconsistency between URL and actionUrl

URL is required but actionUrl is optional. Based on the PR discussion, this seems intentional, but the inconsistency in how they're validated might cause confusion. Your palms are gonna get sweaty debugging this later.

Verify this behavior is intentional based on this PR comment: "URL should be required while the Action URL could remain optional, with both fields allowing for relative and absolute URLs."

@swapnils118
Copy link
Author

swapnils118 commented Mar 10, 2025

@erenfn
Issues Addressed:

  • The URL input field modified to required (Backend logic for banner.helper.js).
  • Action URL remains optional.
  • Both now accepts absolute and relative url's.
  • Specific and clear error messages are displayed for smooth user interaction.
urlRequired relevantErrMsg

@erenfn
Copy link
Collaborator

erenfn commented Mar 11, 2025

Can be merged after resolving the conflicts. Most of them will be just styling differences

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

♻️ Duplicate comments (1)
frontend/src/scenes/banner/BannerPageComponents/BannerLeftAppearance/BannerLeftApperance.jsx (1)

15-28: ⚠️ Potential issue

Undefined onSave function will cause runtime error.

There's a call to onSave() in the form submission handler, but this function isn't defined anywhere in the component. This will throw an error when the form is submitted.

onSubmit={async (values, { setSubmitting }) => {
  try {
-    onSave();
+    // Either define onSave function or handle submission directly
+    // If onSave should be a prop:
+    if (typeof onSave === 'function') {
+      onSave(values);
+    }
  } catch (error) {
    console.error(error);
  } finally {
    setSubmitting(false);
  }
}}
📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between c8ab1f0 and 41c7e38.

⛔ Files ignored due to path filters (1)
  • frontend/dist/index.html is excluded by !**/dist/**
📒 Files selected for processing (2)
  • frontend/src/scenes/banner/BannerPageComponents/BannerLeftAppearance/BannerLeftApperance.jsx (1 hunks)
  • frontend/src/scenes/banner/CreateBannerPage.jsx (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • frontend/src/scenes/banner/CreateBannerPage.jsx
⏰ Context from checks skipped due to timeout of 90000ms (1)
  • GitHub Check: build (22.x)
🔇 Additional comments (5)
frontend/src/scenes/banner/BannerPageComponents/BannerLeftAppearance/BannerLeftApperance.jsx (5)

1-6: Clean imports, but let's check the appearance schema.

The imports look well-organized, importing the required components and utilities. The appearanceSchema is now properly imported from the bannerHelper utility.


8-13: Props structure looks good.

The component accepts the necessary props for managing banner appearance - backgroundColor, setBackgroundColor, fontColor, and setFontColor. These props are clearly defined and follow React's pattern for controlled components.


30-37: Good use of Formik's render props pattern.

The component correctly extracts the necessary Formik properties to handle form state, errors, and interactions.


38-58: Background color field implementation looks good.

The ColorTextField for background color is properly implemented with Formik integration. The onChange handler correctly updates both the Formik state and the parent component state. Error handling is also properly implemented.


59-77: Font color field implementation looks good.

Similar to the background color field, the font color field is also properly implemented with Formik integration and error handling.

@swapnils118
Copy link
Author

Can be merged after resolving the conflicts. Most of them will be just styling differences

  • Merge conflicts are resolved.

@erenfn erenfn merged commit 9c74f99 into develop Mar 12, 2025
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants