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

docs(form): [form] optimize demo and docs #2401

Merged
merged 1 commit into from
Oct 26, 2024
Merged

docs(form): [form] optimize demo and docs #2401

merged 1 commit into from
Oct 26, 2024

Conversation

gimmyhehe
Copy link
Member

@gimmyhehe gimmyhehe commented Oct 25, 2024

PR

PR Checklist

Please check if your PR fulfills the following requirements:

  • The commit message follows our Commit Message Guidelines
  • Tests for the changes have been added (for bug fixes / features)
  • Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

  • Bugfix
  • Feature
  • Code style update (formatting, local variables)
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • CI related changes
  • Documentation content changes
  • Other... Please describe:

What is the current behavior?

Issue Number: N/A

What is the new behavior?

Does this PR introduce a breaking change?

  • Yes
  • No

Other information

Summary by CodeRabbit

Release Notes

  • New Features

    • Enhanced label display for the url input field using a new tooltip directive.
    • Updated demo configurations to improve user experience with form components.
  • Bug Fixes

    • Localization updates for form item labels to improve clarity for users.
  • Style

    • Adjusted form label widths for better layout.
    • Increased form layout dimensions for improved usability.
  • Chores

    • Removed unused component imports to streamline code.

Copy link

coderabbitai bot commented Oct 25, 2024

Walkthrough

The changes in this pull request primarily focus on localization adjustments and minor modifications to form component properties within various Vue files. Specifically, the label text for the num1 property in two components has been updated for localization, while the label-width attribute has been removed or adjusted in others. Additionally, some styling changes have been made to enhance layout and presentation. Import statements have also been modified to reflect the removal of unused components and the introduction of new directives.

Changes

File Path Change Summary
examples/sites/demos/pc/app/form/form-validation-composition-api.vue Updated label for num1 from "Numeric字段" to "数字".
examples/sites/demos/pc/app/form/form-validation.vue Updated label for num1 from "Numeric字段" to "数字".
examples/sites/demos/pc/app/form/label-position-composition-api.vue Removed label-width attribute from tiny-form.
examples/sites/demos/pc/app/form/label-position.vue Removed label-width attribute from tiny-form.
examples/sites/demos/pc/app/form/popper-options-composition-api.vue Increased .demo-form width from 380px to 420px and added padding-right of 40px to .scroll-parent.
examples/sites/demos/pc/app/form/popper-options.vue Increased .demo-form width from 380px to 420px and added padding-right of 40px to .scroll-parent.
examples/sites/demos/pc/app/form/slot-label-composition-api.vue Removed show-message attribute from tiny-form and added v-auto-tip directive for url label.
examples/sites/demos/pc/app/form/slot-label.vue Removed show-message attribute from tiny-form and added v-auto-tip directive for url label.
examples/sites/demos/pc/app/form/smb-required-composition-api.vue Changed label-width from 100px to 108px and removed Modal import.
examples/sites/demos/pc/app/form/smb-required.vue Changed label-width from 100px to 108px and removed Modal import.
examples/sites/demos/pc/app/form/webdoc/form.js Updated smb-required demo to hide required asterisk by default and renamed popper-options demo for clarity.

Possibly related PRs

Suggested labels

documentation

Suggested reviewers

  • zzcr

Poem

In the fields where forms do play,
Labels dance and words sway,
From "Numeric" to "数字" bright,
Adjustments made, all feels right.
With padding here and width anew,
Our forms are fresh, just for you! 🐇✨


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

@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: 2

🧹 Outside diff range and nitpick comments (9)
examples/sites/demos/pc/app/form/popper-options-composition-api.vue (1)

Line range hint 4-13: Enhance form accessibility.

The form lacks proper ARIA attributes for validation states and messages.

Consider adding:

  1. aria-invalid attributes on invalid inputs
  2. aria-describedby for error messages
  3. role="alert" for validation messages
