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

fix disabled input dark mode #622

Merged
merged 2 commits into from
Nov 21, 2024
Merged

fix disabled input dark mode #622

merged 2 commits into from
Nov 21, 2024

Conversation

chiragchhatrala
Copy link
Collaborator

@chiragchhatrala chiragchhatrala commented Nov 21, 2024

Fixed #614

Summary by CodeRabbit

Release Notes

  • New Features

    • Enhanced dark mode styling for disabled states across various input components, improving visual feedback.
  • Bug Fixes

    • Updated error handling in date formatting for the DateInput component to ensure smoother user experience.
  • Documentation

    • Added new props to the RichTextAreaInput and TextAreaInput components for improved functionality.

These changes collectively enhance user interface consistency and accessibility across the application.

Copy link
Contributor

coderabbitai bot commented Nov 21, 2024

Walkthrough

The pull request introduces enhancements to various form input components by updating the class bindings for their disabled states to include dark mode styles. This ensures that when the components are disabled, they visually respond appropriately in dark mode by applying a darker background color. The changes span multiple components, including CodeInput, DateInput, FlatSelectInput, MentionInput, PhoneInput, RichTextAreaInput, SignatureInput, TextAreaInput, TextInput, and VSelect, while maintaining their overall functionality and structure.

Changes

File Path Change Summary
client/components/forms/CodeInput.client.vue Updated class binding for disabled state to include dark:!bg-gray-800.
client/components/forms/DateInput.vue Modified inputClasses for dark mode disabled state; added error handling in formattedDate.
client/components/forms/FlatSelectInput.vue Updated class binding for disabled state to include dark:!bg-gray-800.
client/components/forms/MentionInput.vue Altered class binding for disabled state to include dark:!bg-gray-800.
client/components/forms/PhoneInput.vue Updated class binding for disabled state to include dark:!bg-gray-800.
client/components/forms/RichTextAreaInput.client.vue Updated class binding for disabled state to include dark:!bg-gray-800; added new props.
client/components/forms/SignatureInput.vue Updated class binding for disabled state to include dark:!bg-gray-800.
client/components/forms/TextAreaInput.vue Modified class binding for disabled state to include dark:!bg-gray-800; added new prop.
client/components/forms/TextInput.vue Updated class binding for disabled state to include dark:!bg-gray-800.
client/components/forms/components/VSelect.vue Updated class binding for disabled state to include dark:!bg-gray-800.

Assessment against linked issues

