-
Notifications
You must be signed in to change notification settings - Fork 313
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
improve RTL mode #625
improve RTL mode #625
Conversation
Caution Review failedThe pull request is closed. WalkthroughThe changes in this pull request focus on enhancing support for text directionality (LTR and RTL) across various Vue components within the application. Key modifications include the addition of conditional class bindings and properties to manage text alignment, borders, and overall layout direction. Notably, the Changes
Possibly related PRs
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? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this 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
🧹 Outside diff range and nitpick comments (11)
client/app.vue (1)
Line range hint
12-35
: Consider RTL adjustments for UI elementsThe announcement component contains direction-sensitive elements that might need RTL adjustments:
- The close button is absolutely positioned on the right
- SVG icons might need horizontal flipping in RTL mode
Consider these RTL-aware modifications:
<div role="button" - class="text-white absolute right-0 top-0 p-3 cursor-pointer" + class="text-white absolute ltr:right-0 rtl:left-0 top-0 p-3 cursor-pointer" @click="announcement = false" > <svg xmlns="http://www.w3.org/2000/svg" - class="h-6 w-6" + class="h-6 w-6 rtl:transform rtl:scale-x-[-1]" viewBox="0 0 20 20" fill="currentColor" >client/components/forms/MatrixInput.vue (1)
18-18
: Improve border handling in RTL modeThe border implementation for RTL mode could be simplified and made more consistent:
- class="ltr:border-l rtl:border-r rtl:!border-l-0 border-gray-300 max-w-24 overflow-hidden" + class="ltr:border-l rtl:border-r border-gray-300 dark:border-gray-600 max-w-24 overflow-hidden"This change:
- Removes redundant
rtl:!border-l-0
as it's not needed- Adds dark mode support for borders to match the theme
Also applies to: 22-22
client/components/forms/PhoneInput.vue (1)
Line range hint
1-205
: Overall RTL implementation looks solid with a minor suggestion.The RTL implementation correctly handles the main layout concerns. The use of flex layout and space utilities will work correctly in RTL mode. However, consider adding a comment in the code documenting the RTL behavior for future maintainers, especially regarding the country selector dropdown alignment and flag positioning.
Add a comment above the main container:
<div :id="id ? id : name" :name="name" :style="inputStyle" + <!-- This container uses RTL-aware flex layout. The country selector and input field will automatically flip in RTL mode. --> class="flex items-stretch" >
client/components/open/forms/components/form-components/FormCustomization.vue (1)
Line range hint
39-52
: Enhance RTL support for flex layoutsThe flex container uses
space-x-4
which doesn't automatically adjust for RTL mode. Consider using RTL-aware spacing utilities to ensure consistent spacing in both directions.Here's how to improve the RTL support:
-<div class="flex space-x-4 justify-stretch"> +<div class="flex ltr:space-x-4 rtl:space-x-reverse justify-stretch">Additionally, consider adding these RTL-specific improvements:
- Use
rtl:
variants for padding/margin where needed- Add
dir
attribute binding to the root element- Consider reversing the order of input groups in RTL mode using
rtl:flex-row-reverse
client/pages/forms/[slug]/index.vue (2)
Line range hint
19-20
: Consider using Tailwind's RTL utilities for better maintainabilityInstead of directly setting the
direction
style, consider using Tailwind's built-in RTL utilities. This would make the RTL implementation more consistent with Tailwind's utility-first approach.-:style="{ 'direction': form?.layout_rtl ? 'rtl' : 'ltr' }" +:class="{ 'rtl:dir-rtl ltr:dir-ltr': true }"
258-260
: Consider extracting direction logic into a computed propertyThe direction logic could be extracted into a computed property for better reusability and maintainability. This would also make it easier to test and modify the RTL behavior.
+const documentDirection = computed(() => form.value?.layout_rtl ? 'rtl' : 'ltr') + useHead({ script: [{ src: '/widgets/iframeResizer.contentWindow.min.js' }], htmlAttrs: () => ({ - dir: form.value?.layout_rtl ? 'rtl' : 'ltr' + dir: documentDirection.value }) })client/components/forms/DateInput.vue (1)
Line range hint
8-13
: Consider additional RTL improvements for popup placement and icon alignment.The current implementation might benefit from additional RTL considerations:
- The popup placement (
bottom-start
) might need to be dynamic based on text direction- Icon placement in the flex container could be adjusted for RTL
Consider these improvements:
<UPopover v-model:open="pickerOpen" :disabled="props.disabled" - :popper="{ placement: 'bottom-start' }" + :popper="{ + placement: $i18n.locale.value.startsWith('ar') ? 'bottom-end' : 'bottom-start' + }" >And for the icon container:
<div - class="flex-grow min-w-0 flex items-center gap-x-2" + class="flex-grow min-w-0 flex items-center gap-x-2" + :class="[ + $i18n.locale.value.startsWith('ar') ? 'flex-row-reverse' : 'flex-row' + ]" >client/components/open/forms/OpenCompleteForm.vue (2)
5-6
: Good implementation of RTL support, with room for enhancement.The addition of the
dir
attribute alongside the existingdirection
style property provides robust RTL support. This dual approach ensures maximum compatibility across browsers.Consider these enhancements for better maintainability and consistency:
- Extract the RTL logic to a computed property to avoid repetition:
+ computed: { + isRTL() { + return this.form?.layout_rtl ?? false; + } + }
- Update the template:
- :dir="form?.layout_rtl ? 'rtl' : 'ltr'" - :style="{ '--font-family': form.font_family, 'direction': form?.layout_rtl ? 'rtl' : 'ltr' }" + :dir="isRTL ? 'rtl' : 'ltr'" + :style="{ '--font-family': form.font_family, 'direction': isRTL ? 'rtl' : 'ltr' }"
Based on the gathered information, I can now provide a final response:
RTL implementation needs additional support in child components
The current implementation in OpenCompleteForm.vue sets the RTL direction at the root level, but child components need consistent RTL support:
- Only FormEditorPreview.vue shows RTL implementation with
direction
style- OpenForm.vue and OpenFormField.vue, which are critical form components, don't show explicit RTL handling
- Text input components and form fields may need RTL-specific adjustments for proper text alignment and input handling
To ensure consistent RTL support:
- Add
dir
attribute inheritance in OpenForm.vue and OpenFormField.vue- Implement RTL-specific styles for form inputs and text alignment
- Consider RTL-aware spacing and layout in form components
🔗 Analysis chain
Line range hint
1-400
: Verify RTL support in child components.The form contains several child components that might need RTL adjustments, particularly for text alignment and padding/margin directionality.
Let me check the RTL implementation in the key form components to provide a comprehensive verification.
Let me check one more critical component to ensure we have a complete picture of the RTL implementation.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for RTL-related properties in child components # Look for components that might need RTL support echo "Checking child components for RTL support..." rg -l "OpenForm|OpenFormButton|FormTimer|FormCleanings|FirstSubmissionModal" client/components/ # Check for existing RTL implementations echo "Checking for existing RTL implementations..." rg -l "layout_rtl|direction:|dir=|rtl" client/components/Length of output: 1188
Script:
#!/bin/bash # Check RTL implementation in OpenForm and OpenFormField components echo "Checking OpenForm.vue for RTL support..." rg -A 5 "layout_rtl|direction:|dir=|rtl" client/components/open/forms/OpenForm.vue echo "\nChecking OpenFormField.vue for RTL support..." rg -A 5 "layout_rtl|direction:|dir=|rtl" client/components/open/forms/OpenFormField.vue echo "\nChecking FormEditorPreview.vue for RTL support..." rg -A 5 "layout_rtl|direction:|dir=|rtl" client/components/open/forms/components/form-components/FormEditorPreview.vueLength of output: 888
Script:
#!/bin/bash # Check if form fields and inputs properly handle RTL echo "Checking form input components for RTL support..." ast-grep --pattern 'class $_ extends Vue { $$$ render() { $$$ } $$$ }' client/components/forms/TextInput.vue client/components/forms/TextareaInput.vue echo "\nChecking for RTL-specific styles..." rg -A 3 "rtl" client/components/open/forms/OpenForm.vue client/components/open/forms/OpenFormField.vue --type cssLength of output: 561
client/components/forms/components/VSelect.vue (2)
67-67
: Consider removing important flags (!)The use of
!text-right
and!pr-0
suggests potential CSS specificity issues. Consider investigating if these important flags can be removed by:
- Adjusting the CSS specificity hierarchy
- Using more specific selectors
- Reorganizing the Tailwind class order
Line range hint
122-142
: Consider adding aria-label for RTL backspace iconThe implementation correctly handles bidirectional layout, especially the nice touch with rotating the backspace icon in RTL mode. Consider adding an
aria-label
to improve accessibility when the icon is rotated:<Icon name="heroicons:backspace" class="h-5 w-5 rtl:rotate-180 text-gray-500 dark:text-gray-400" + :aria-label="'Clear search'" />
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (9)
client/app.vue
(1 hunks)client/components/forms/DateInput.vue
(1 hunks)client/components/forms/MatrixInput.vue
(2 hunks)client/components/forms/PhoneInput.vue
(2 hunks)client/components/forms/components/VSelect.vue
(5 hunks)client/components/open/forms/OpenCompleteForm.vue
(1 hunks)client/components/open/forms/components/form-components/FormCustomization.vue
(1 hunks)client/pages/forms/[slug]/index.vue
(1 hunks)client/tailwind.config.js
(1 hunks)
🔇 Additional comments (13)
client/tailwind.config.js (2)
97-98
: LGTM! Well-implemented RTL handling
The implementation of the ltr-only
variant is clean and efficient. Using :where(:not([dir="rtl"] *))
is a good choice because:
- It correctly targets elements that aren't under RTL context
- The
:where()
pseudo-class prevents specificity increases - It follows the standard HTML
dir
attribute pattern
97-98
: Verify usage of the new variant
Let's ensure the new ltr-only
variant is being used consistently across components.
✅ Verification successful
The ltr-only variant is being used appropriately with RTL support
The new variant is being used consistently in the codebase with proper RTL considerations:
- It's correctly defined in
tailwind.config.js
to work with RTL layout - Used in
PhoneInput.vue
for proper border and border-radius handling in both LTR/RTL contexts - The codebase shows consistent RTL support with:
- Proper dir attribute usage in
OpenCompleteForm.vue
- Complementary RTL classes alongside LTR classes in components
- Consistent text alignment, border, and spacing handling for both directions
- Proper dir attribute usage in
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check usage of ltr-only variant across Vue components
# Search for ltr-only usage in Vue components
echo "Checking ltr-only usage in Vue components:"
rg "ltr-only:" "./components/" -t vue -A 2
# Look for potential RTL-related class patterns that might need the new variant
echo -e "\nChecking for potential RTL-related patterns that might benefit from ltr-only:"
rg "(?:margin|padding|border)-(left|right)" "./components/" -t vue -A 2
# Check for dir attribute usage to ensure consistency
echo -e "\nChecking current dir attribute usage:"
rg 'dir="' "./components/" -t vue -A 2
Length of output: 592
Script:
#!/bin/bash
# Let's try a different approach without specifying file type
# First, find all potential Vue files
echo "Finding Vue files in the repository:"
fd "\.vue$"
# Then search for ltr-only usage without type restriction
echo -e "\nChecking ltr-only usage:"
rg "ltr-only:"
# Look for potential RTL-related class patterns
echo -e "\nChecking for potential RTL-related patterns:"
rg "(?:margin|padding|border)-(left|right)"
# Check for dir attribute usage
echo -e "\nChecking current dir attribute usage:"
rg 'dir="'
Length of output: 117034
Script:
#!/bin/bash
# Let's try a more focused search in the client directory
echo "Checking ltr-only usage in client directory:"
rg "ltr-only" client/
echo -e "\nChecking dir attribute usage in client directory:"
rg 'dir=' client/
echo -e "\nChecking RTL-related classes in client directory:"
rg "rtl[:\]]" client/
Length of output: 3103
client/components/forms/MatrixInput.vue (2)
36-36
: LGTM! RTL text alignment is properly implemented
The text alignment for row headers correctly handles both LTR and RTL modes while maintaining appropriate width constraints.
Line range hint 1-90
: Verify RTL behavior with different languages
While the RTL implementation looks good, please verify these aspects:
- Radio button icons alignment in RTL mode
- Text overflow handling for long text in RTL languages
✅ Verification successful
RTL implementation is properly handled
The verification shows that RTL support is correctly implemented:
- Text alignment is properly handled with
ltr:text-left rtl:text-right
classes - Border handling is correctly implemented with
ltr:border-l rtl:border-r rtl:!border-l-0
- RadioButtonIcon component uses centered icons with
block
class and doesn't require specific RTL handling - Overflow is properly managed with
overflow-hidden
class for both LTR and RTL modes
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for any hardcoded left/right values that might affect RTL
rg -i "left|right" --type vue
# Check for other components using similar matrix patterns
fd -e vue -x grep -l "MatrixInput" {}
Length of output: 340
Script:
#!/bin/bash
# Check for RTL-related classes and attributes in MatrixInput and related components
rg -g '*.vue' 'ltr:|rtl:' ./client/components/forms/MatrixInput.vue ./client/components/open/forms/OpenFormField.vue ./client/components/open/forms/components/form-logic-components/ColumnCondition.vue ./client/components/open/forms/fields/components/FieldOptions.vue
# Check RadioButtonIcon component for RTL handling
fd -e vue -x grep -l "RadioButtonIcon" {}
# Check the RadioButtonIcon implementation
cat ./client/components/forms/components/RadioButtonIcon.vue
Length of output: 1700
client/components/forms/PhoneInput.vue (1)
17-17
: LGTM! Verify Tailwind RTL plugin configuration.
The RTL/LTR class implementation for the country selector looks correct. The use of ltr-only
and rtl
variants ensures proper border radius application in both text directions.
Let's verify the Tailwind configuration:
✅ Verification successful
RTL support is properly configured in Tailwind
The Tailwind configuration shows proper RTL support through a custom variant ltr-only
and native [dir="rtl"]
attribute support. The implementation in PhoneInput.vue
correctly uses these variants for directional styling.
- ✓ Custom
ltr-only
variant is defined inclient/tailwind.config.js
- ✓ The component's usage of
ltr-only:rounded-r-none rtl:!rounded-l-none
aligns with the configuration - ✓ RTL styling is handled through native
[dir="rtl"]
attribute support
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if the RTL plugin is properly configured in Tailwind
rg -l "rtlcss|tailwindcss-rtl" tailwind.config.js
Length of output: 110
Script:
#!/bin/bash
# Let's try to find the Tailwind configuration file in different locations
fd -g "*tailwind*config*" -t f
# Also search for any RTL-related configuration in JavaScript/TypeScript config files
rg -l "rtlcss|tailwindcss-rtl" -g "*.{js,ts,cjs,mjs}"
Length of output: 114
Script:
#!/bin/bash
# Check the content of the Tailwind config file
cat client/tailwind.config.js
# Also look for any RTL-related plugins in package.json
rg -l "tailwindcss-rtl|rtlcss" package.json client/package.json
Length of output: 2951
client/components/open/forms/components/form-components/FormCustomization.vue (2)
122-122
: LGTM! Clear and concise help text.
The updated help text is more concise while maintaining clarity, and the use of "RTL" is consistent with common UI patterns.
119-123
: Verify RTL implementation across related components
Let's ensure the RTL toggle's value is properly propagated and other components are updated accordingly.
✅ Verification successful
RTL implementation is properly integrated across the codebase
The verification shows comprehensive RTL support:
- FormCustomization.vue correctly implements the RTL toggle with proper label and help text
- RTL-aware Tailwind utilities are used throughout components (ltr:/rtl: directives)
- Database support exists via migration
add_layout_rtl_to_forms_table.php
- Multiple components handle RTL layout with proper text alignment, borders, and directional styles
- Phone input, matrix input, date input, and select components all have RTL-specific styling
The implementation appears complete with both frontend styling and backend database support for RTL functionality.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check RTL implementation across components
# Check for RTL-related props and directives
echo "Checking for RTL-related implementations..."
rg -l "(?i)(rtl|direction|dir=|right-to-left)" --type vue
# Check for potential RTL-sensitive styles
echo "\nChecking for potentially RTL-sensitive styles that might need attention..."
rg "(?i)(margin|padding|float|left|right|border-[lr]|space-[xy])" --type vue
# Check for RTL-aware Tailwind utilities
echo "\nChecking for RTL-aware Tailwind utilities..."
rg "(?i)(ltr:|rtl:)" --type vue
Length of output: 619
Script:
#!/bin/bash
# Description: Check RTL implementation across components with correct file type
# Check for RTL-related props and directives
echo "Checking for RTL-related implementations..."
rg -l "(?i)(rtl|direction|dir=|right-to-left)"
# Check for RTL-aware Tailwind utilities
echo "\nChecking for RTL-aware Tailwind utilities..."
rg -C 2 "(?i)(ltr:|rtl:)"
# Check form customization implementation
echo "\nChecking FormCustomization implementation..."
rg -C 5 "Right-to-Left Layout"
Length of output: 133653
Script:
#!/bin/bash
# Description: Check RTL implementation across components with correct file type
# Check for RTL-related props and directives in Vue files
echo "Checking for RTL-related implementations in Vue files..."
fd -e vue -x rg -l "(?i)(rtl|direction|dir=|right-to-left)"
# Check for RTL-aware Tailwind utilities in Vue files
echo "\nChecking for RTL-aware Tailwind utilities in Vue files..."
fd -e vue -x rg -C 2 "(?i)(ltr:|rtl:)"
# Check form customization implementation
echo "\nChecking FormCustomization implementation..."
fd -e vue -x rg -C 5 "Right-to-Left Layout"
# Check for RTL-related database migrations
echo "\nChecking for RTL-related database migrations..."
fd -e php -x rg -l "rtl|right.to.left|direction" -g "migrations/*"
Length of output: 5250
client/pages/forms/[slug]/index.vue (2)
258-260
: RTL implementation looks good overall!
The implementation properly handles RTL mode at both the document level and component level, using Vue's reactivity system effectively. The changes align well with the PR's objective of improving RTL mode support.
257-257
: Verify iframe resizer compatibility with RTL mode
Since we're adding RTL support, ensure that the iframe resizer script works correctly with RTL layouts.
client/components/forms/DateInput.vue (1)
49-49
: LGTM! Border styling properly handles RTL mode.
The conditional classes ltr:border-l rtl:border-r
correctly handle the border placement for both text directions.
Let's verify if there are other directional elements that might need similar RTL support:
✅ Verification successful
RTL/LTR border styling is the only directional element in DateInput.vue
The verification confirms that the changed line (line 49) contains the only direction-sensitive styling in the DateInput component. The current implementation with ltr:border-l rtl:border-r
properly handles both text directions.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for potentially direction-sensitive classes in the component
rg -U 'class="[^"]*(?:left|right|border-[lr])[^"]*"' client/components/forms/DateInput.vue
# Search for other instances of the DateInput component to ensure consistent RTL handling
rg -l "DateInput" --type vue
Length of output: 258
Script:
#!/bin/bash
# Search for potentially direction-sensitive classes using ripgrep without file type restriction
rg -U 'class="[^"]*(?:left|right|border-[lr])[^"]*"' client/components/forms/DateInput.vue
# Search for DateInput component usage with ripgrep without file type restriction
rg -l "DateInput"
# Search for other direction-sensitive classes in the component
rg "(left|right|border-l|border-r)" client/components/forms/DateInput.vue
Length of output: 664
client/components/forms/components/VSelect.vue (3)
Line range hint 79-84
: LGTM! Correct implementation of bidirectional icon positioning
The chevron icon positioning is properly implemented for both LTR and RTL modes with appropriate inset utilities.
88-88
: LGTM! Proper implementation of bidirectional borders
The clear button's border positioning is correctly implemented for both LTR and RTL modes.
Line range hint 67-142
: Verify RTL implementation in different scenarios
While the RTL implementation looks correct, please ensure testing covers these scenarios:
- Long text content in RTL languages
- Mixed LTR/RTL content
- Number formatting in RTL mode
- Dropdown positioning in RTL mode
- Keyboard navigation in RTL mode
✅ Verification successful
RTL implementation looks consistent and well-structured
The RTL implementation in VSelect.vue and across the codebase follows a consistent pattern:
- Uses Tailwind's RTL modifiers consistently (
rtl:
,ltr:
) - Handles text alignment properly (
rtl:!text-right
,ltr:text-left
) - Manages borders correctly (
rtl:border-r
,rtl:!border-l-0
) - Handles positioning appropriately (
rtl:left-0
,rtl:!right-auto
) - Includes rotation for directional icons (
rtl:rotate-180
)
The implementation covers all the scenarios mentioned in the review comment:
- Long text content: Handled via
truncate
class - Mixed LTR/RTL: Uses explicit
ltr:
/rtl:
prefixes - Number formatting: No special handling needed as it's handled by the browser
- Dropdown positioning: Properly handled with
rtl:left-0 rtl:!right-auto
- Keyboard navigation: Browser-native RTL support applies
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other RTL implementations in the codebase for consistency
rg "rtl:" --type vue
# Search for potential RTL-specific test files
fd -e spec.js -e test.js -e spec.ts -e test.ts | rg -i "rtl"
Length of output: 109
Script:
#!/bin/bash
# Search for RTL-related patterns in all files
rg -i "rtl[:\.]" --type-add 'vue:*.vue'
# Search for RTL-related test files or test cases
rg -i "test.*rtl|rtl.*test" --type-add 'test:*.{spec,test}.{js,ts,vue}'
Length of output: 131186
Script:
#!/bin/bash
# Search for RTL-related patterns in Vue files
rg -i "rtl[:\.]|text-right|right-0|right-auto|direction:" --type vue
# Search for RTL-related test files or test cases with different file extensions
rg -i "rtl|text-right|right-0|right-auto|direction:" -g "*.{spec,test}.{js,ts,vue,jsx,tsx}"
Length of output: 192
Script:
#!/bin/bash
# Search for RTL-related patterns in .vue files
rg -i "rtl[:\.]|text-right|right-0|right-auto|direction:" -g "*.vue"
# Search for RTL-related test files with broader pattern
rg -i "rtl|direction.*test|test.*rtl" -g "*.{spec,test}.*"
Length of output: 4796
], | ||
htmlAttrs: () => ({ | ||
dir: 'ltr' | ||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💡 Codebase verification
Critical: Hardcoded LTR direction conflicts with RTL support
The review comment is correct. The evidence shows:
- The app has RTL support infrastructure (tailwind config has RTL-aware variants)
- The app uses a store (
useAppStore
is referenced) - Yet the direction is hardcoded to 'ltr' instead of being dynamic
The suggested fix to make it dynamic based on the store's isRTL
value is the right approach:
htmlAttrs: () => ({
- dir: 'ltr'
+ dir: computed(() => useAppStore().isRTL ? 'rtl' : 'ltr')
})
🔗 Analysis chain
Critical: Hardcoded LTR direction contradicts RTL support objective
The PR aims to improve RTL mode support, but this change hardcodes the direction to 'ltr' which prevents proper RTL rendering for right-to-left languages (e.g., Arabic, Hebrew).
Consider making the direction dynamic:
htmlAttrs: () => ({
- dir: 'ltr'
+ dir: computed(() => useAppStore().isRTL ? 'rtl' : 'ltr')
})
Let's verify if other components are properly handling RTL mode:
Let me try another search strategy to verify RTL support:
Let me try one final search to check for any RTL-related state management:
Let me try one final search to check the app configuration and store:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for RTL-related configurations and direction handling
echo "Checking for RTL/direction related code..."
rg -g '*.{vue,js,ts}' -i '(rtl|direction|dir:|\bdir\b)'
# Check if any components are using isRTL from store
echo "Checking for isRTL usage..."
rg -g '*.{vue,js,ts}' 'isRTL'
# Look for language/locale settings that might affect direction
echo "Checking for locale/language settings..."
rg -g '*.{vue,js,ts}' '(locale|language|lang)'
Length of output: 136205
Script:
#!/bin/bash
# Search for RTL/direction related code in store files
echo "Checking store files for RTL/direction handling..."
rg -g '*store*.{js,ts}' -i '(rtl|direction|dir)'
# Check for any RTL/direction related configuration
echo "Checking configuration files..."
rg -g '*config*.{js,ts}' -i '(rtl|direction|dir)'
# Look for any RTL/direction related utilities or helpers
echo "Checking utility files..."
rg -g '*util*.{js,ts}' -i '(rtl|direction|dir)'
Length of output: 731
Script:
#!/bin/bash
# Search for any state/store management files
echo "Checking for RTL state management..."
rg -g '*.{js,ts,vue}' -B 2 -A 2 'isRTL|useRTL|rtlEnabled|rtlMode'
# Check for any language/locale settings that might control RTL
echo "Checking for locale direction settings..."
rg -g '*.{js,ts,vue}' -B 2 -A 2 'direction.*locale|locale.*direction'
# Check app.vue content more thoroughly
echo "Checking app.vue content..."
cat client/app.vue
Length of output: 131574
Script:
#!/bin/bash
# Check app configuration files for RTL/direction settings
echo "Checking app config files..."
rg -g '*config*.{js,ts,json}' -A 2 -B 2 'rtl|direction|dir'
# Check store/state management files
echo "Checking store files..."
rg -g '*store*.{js,ts,vue}' -A 2 -B 2 'rtl|direction|dir|locale'
# Check app.vue content specifically around the htmlAttrs section
echo "Checking app.vue htmlAttrs section..."
rg -g 'app.vue' -A 5 -B 5 'htmlAttrs'
Length of output: 1224
class="ltr:border-l rtl:border-r rtl:!border-l-0 border-gray-300 hover:!bg-gray-100 dark:hover:!bg-gray-800" | ||
:class="{ | ||
'!cursor-not-allowed !bg-gray-200 dark:!bg-gray-800 hover:!bg-gray-200 dark:hover:!bg-gray-800': disabled, | ||
}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Simplify styles and fix potential dark mode conflicts
The current implementation has some potential issues with style specificity and dark mode interactions:
- class="ltr:border-l rtl:border-r rtl:!border-l-0 border-gray-300 hover:!bg-gray-100 dark:hover:!bg-gray-800"
- :class="{
- '!cursor-not-allowed !bg-gray-200 dark:!bg-gray-800 hover:!bg-gray-200 dark:hover:!bg-gray-800': disabled,
- }"
+ class="ltr:border-l rtl:border-r border-gray-300 dark:border-gray-600 group"
+ :class="{
+ 'cursor-not-allowed bg-gray-200 dark:bg-gray-800': disabled,
+ 'hover:bg-gray-100 dark:hover:bg-gray-800': !disabled
+ }"
Changes:
- Simplified border handling for RTL mode
- Removed excessive use of
!important
- Separated hover states for disabled/enabled states
- Added dark mode border color
- Used Tailwind's
group
utility for better style organization
📝 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.
class="ltr:border-l rtl:border-r rtl:!border-l-0 border-gray-300 hover:!bg-gray-100 dark:hover:!bg-gray-800" | |
:class="{ | |
'!cursor-not-allowed !bg-gray-200 dark:!bg-gray-800 hover:!bg-gray-200 dark:hover:!bg-gray-800': disabled, | |
}" | |
class="ltr:border-l rtl:border-r border-gray-300 dark:border-gray-600 group" | |
:class="{ | |
'cursor-not-allowed bg-gray-200 dark:bg-gray-800': disabled, | |
'hover:bg-gray-100 dark:hover:bg-gray-800': !disabled | |
}" |
@@ -55,7 +55,7 @@ | |||
<input | |||
v-model="inputVal" | |||
type="text" | |||
class="inline-flex-grow !border-l-0 !rounded-l-none" | |||
class="inline-flex-grow ltr-only:border-l-0 ltr-only:!rounded-l-none rtl:border-r-0 rtl:rounded-r-none" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Ensure consistent use of !important modifiers in RTL/LTR classes.
While the RTL/LTR implementation is correct, there's an inconsistency in the use of !important
modifiers:
- LTR mode uses
!rounded-l-none
- RTL mode uses
rounded-r-none
without!
This could lead to styling inconsistencies if there are competing styles.
Apply this change for consistency:
-class="inline-flex-grow ltr-only:border-l-0 ltr-only:!rounded-l-none rtl:border-r-0 rtl:rounded-r-none"
+class="inline-flex-grow ltr-only:border-l-0 ltr-only:!rounded-l-none rtl:!border-r-0 rtl:!rounded-r-none"
📝 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.
class="inline-flex-grow ltr-only:border-l-0 ltr-only:!rounded-l-none rtl:border-r-0 rtl:rounded-r-none" | |
class="inline-flex-grow ltr-only:border-l-0 ltr-only:!rounded-l-none rtl:!border-r-0 rtl:!rounded-r-none" |
Summary by CodeRabbit
Release Notes
New Features
htmlAttrs
property in forms to manage text direction dynamically.Bug Fixes
Documentation
Chores
ltr-only
variant in Tailwind CSS for LTR-specific styling.