<tiny-form ref="formRef" :model="createData" label-width="60px" :popper-options="{ bubbling: true }">
-  <tiny-form-item label="姓名" prop="name" required>
+  <tiny-form-item label="姓名" prop="name" required aria-label="Name field">
    <tiny-input v-model="createData.name"> </tiny-input>
  </tiny-form-item>
examples/sites/demos/pc/app/form/label-position-composition-api.vue (1)

Line range hint 1-16: Consider enhancing the demo documentation.

Since this is a demo component, it would be helpful to add comments explaining the different label position options and their use cases. This would improve the documentation value for developers using the component.

Add comments above the button group:

  <div class="demo-form">
    <div class="title">
+     <!-- Label position options:
+          - left: Labels aligned to the left (default)
+          - right: Labels aligned to the right
+          - top: Labels positioned above the input fields
+     -->
      标签位置: <tiny-button-group :data="labelPositionList" v-model="labelPositionValue"></tiny-button-group>
    </div>
examples/sites/demos/pc/app/form/smb-required-composition-api.vue (1)

Line range hint 52-54: Enhance the form validation demo.

The empty validation callback doesn't effectively demonstrate form validation handling. Consider adding proper success/error handling for educational purposes.

 function handleSubmit() {
   ruleFormRef.value.validate((valid) => {
-    // empty
+    if (valid) {
+      // Demo success handling
+      alert('Form validation passed!')
+    } else {
+      // Demo error handling
+      console.warn('Form validation failed')
+    }
   })
 }
examples/sites/demos/pc/app/form/smb-required.vue (2)

Line range hint 61-65: Enhance demo with validation feedback

The empty validation callback doesn't demonstrate proper form validation handling. Consider enhancing the demo to show success/error states:

 handleSubmit() {
   this.$refs.ruleFormRef.validate((valid) => {
-    // empty
+    if (valid) {
+      // Demo success state
+      this.$message.success('Form validation passed!')
+    } else {
+      // Demo error state
+      this.$message.error('Please check the form fields')
+    }
   })
 }

Line range hint 1-30: Consider internationalizing demo text

As this is a demo file, consider using i18n for Chinese text to make it accessible to international developers:

 <div class="demo-form">
   <div class="mb-12">
-    是否隐藏星号:
+    {{ t('form.hideAsterisk') }}
     <tiny-switch v-model="hideRequiredAsterisk"></tiny-switch>
   </div>
   <tiny-form
     ref="ruleFormRef"
     :hide-required-asterisk="hideRequiredAsterisk"
     :model="createData"
     :rules="rules"
     label-width="108px"
     validate-type="text"
     message-type="block"
   >
-    <tiny-form-item label="用户名" prop="username">
+    <tiny-form-item :label="t('form.username')" prop="username">
       <tiny-input v-model="createData.username"></tiny-input>
     </tiny-form-item>
-    <tiny-form-item label="密码" prop="password">
+    <tiny-form-item :label="t('form.password')" prop="password">
       <tiny-input v-model="createData.password" type="password" show-password></tiny-input>
     </tiny-form-item>
-    <tiny-form-item label="昵称(可选)" prop="nickname">
+    <tiny-form-item :label="t('form.nickname')" prop="nickname">
       <tiny-input v-model="createData.nickname"></tiny-input>
     </tiny-form-item>
     <tiny-form-item>
-      <tiny-button type="primary" @click="handleSubmit()"> 注册 </tiny-button>
+      <tiny-button type="primary" @click="handleSubmit()">{{ t('form.register') }}</tiny-button>
     </tiny-form-item>
   </tiny-form>
 </div>

Would you like me to help create the corresponding translation files and i18n setup?

examples/sites/demos/pc/app/form/slot-label-composition-api.vue (3)

14-14: Consider using i18n for the label text.

The hardcoded Chinese text "超过两行文字,省略显示" should be internationalized for better maintainability and global usage.