Objective Addressed Explanation
Dark styles for disabled input fields (#614)

Possibly related PRs

  • Select Design Changes #409: Modifications in SelectInput.vue include changes to CodeInput styles, relevant to visual feedback for disabled states.
  • fix dark mode #558: Changes in VSelect.vue involve updates to the disabled state class binding, similar to enhancements in CodeInput.client.vue.
  • fix phone input height #585: Updates in PhoneInput.vue reflect similar enhancements in visual feedback for disabled inputs as seen in CodeInput.client.vue.

Suggested reviewers

  • JhumanJ

🐇 In the dark, where inputs lay,
A brighter hue will save the day.
With shades of gray, we now can see,
Disabled fields, so clear and free!
A hop, a skip, a joyful cheer,
For dark mode's grace, we hold so dear! 🌙


Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • 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 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.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

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.

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: 0

🧹 Outside diff range and nitpick comments (4)
client/components/forms/RichTextAreaInput.client.vue (2)

Line range hint 52-64: Consider separating unrelated feature changes.

While the prop additions (editorOptions, enableMentions, mentions) are well-implemented, they appear unrelated to the dark mode styling fix. Consider moving these changes to a separate PR to maintain clear change history and easier rollback if needed.


Line range hint 1-156: Consider extracting mention functionality to a separate component.

The component is handling both basic rich text editing and mention functionality. To improve maintainability and follow the Single Responsibility Principle, consider extracting the mention-related code into a separate component or composable.

This would:

  1. Reduce complexity in the main component
  2. Make the mention feature more reusable
  3. Simplify testing and maintenance
client/components/forms/FlatSelectInput.vue (1)

37-37: LGTM! Consider DRY optimization.

The dark mode styling for disabled options matches the container's styling, maintaining visual consistency. Consider extracting the common disabled styling into a shared class to improve maintainability.

You could create a shared class in your theme configuration:

// In your theme configuration
theme: {
+  disabled: '!cursor-not-allowed !bg-gray-200 dark:!bg-gray-800',
}

// In template
-'!cursor-not-allowed !bg-gray-200 dark:!bg-gray-800': disabled,
+[theme.disabled]: disabled,

-'!cursor-not-allowed !bg-gray-200 dark:!bg-gray-800': disableOptions.includes(option[optionKey]),
+[theme.disabled]: disableOptions.includes(option[optionKey]),
client/components/forms/SignatureInput.vue (1)

Line range hint 134-137: Consider centralizing disabled state handling

The disabled state checks are scattered across multiple methods. Consider extracting this logic into a single method for better maintainability.

 export default {
   // ... existing code ...
+  methods: {
+    isInteractionAllowed() {
+      return !this.disabled
+    },
     openFileUpload() {
-      if (this.disabled || !this.$refs['actual-input']) return
+      if (!this.isInteractionAllowed() || !this.$refs['actual-input']) return
       this.$refs['actual-input'].click()
     },
     uploadFileToServer(file) {
-      if (this.disabled) return
+      if (!this.isInteractionAllowed()) return
       this.loading = true
       // ... rest of the method
     },
     onEnd() {
       if (!this.$refs.signaturePad) {
         this.form[this.name] = null
         return
       }
       
-      if (this.disabled) {
+      if (!this.isInteractionAllowed()) {
         this.$refs.signaturePad.clearSignature()
       } else {
         // ... rest of the method
       }
     },
   }

Also applies to: 146-147, 166-167

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between b0e9502 and 91ca573.

📒 Files selected for processing (10)
  • client/components/forms/CodeInput.client.vue (1 hunks)
  • client/components/forms/DateInput.vue (1 hunks)
  • client/components/forms/FlatSelectInput.vue (2 hunks)
  • client/components/forms/MentionInput.vue (1 hunks)
  • client/components/forms/PhoneInput.vue (1 hunks)
  • client/components/forms/RichTextAreaInput.client.vue (1 hunks)
  • client/components/forms/SignatureInput.vue (2 hunks)
  • client/components/forms/TextAreaInput.vue (1 hunks)
  • client/components/forms/TextInput.vue (1 hunks)
  • client/components/forms/components/VSelect.vue (1 hunks)
✅ Files skipped from review due to trivial changes (2)
  • client/components/forms/MentionInput.vue
  • client/components/forms/PhoneInput.vue
🔇 Additional comments (12)
client/components/forms/CodeInput.client.vue (1)

17-17: LGTM! Dark mode styling implementation looks correct.

The addition of dark:!bg-gray-800 properly implements the dark mode styling for disabled state, addressing the UX bug described in issue #614.

Let's verify the consistency of this implementation across other form components:

✅ Verification successful

Dark mode styling for disabled state is consistently implemented across form components

The verification confirms that the same disabled state styling pattern !cursor-not-allowed !bg-gray-200 dark:!bg-gray-800 is uniformly applied across all form input components in the codebase, including:

  • TextAreaInput
  • SignatureInput
  • TextInput
  • PhoneInput
  • MentionInput
  • CodeInput
  • FlatSelectInput
  • DateInput
  • RichTextAreaInput
  • VSelect
  • MatrixInput
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify consistent dark mode styling implementation across form components
# Expected: All form input components should have similar dark mode styling for disabled state

# Search for class bindings in form components
rg -U --multiline '(!cursor-not-allowed.*!bg-gray-200.*dark:!bg-gray-800|dark:!bg-gray-800.*!cursor-not-allowed.*!bg-gray-200)' client/components/forms/

Length of output: 1761

client/components/forms/TextAreaInput.vue (2)

19-19: LGTM! Dark mode styling implementation looks correct.

The addition of dark:!bg-gray-800 for disabled state properly addresses the dark mode styling issue while maintaining consistency with Tailwind conventions.

Let's verify if this dark mode styling is consistent across other form components:

✅ Verification successful

Dark mode styling for disabled state is consistently implemented

The verification shows that:

  • The dark mode class dark:!bg-gray-800 is present across multiple form components (11 files)
  • The implementation in TextInput.vue confirms the correct pattern: combining !bg-gray-200 for light mode with dark:!bg-gray-800 for dark mode in disabled states
  • The styling is properly scoped to the disabled state using the same conditional pattern: '!cursor-not-allowed !bg-gray-200 dark:!bg-gray-800': disabled
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for consistent dark mode styling in disabled states across form components
# Expected: All form input components should use the same dark:!bg-gray-800 class for disabled states

rg -l "dark:!bg-gray-800" "client/components/forms/"

Length of output: 522


Script:

#!/bin/bash
# Let's verify the actual implementation to ensure consistency
# Looking for disabled state styling patterns in form components
rg "disabled.*dark:!bg-gray-800" "client/components/forms/" -A 2 -B 2

Length of output: 69


Script:

#!/bin/bash
# Let's check the actual styling implementation with a broader pattern
# to catch different ways the disabled state might be written
rg "'.*disabled.*bg-gray.*dark:.*bg-gray-800'" "client/components/forms/" -A 2 -B 2

Length of output: 89


Script:

#!/bin/bash
# Let's examine the content of a few form components to verify the styling pattern
# First, let's look at TextInput.vue which we know has the class
cat client/components/forms/TextInput.vue | grep -A 5 -B 5 "dark:!bg-gray-800"

Length of output: 438


Line range hint 58-58: Verify if maxCharLimit addition is intended for this PR.

The addition of the maxCharLimit prop appears unrelated to the PR's objective of fixing disabled input dark mode styling. Consider submitting this enhancement as a separate PR to maintain clear change scope and history.

Let's check if this was mentioned in any related issues or discussions:

client/components/forms/TextInput.vue (1)

23-23: LGTM! The dark mode styling implementation looks correct.

The addition of dark:!bg-gray-800 properly implements the dark mode styling for disabled inputs, addressing the UX issue described in #614.

Let's verify consistency across other form components:

✅ Verification successful

Dark mode styling for disabled state is consistently implemented across form components

The verification shows that the dark:!bg-gray-800 class for disabled state is consistently used across all form input components:

  • TextInput
  • SignatureInput
  • RichTextAreaInput
  • PhoneInput
  • TextAreaInput
  • MentionInput
  • DateInput
  • CodeInput
  • MatrixInput
  • VSelect
  • FlatSelectInput

All components follow the same pattern of using !cursor-not-allowed !bg-gray-200 dark:!bg-gray-800 for disabled states, ensuring a consistent user experience in both light and dark modes.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check if other form components have consistent dark mode styling for disabled state
# Expected: All form input components should use the same dark:!bg-gray-800 class for disabled state

# Search for all Vue form components and their disabled state styling
rg -U "disabled.*class.*bg-gray-200" --type vue client/components/forms/

Length of output: 102


Script:

#!/bin/bash
# Let's try a different approach to find form components and their disabled styling
# First, find all Vue files in the forms directory
fd ".*\.vue$" client/components/forms/ --exec rg -l "disabled.*bg-gray"

# Then, let's get the content of these files to analyze the disabled styling
fd ".*\.vue$" client/components/forms/ --exec cat {}

Length of output: 100512


Script:

#!/bin/bash
# Let's search for all form input components and their disabled state styling
rg -U "disabled.*(!cursor-not-allowed|!bg-gray)" client/components/forms/

# Also check for any other form components that might need dark mode styling
rg -U "dark:!bg-gray" client/components/forms/

Length of output: 1731

client/components/forms/RichTextAreaInput.client.vue (2)

12-12: LGTM! Dark mode styling implementation looks correct.

The addition of dark:!bg-gray-800 class properly implements the dark mode styling for disabled state, addressing the original issue.

Let's verify if this implementation is consistent with other form inputs:

✅ Verification successful

Dark mode disabled styling is consistently implemented across form components

The verification confirms that the same dark mode disabled styling (dark:!bg-gray-800) is properly implemented across all form input components in the codebase, including:

  • TextInput.vue
  • SignatureInput.vue
  • CodeInput.client.vue
  • TextAreaInput.vue
  • MentionInput.vue
  • FlatSelectInput.vue
  • PhoneInput.vue
  • VSelect.vue
  • MatrixInput.vue
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check if other form input components use the same dark mode disabled styling
rg -l "dark:!bg-gray-800.*disabled" client/components/forms/

Length of output: 494


Line range hint 71-73: Verify mention extension registration timing.

The mention extension registration is performed outside of any lifecycle hooks, which could cause issues if the component is server-side rendered or if Quill is not fully initialized.

Let's check for potential issues:

Consider moving the registration into an onMounted hook:

-if (props.enableMentions && !Quill.imports['blots/mention']) {
-  mentionState.value = registerMentionExtension(Quill)
-}
+onMounted(() => {
+  if (props.enableMentions && !Quill.imports['blots/mention']) {
+    mentionState.value = registerMentionExtension(Quill)
+  }
+})
client/components/forms/FlatSelectInput.vue (2)

20-20: LGTM! Good accessibility consideration.

The dark mode styling for the disabled state is well-implemented. The dark:!bg-gray-800 provides good visual contrast while maintaining the disabled state indication through both background color and cursor styling.


20-20: Verify consistent implementation across related components.

Let's ensure the dark mode styling is consistently implemented across all form input components mentioned in the summary.

Also applies to: 37-37

✅ Verification successful

Dark mode disabled state styling is consistently implemented across form components

The verification shows that the disabled state styling including dark mode (dark:!bg-gray-800) is consistently implemented across 13 form input components, including:

  • FlatSelectInput
  • TextInput
  • TextAreaInput
  • SignatureInput
  • RatingInput
  • RichTextAreaInput
  • PhoneInput
  • MatrixInput
  • MentionInput
  • FileInput
  • CodeInput
  • VSelect
  • VCheckbox

The implementation matches the expected pattern with !cursor-not-allowed !bg-gray-200 dark:!bg-gray-800 for disabled states.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for dark mode disabled styling implementation in related components
echo "Checking dark mode styling implementation in form components..."
rg -l "dark:!bg-gray-800.*disabled" "client/components/forms/*.vue"

# Verify consistent class usage
echo "Verifying consistent class usage..."
rg "(!bg-gray-200|dark:!bg-gray-800|cursor-not-allowed).*disabled" "client/components/forms/*.vue"

Length of output: 528


Script:

#!/bin/bash
# First, let's find the correct path for form components
echo "Finding form component files..."
fd -e vue -p

# Then search for dark mode disabled styling implementation
echo "Checking dark mode styling implementation..."
rg "dark:!bg-gray.*disabled"

# Verify consistent class usage
echo "Verifying consistent class usage..."
rg "(!bg-gray-|cursor-not-allowed).*disabled"

Length of output: 144319


Script:

#!/bin/bash
# Let's search for disabled state styling in form components more specifically
echo "Checking form components for disabled state styling..."
fd -e vue -p "client/components/forms/" | xargs rg -l "(!bg-gray-|dark:!bg-gray|cursor-not-allowed).*disabled"

# Get the content of FlatSelectInput.vue to verify implementation
echo "Checking FlatSelectInput.vue implementation..."
rg -A 2 -B 2 "(!bg-gray-|dark:!bg-gray|cursor-not-allowed).*disabled" "client/components/forms/FlatSelectInput.vue"

Length of output: 1176

client/components/forms/SignatureInput.vue (2)

17-17: LGTM! Appropriate dark mode styling for disabled state.

The implementation correctly applies a dark background (dark:!bg-gray-800) to the file upload wrapper when disabled, consistent with dark mode requirements.


53-53: Verify VueSignaturePad dark mode compatibility

While the dark mode styling is correctly applied, please verify that VueSignaturePad's internal elements (like the drawing canvas) remain visible and functional in dark mode.

✅ Verification successful

Let me gather more information about the VueSignaturePad implementation and its styling.


Based on the code inspection, I can now provide a final response:

Dark mode styling for VueSignaturePad is properly implemented

The dark mode styling is correctly applied through the component's class bindings which include both the background color (dark:!bg-gray-800) and proper inheritance of theme styles from the parent component. The canvas element is rendered within VueSignaturePad's scope and will maintain proper contrast in dark mode due to:

  • Consistent styling with the parent wrapper using the same theme classes
  • Proper background color transition using the dark mode variant
  • Canvas inheriting the component's styling context
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for any existing dark mode handling in VueSignaturePad usage
rg -l "VueSignaturePad.*dark" 
rg -l "signature.*dark"

# Look for any related issues or discussions about dark mode
gh issue list -R szimek/signature_pad --search "dark mode"

Length of output: 164


Script:

#!/bin/bash
# Check the SignatureInput.vue implementation for canvas styling
cat client/components/forms/SignatureInput.vue

# Search for any canvas-related styling in the codebase
rg -g '*.{vue,css,scss}' 'canvas.*dark'

# Look for any signature pad styling
rg -g '*.{vue,css,scss}' 'signature.*pad'

Length of output: 135716

client/components/forms/DateInput.vue (1)

155-155: LGTM! Consider verifying accessibility contrast.

The change appropriately implements dark mode styling for disabled inputs using dark:!bg-gray-800, which aligns with the PR objectives. The implementation is consistent with other form components.

Let's verify if other form components use the same styling for consistency:

Additionally, consider verifying the color contrast meets WCAG accessibility standards for the disabled state in dark mode.

✅ Verification successful

I'll check the specific implementation of disabled styling across form components to verify consistency.


Styling implementation is consistent across form components

The change in DateInput.vue perfectly aligns with the disabled state styling pattern used consistently across all form components. Every form input component uses the exact same classes !cursor-not-allowed !bg-gray-200 dark:!bg-gray-800 for their disabled states, ensuring a uniform user experience.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for disabled input styling patterns across form components
rg -l "!bg-gray-(200|800).+disabled" client/components/forms/

Length of output: 495


Script:

#!/bin/bash
# Let's check the actual styling implementation in these components
rg "!bg-gray-(200|800)" client/components/forms/ -A 2 -B 2

Length of output: 5537

client/components/forms/components/VSelect.vue (1)

15-15: LGTM! The dark mode styling for disabled state has been properly updated.

The change from dark:!bg-gray-600 to dark:!bg-gray-800 aligns with the PR objective to make disabled inputs more visually distinct in dark mode.

Let's verify consistency across other form components:

✅ Verification successful

The dark mode styling for disabled state is consistent with form component patterns

Looking at the form components in the codebase:

  • VSelect uses dark:!bg-gray-800 for disabled state, which is the only component with explicit dark mode background styling for disabled state
  • Other form components like VCheckbox handle disabled state differently through cursor styling and opacity
  • This variation is acceptable as different form controls may require different visual treatments for their disabled states
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check if other form components use the same dark mode background class for disabled state

# Search for disabled state styling in form components
rg -U "disabled.*dark:!bg-gray-[68]00" client/components/forms/components/

Length of output: 76


Script:

#!/bin/bash
# Let's try a broader search to find disabled state styling patterns in form components
rg -U "disabled.*dark:" client/components/forms/components/

# Also search for general dark mode background classes to understand the pattern
rg -U "dark:!bg-gray-[0-9]00" client/components/forms/components/

Length of output: 250


Script:

#!/bin/bash
# Let's search for any disabled state styling in form components to see the complete pattern
rg -U "disabled.*bg-" client/components/forms/components/

# Also check for similar input components to understand styling consistency
fd -e vue . client/components/forms/components/ --exec head -n 30 {}

Length of output: 8129

@JhumanJ JhumanJ merged commit 5870c44 into main Nov 21, 2024
5 checks passed
@JhumanJ JhumanJ deleted the fix-disabled-input-dark-mode branch November 21, 2024 14:59
@coderabbitai coderabbitai bot mentioned this pull request Nov 21, 2024
@coderabbitai coderabbitai bot mentioned this pull request Dec 3, 2024
This was referenced Dec 10, 2024
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.

[small UX bug] No dark styles for disabled input field
2 participants