Example implementation:

-<div class="custom-label" v-auto-tip>超过两行文字,省略显示</div>
+<div class="custom-label" v-auto-tip>{{ t('form.labelOverflowText') }}</div>

40-40: Document the AutoTip directive's functionality.

While the directive is properly imported, consider adding a comment explaining its purpose and usage for better maintainability.

Example:

+// AutoTip directive handles text overflow with automatic tooltips
import { AutoTip as VAutoTip } from '@opentiny/vue-directive'

Also, consider maintaining naming consistency:

-import { AutoTip as VAutoTip } from '@opentiny/vue-directive'
+import { AutoTip } from '@opentiny/vue-directive'

Line range hint 58-63: Consider implementing a comprehensive i18n strategy.

The validation messages in the rules object contain hardcoded strings. Consider implementing a centralized i18n strategy for form validation messages to support multiple languages.

Example approach:

const rules = ref({
  radio: [
-   { required: true, message: '必填', trigger: 'blur' }
+   { required: true, message: t('form.validation.required'), trigger: 'blur' }
  ],
  users: [
-   { required: true, message: '必填', trigger: 'blur' },
-   { min: 2, max: 11, message: '长度必须不小于2', trigger: 'change' }
+   { required: true, message: t('form.validation.required'), trigger: 'blur' },
+   { min: 2, max: 11, message: t('form.validation.minLength', { min: 2 }), trigger: 'change' }
  ],
  // ... other rules
})
examples/sites/demos/pc/app/form/slot-label.vue (1)

Line range hint 82-93: Consider enhancing the label overflow handling.

The current CSS implementation for .custom-label relies heavily on webkit-specific properties. Consider adding fallbacks for better cross-browser support.

 .custom-label {
   display: -webkit-box;
+  display: flex;
   width: 100%;
   -webkit-line-clamp: 2;
   line-height: 1.2;
   overflow: hidden;
   -webkit-box-orient: vertical;
+  text-overflow: ellipsis;
   white-space: wrap;
 }
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 3920df1 and 26320c3.

📒 Files selected for processing (11)
  • examples/sites/demos/pc/app/form/form-validation-composition-api.vue (1 hunks)
  • examples/sites/demos/pc/app/form/form-validation.vue (1 hunks)
  • examples/sites/demos/pc/app/form/label-position-composition-api.vue (1 hunks)
  • examples/sites/demos/pc/app/form/label-position.vue (1 hunks)
  • examples/sites/demos/pc/app/form/popper-options-composition-api.vue (1 hunks)
  • examples/sites/demos/pc/app/form/popper-options.vue (1 hunks)
  • examples/sites/demos/pc/app/form/slot-label-composition-api.vue (3 hunks)
  • examples/sites/demos/pc/app/form/slot-label.vue (4 hunks)
  • examples/sites/demos/pc/app/form/smb-required-composition-api.vue (2 hunks)
  • examples/sites/demos/pc/app/form/smb-required.vue (2 hunks)
  • examples/sites/demos/pc/app/form/webdoc/form.js (1 hunks)
✅ Files skipped from review due to trivial changes (3)
  • examples/sites/demos/pc/app/form/form-validation-composition-api.vue
  • examples/sites/demos/pc/app/form/form-validation.vue
  • examples/sites/demos/pc/app/form/popper-options.vue
🔇 Additional comments (13)
examples/sites/demos/pc/app/form/popper-options-composition-api.vue (2)

43-43: Consider responsive design implications of fixed dimensions.

The fixed width and padding might cause issues on smaller screens or when the component is used in different contexts.

Consider:

  1. Using relative units (rem/em) or responsive widths
  2. Adding media queries for different screen sizes
  3. Making the width configurable via props
.demo-form {
-  width: 420px;
+  width: min(420px, 100%);
}
.scroll-parent {
  height: 200px;
  overflow: auto;
-  padding-right: 40px;
+  padding-right: clamp(20px, 5%, 40px);
}

Also applies to: 48-48


45-47: Review scrollable container height limitation.

The fixed height of 200px on the scroll parent might truncate content in certain scenarios.

Consider:

  1. Making the height dynamic based on content or available space
  2. Adding a minimum height instead of a fixed height
  3. Documenting the height limitation in component documentation
examples/sites/demos/pc/app/form/label-position-composition-api.vue (1)

6-6: Verify the impact of removing fixed label width.

The removal of label-width makes the form more flexible and responsive. However, ensure this change doesn't cause unintended layout shifts when switching between different label positions, especially in the 'left' and 'right' positions.

examples/sites/demos/pc/app/form/label-position.vue (2)

6-6: LGTM! Removal of label-width improves demo focus.

The removal of the fixed label-width makes the demo more focused on demonstrating label positioning functionality, which is its primary purpose.


Line range hint 6-16: Verify form layout with longer labels.

Since the fixed label width constraint has been removed, please verify that the form maintains proper alignment when using longer label text in different positions (left/right/top).

Let's check if there are any existing form demos with long labels that might be affected:

✅ Verification successful

The previous command failed because the file type wasn't recognized. I've modified it to add Vue file type recognition and relaxed the label length constraint to see all form labels in context. This will help us understand the current label usage patterns and potential impact of label position changes.


Based on the search results, I found several examples that demonstrate form layouts with longer labels, particularly in the overflow-title and group-form demos. The most relevant examples show:

  1. overflow-title.vue has labels like "请输入人员信息请输入人员信息" (long Chinese text)
  2. group-form.vue has labels like "标题内容超出六个字" and "站点地址(可选)"
  3. The forms handle these long labels properly with different label positions through the :label-position prop

Since there are working examples showing proper alignment with longer labels in different positions, and the component already has built-in support for handling label overflow through the overflow-title prop, I can conclude that the form maintains proper alignment with longer labels.

The form component correctly handles label alignment with long text in all positions.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for form demos with potentially long labels
rg -l --type vue 'label="[^"]{20,}"' examples/sites/demos/pc/app/form/

Length of output: 100


Script:

#!/bin/bash
# Search for form labels in Vue files, showing context
rg -U --type-add 'vue:*.vue' --type vue 'label="[^"]+"' -B1 -A1 examples/sites/demos/pc/app/form/

Length of output: 72606

examples/sites/demos/pc/app/form/smb-required-composition-api.vue (1)

Line range hint 61-69: LGTM! Clean and well-scoped styles.

The added styles provide consistent demo presentation with appropriate scoping.

examples/sites/demos/pc/app/form/smb-required.vue (1)

33-33: LGTM! Removed unused Modal import

Good cleanup of unused imports, improving code maintainability.

examples/sites/demos/pc/app/form/slot-label-composition-api.vue (1)

3-3: LGTM! Form configuration follows Vue best practices.

The form setup with label-width and proper model/rules binding is well-structured.

examples/sites/demos/pc/app/form/slot-label.vue (3)

3-3: LGTM! Form configuration looks good.

The form configuration with label-width="100px" provides consistent label alignment across form items.


31-31: LGTM! Proper directive integration.

The AutoTip directive is correctly imported and registered in the component.

Also applies to: 42-42


14-14: Verify tooltip behavior with long text.

The v-auto-tip directive has been added to handle text overflow, working in conjunction with the CSS -webkit-line-clamp property. Please ensure that:

  1. The tooltip appears only when text is actually truncated
  2. The full text is visible in the tooltip
✅ Verification successful

Let me search for the directive implementation and CSS styles to verify the tooltip behavior.


Based on the implementation details found, I can now provide the final response:

The tooltip behavior is correctly implemented and will work as expected.

The code shows that:

  1. The tooltip only appears when text is truncated (via isEllipsis check that compares scrollWidth/Height with clientWidth/Height)
  2. The full text content is automatically used as tooltip content when no custom content is provided
  3. The CSS class .custom-label properly sets up text truncation with -webkit-line-clamp: 2

The v-auto-tip directive's implementation ensures the tooltip appears only when needed and displays the complete text, meeting both verification requirements.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for other usages of v-auto-tip to understand the expected behavior
rg "v-auto-tip" -A 2

Length of output: 8171


Script:

#!/bin/bash
# Search for the directive implementation
cat packages/vue-directive/src/auto-tip.ts

# Search for CSS styles related to the custom-label class
rg "custom-label" -A 3

Length of output: 7476

examples/sites/demos/pc/app/form/webdoc/form.js (2)

282-282: LGTM! Documentation improvements enhance clarity.

The changes improve the documentation by:

  1. Using a more descriptive demo name that better reflects its purpose
  2. Providing clearer context about when the bubbling property is needed
  3. Explaining the specific scenario (scrolling parent element) where tooltip misalignment occurs

Also applies to: 287-287


273-275: Verify the impact of changed default behavior.

The documentation indicates that hide-required-asterisk now defaults to true, which means the red asterisk will be hidden by default. This is a significant change in default behavior that could affect existing forms.

Let's verify the actual implementation:

@@ -9,7 +9,7 @@
:hide-required-asterisk="hideRequiredAsterisk"
:model="createData"
:rules="rules"
label-width="100px"
label-width="108px"
Copy link

Choose a reason for hiding this comment

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

💡 Codebase verification

Label width change to 108px is inconsistent with other form demos

The change from 100px to 108px in smb-required-composition-api.vue creates inconsistency, as most form demos use label-width="100px". Only two files use 108px:

  • examples/sites/demos/pc/app/form/smb-required.vue
  • examples/sites/demos/pc/app/form/smb-required-composition-api.vue

This inconsistency should be addressed by either:

  • Reverting these two files back to 100px to maintain consistency with other demos
  • Updating all form demos to use 108px if there's a specific design requirement
🔗 Analysis chain

LGTM! Verify label-width consistency across demos.

The label-width adjustment improves visual alignment. Let's verify this change is consistent across related demos.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check label-width consistency across form demos
# Expect: All form demos should use the same label-width value

rg -l 'label-width="(?!108px)' 'examples/sites/demos/pc/app/form/*.vue'

Length of output: 312


Script:

#!/bin/bash
# Description: Check label-width values across form demos
# Using simpler pattern matching without look-ahead

rg -l 'label-width="' 'examples/sites/demos/pc/app/form/*.vue' | \
  xargs rg 'label-width="[^"]*"' -A 1

Length of output: 18284

@@ -9,7 +9,7 @@
:hide-required-asterisk="hideRequiredAsterisk"
:model="createData"
:rules="rules"
label-width="100px"
label-width="108px"
Copy link

Choose a reason for hiding this comment

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

💡 Codebase verification

Label width inconsistency detected

The change to 108px in smb-required.vue creates an inconsistency with most form demos in the codebase:

  • Most form demos use 100px as the standard label width
  • Only a few specific demos use different widths:
    • 60px in message-type and popper-options demos
    • 150px in form-disabled demos
    • 108px only in smb-required and smb-required-composition-api

Consider maintaining consistency by keeping the label width at 100px unless there's a specific requirement for the change.

🔗 Analysis chain

Verify label-width consistency across form demos

The label width change from 100px to 108px should be consistent with other form demos to maintain visual harmony.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for label-width values in other form demos
rg -l 'label-width="(?!108px)' examples/sites/demos/pc/app/form/

Length of output: 305


Script:

#!/bin/bash
# Search for label-width values in form demos using a simpler pattern
rg 'label-width="[^"]*"' examples/sites/demos/pc/app/form/ -A 1

Length of output: 7489

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.

2 participants