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

feat(date-picker): [date-picker] Adapting to the SMB themem #2205

Merged
merged 1 commit into from
Sep 30, 2024

Conversation

Youyou-smiles
Copy link
Collaborator

@Youyou-smiles Youyou-smiles commented Sep 29, 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

    • Introduced a new DatePanel component to enhance date selection functionality.
  • Improvements

    • Streamlined date picker components by removing unnecessary range-separator attributes and fixed widths for a cleaner user interface.
    • Increased the width of date-time range inputs for better usability.
    • Enhanced button responsiveness in the date picker footer based on selection mode.
  • Bug Fixes

    • Adjusted layout and styling for various date and time picker components to ensure consistent visual presentation.

Copy link

coderabbitai bot commented Sep 29, 2024

Walkthrough

The pull request introduces various modifications across multiple Vue.js components, primarily focusing on simplifying the date and time picker functionalities. Key changes include the removal of the range-separator attribute from several components and adjustments to CSS styles, particularly the width of certain elements. These alterations aim to streamline component attributes and enhance the overall layout without affecting existing functionalities.

Changes

File Path Change Summary
examples/sites/demos/pc/app/date-picker/... Removed range-separator from <tiny-date-picker> components and adjusted CSS widths.
examples/sites/demos/pc/app/time-picker/... Removed range-separator from <tiny-time-picker> components.
packages/design/saas/index.ts Added DatePanel to exports, enhancing module functionality.
packages/design/saas/src/date-panel/index.ts Introduced a new file exporting a state object for button configuration.
packages/renderless/src/date-panel/vue.ts Updated initState and renderless functions to include designConfig for dynamic styling.
packages/theme-saas/src/picker/index.less Added new CSS classes and modified existing styles for icon containers.
packages/theme/src/picker/... Removed specific styles for button and picker components, streamlining their appearance.
packages/vue/src/date-panel/src/pc.vue Modified footer component for dynamic styling based on selection mode.
packages/vue/src/date-range/src/pc.vue Simplified button definitions by removing size attributes.
packages/vue/src/picker/src/pc.vue Enhanced icon rendering logic for better structure and conditional display.

Possibly related PRs

Suggested labels

enhancement

Suggested reviewers

  • zzcr

🐰 "In the meadow, changes bloom,
Date pickers dance, making room.
With styles refined and widths anew,
Components shine, all fresh and true.
Hopping forward, we embrace the light,
A joyful leap into the night!" 🌼


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.

@github-actions github-actions bot added the enhancement New feature or request label Sep 29, 2024
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: 6

🧹 Outside diff range and nitpick comments (20)
packages/design/saas/src/date-panel/index.ts (1)

1-6: LGTM! Consider enhancing with types and documentation.

The changes align well with the PR objective of adapting the date-picker to the SMB theme. The default export sets up the initial state for button styling in the date-panel component.

To further improve this code:

  1. Add documentation to explain the purpose and usage of this file. For example:

    /**
     * Default configuration for the date-panel component.
     * This sets up the initial state for button styling within the date-picker.
     */
  2. Consider adding type definitions for improved type safety:

    interface DatePanelState {
      buttonType: 'primary' | 'secondary' | 'text';
      buttonSize: 'mini' | 'small' | 'medium' | 'large';
    }
    
    const state: DatePanelState = {
      buttonType: 'primary',
      buttonSize: 'mini'
    };
    
    export default { state };
  3. The file name index.ts is generic. Consider renaming it to better reflect its role, e.g., datePanelConfig.ts or datePanelDefaults.ts.

examples/sites/demos/pc/app/time-picker/is-range-composition-api.vue (1)

Line range hint 9-17: Consider making initial time values more flexible

The current implementation uses hardcoded initial values for startTime and endTime. To improve the reusability and flexibility of this component, consider the following suggestions:

  1. Accept initial values as props, allowing parent components to set them.
  2. Use the current date and time as default values if no props are provided.

Here's an example of how you could refactor this:

 <script setup>
-import { ref } from 'vue'
+import { ref, computed } from 'vue'
 import { TimePicker as TinyTimePicker } from '@opentiny/vue'

-const startTime = new Date(2016, 9, 10, 18, 40)
-const endTime = new Date(2016, 9, 10, 18, 50)
+const props = defineProps({
+  initialStartTime: {
+    type: Date,
+    default: () => new Date()
+  },
+  initialEndTime: {
+    type: Date,
+    default: () => {
+      const date = new Date();
+      date.setMinutes(date.getMinutes() + 10);
+      return date;
+    }
+  }
+})

-const value1 = ref([startTime, endTime])
+const value1 = ref([props.initialStartTime, props.initialEndTime])
 </script>

This change allows the component to be more flexible while still providing sensible defaults.

examples/sites/demos/pc/app/date-picker/label-inside.vue (1)

29-32: Consider adding explanatory comments.

The changes align well with the PR objective of adapting the date-picker to the SMB theme. However, to improve code maintainability and clarity, consider adding comments explaining the reasoning behind these specific adjustments.

For example:

:deep(.tiny-date-editor--daterange.tiny-input__inner) {
  /* Increased width to accommodate SMB theme requirements */
  width: 360px;
}

:deep(.tiny-range__close-icon) {
  /* Adjusted position to align with SMB theme layout */
  right: -4px;
}

This will help other developers understand the purpose of these changes in the context of the SMB theme adaptation.

packages/design/saas/index.ts (1)

43-44: Consider alphabetizing the components object for improved maintainability.

The addition of DatePanel to the exported components is correct. However, to improve readability and maintainability, consider alphabetizing the entire components object. This would make it easier to locate specific components and maintain consistency as new components are added in the future.

Here's a suggested refactor:

 export default {
   name: 'saas',
   version,
   components: {
     Alert,
     Badge,
     CollapseItem,
+    DatePanel,
+    DateRange,
     Drawer,
     Dropdown,
     DropdownMenu,
     DropdownItem,
     Form,
     Grid,
-    Switch,
-    Select,
-    Popover,
-    Loading,
     Input,
-    DateRange,
+    Loading,
     Pager,
+    Popeditor,
+    Popover,
+    Select,
+    Switch,
-    DialogBox,
-    Popeditor,
-    DatePanel
+    DialogBox
   }
 }
examples/sites/demos/pc/app/time-picker/size.spec.ts (2)

17-17: Approve change and update TODO comment

The adjustment to 40px for the medium-sized range time picker aligns it with the single time picker, addressing the inconsistency mentioned in the TODO comment. This change improves overall UI consistency.

Consider removing or updating the TODO comment on line 16, as the inconsistency has been addressed:

- // TINY-TODO: 日期和日期范围的输入框高度不一致
+ // Heights for date and date range inputs are now consistent

22-23: Approve change and update TODO comment

The adjustment to 28px for both single and range time pickers in small size improves consistency and addresses the issue mentioned in the TODO comment. This change aligns well with the PR objective of adapting to the SMB theme.

Consider removing or updating the TODO comment on line 21, as the inconsistency has been addressed:

- // TINY-TODO: 日期和日期范围的输入框高度不一致
+ // Heights for date and date range inputs are now consistent
examples/sites/demos/pc/app/time-picker/size.vue (1)

6-7: Approved: Improved logical order of size options

The reordering of the radio buttons for size options (medium, default, small, mini) creates a more intuitive descending size sequence. This change enhances user understanding and ease of selection without affecting the component's functionality.

Consider adding a comment above the <tiny-radio-group> explaining the rationale behind this specific order of sizes. For example:

<!-- Size options are ordered from largest to smallest for intuitive selection -->
<tiny-radio-group v-model="radioValue" size="mini" class="demo-time-picker__switch-size">
  ...
</tiny-radio-group>
examples/sites/demos/pc/app/date-picker/size-composition-api.vue (1)

Line range hint 1-63: Consider updating documentation for these UI changes.

While the changes made are relatively minor, it would be beneficial to update any relevant documentation or add comments in the code to explain:

  1. The new order of size options in the radio button group.
  2. The reason for the specific width increase of the date range picker.

This will help maintain clarity for future developers working on this component.

examples/sites/demos/pc/app/date-picker/size.vue (1)

Line range hint 1-71: Summary of changes and request for additional context

The changes in this file include reordering the size options for the date picker and increasing the width of the date range picker. While these changes seem to improve the component's usability, it would be helpful to have more context about the SMB theme adaptation mentioned in the PR objectives.

Could you provide more details on the specific requirements of the SMB theme? This would help us better understand how these changes contribute to the theme adaptation and if there are any other modifications needed to fully align with the SMB theme guidelines.

packages/theme-saas/src/picker/index.less (2)

109-109: Approved with suggestion: Consider consistent use of utility classes.

The changes to .@{range-prefix-cls}__close-icon improve the layout and align with the SMB theme. The use of utility classes for width, height, and margin is good for consistency. However, I noticed a mix of utility classes and traditional CSS properties in this block.

Consider refactoring the entire block to use utility classes consistently. This could improve maintainability and make it easier to adapt to theme changes in the future. For example:

.@{range-prefix-cls}__close-icon {
  @apply absolute right-1.5 text-base w-4 h-5 mr-6;
  @apply flex justify-center items-center;
  float: right;
  @apply leading-8;
}

This approach would make the styling more consistent with the newly added utility classes.

Also applies to: 116-117


Incomplete removal of .baseClearicon class.

The .baseClearicon class is still present in multiple files:

  • packages/theme/src/picker/index.less
  • packages/theme-saas/src/picker/index.less (within svg.baseClearicon:hover)

Please ensure that all instances of .baseClearicon are removed or refactored appropriately to prevent any unintended behaviors.

🔗 Analysis chain

Line range hint 1-285: Please clarify the removal of .baseClearicon class.

The AI summary mentions that the .baseClearicon class has been removed from the .@{input-prefix-cls}__icon class. While this simplifies the CSS structure, it's not clear if this removal was intentional or if it might have unintended consequences.

Could you please confirm if the removal of .baseClearicon was intentional? If so, please ensure that the hover behavior for the clear icon is still working as expected. You may want to run the following command to check for any remaining usage of .baseClearicon in the codebase:

If the removal was unintentional, please consider adding it back to maintain the existing hover behavior.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for any remaining usage of .baseClearicon
rg --type less --type css '.baseClearicon'

Length of output: 228

packages/theme/src/picker/index.less (3)

119-122: LGTM: New close box styling

The addition of the .@{range-prefix-cls}__close-box class looks good. It creates a container for the close icon with appropriate positioning and layering.

One small suggestion: Consider using a variable for the z-index value to maintain consistency across the theme.

Here's a suggested minor improvement:

- z-index: 5;
+ z-index: var(--ti-date-picker-close-box-z-index, 5);

Don't forget to define the --ti-date-picker-close-box-z-index variable in your theme variables file.


127-132: Close icon styling improvements

The changes to the .@{range-prefix-cls}__close-icon class look good overall. They provide more specific styling for the close icon. However, there are a couple of points to consider:

  1. The absolute positioning with right: -20px places the icon outside its container. Ensure this doesn't cause any layout issues or unintended overlaps.

  2. The hardcoded white background color might cause visibility issues on light backgrounds. Consider using a theme variable that can adapt to different background contexts.

Here are some suggested improvements:

  width: 20px;
  height: 18px;
  position: absolute;
  right: -20px;
- background-color: #FFFFFF;
+ background-color: var(--ti-date-picker-close-icon-bg, #FFFFFF);
  margin-top: -1px;

Also, consider adding a subtle box-shadow or border to ensure visibility against all background colors:

  box-shadow: 0 0 0 1px var(--ti-date-picker-close-icon-border-color, rgba(0,0,0,0.1));

Don't forget to define the new variables in your theme variables file.


151-158: Consider more flexible width and LGTM on alignment

The change to center-align the items within the range editor looks good and aligns with the SMB theme objectives.

However, setting a fixed width of 360px might limit flexibility in different contexts.

Consider using a more flexible approach:

.@{range-editor-prefix-cls}.@{input-prefix-cls}__inner {
-  width: 360px;
+  width: var(--ti-date-range-editor-width, 360px);
+  max-width: 100%;
}

This change allows the width to be customized via a theme variable while ensuring it doesn't overflow its container. Don't forget to define the --ti-date-range-editor-width variable in your theme variables file.

packages/vue/src/picker/src/pc.vue (1)

120-120: Consider removing duplicate class.

The class tiny-input__icon is repeated twice on this element. This doesn't affect functionality but it's unnecessary and could be confusing for maintainers.

Consider removing the duplicate class:

-      <i class="tiny-input__icon tiny-input__icon">
+      <i class="tiny-input__icon">
packages/renderless/src/date-panel/vue.ts (2)

92-92: LGTM! Consider adding type annotation for designConfig.

The addition of designConfig parameter is a good approach for customization and aligns with the PR objective.

Consider adding a type annotation for designConfig to improve code readability and maintainability. For example:

const initState = ({ reactive, computed, api, i18n, designConfig }: { /* existing types */, designConfig: DesignConfig }) => {
  // ...
}

Replace DesignConfig with the appropriate type or interface for your design configuration.


235-239: LGTM! Consider restructuring for improved readability.

The addition of designConfig parameter is consistent with the changes in the initState function and supports the PR objective.

To improve readability, consider restructuring the function signature. For example:

export const renderless = (
  props,
  context: { computed: any; reactive: any; watch: any; nextTick: any },
  dependencies: { t: any; emit: any; vm: any; i18n: any; designConfig: any }
) => {
  const { computed, reactive, watch, nextTick } = context;
  const { t, emit: $emit, vm, i18n, designConfig } = dependencies;
  // ... rest of the function
}

This structure groups related parameters and makes the function signature easier to read and maintain.

packages/vue/src/date-panel/src/pc.vue (2)

212-216: Approve footer layout enhancement with a suggestion for improved readability.

The addition of dynamic justifyContent styling based on state.selectionMode improves the flexibility of the footer layout. This change allows for better alignment of footer elements in different selection modes.

Consider extracting the condition into a computed property for improved readability:

<script setup>
// ...
const isSpaceBetweenJustified = computed(() => !['dates', 'years'].includes(state.selectionMode))
</script>

<template>
  <div
    class="tiny-picker-panel__footer"
    v-show="state.isShowFooter"
    :style="{ justifyContent: isSpaceBetweenJustified ? 'space-between' : 'right' }"
  >
    <!-- ... -->
  </div>
</template>

This change would make the template more readable and the logic easier to understand and maintain.


Line range hint 219-233: Approve button enhancements with a suggestion for consistency.

The modifications to the button components improve the flexibility and customization options of the date picker. The conditional visibility of the "Now" button and the dynamic bindings for size and type align well with the PR objective of adapting to the SMB theme.

For consistency, consider applying the same conditional visibility to the "Confirm" button as well:

<tiny-button
  v-show="!['dates', 'years'].includes(state.selectionMode)"
  :type="state.buttonType"
  :size="state.buttonSize"
  class="tiny-picker-panel__link-btn"
  @click="confirm"
>
  {{ t('ui.datepicker.confirm') }}
</tiny-button>

This change would ensure that both buttons have consistent visibility rules, which might be beneficial for certain selection modes.

packages/vue/src/date-range/src/pc.vue (1)

Line range hint 217-225: LGTM! Consider applying consistent styling to both buttons.

The removal of the size attribute from both buttons aligns with the PR objective of adapting to the SMB theme. The functionality remains intact, and the internationalization support is maintained.

For consistency, consider applying the same styling approach to both buttons. Currently, the "Clear" button uses type="text", while the "Confirm" button uses dynamic binding for its type attribute. You might want to use dynamic binding for both buttons to ensure a consistent look and feel. For example:

<tiny-button
  :type="state.clearButtonProps.type || 'text'"
  class="tiny-picker-panel__link-btn"
  @click="handleClear"
>
  {{ t('ui.datepicker.clear') }}
</tiny-button>

This change would allow for easier theming and maintenance in the future.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 41f9ca8 and eaa7546.

📒 Files selected for processing (27)
  • examples/sites/demos/pc/app/date-picker/date-range-composition-api.vue (0 hunks)
  • examples/sites/demos/pc/app/date-picker/date-range.vue (0 hunks)
  • examples/sites/demos/pc/app/date-picker/default-value-composition-api.vue (1 hunks)
  • examples/sites/demos/pc/app/date-picker/default-value.vue (1 hunks)
  • examples/sites/demos/pc/app/date-picker/disabled-composition-api.vue (1 hunks)
  • examples/sites/demos/pc/app/date-picker/disabled.vue (1 hunks)
  • examples/sites/demos/pc/app/date-picker/label-inside-composition-api.vue (1 hunks)
  • examples/sites/demos/pc/app/date-picker/label-inside.vue (1 hunks)
  • examples/sites/demos/pc/app/date-picker/shortcuts-composition-api.vue (1 hunks)
  • examples/sites/demos/pc/app/date-picker/shortcuts.vue (1 hunks)
  • examples/sites/demos/pc/app/date-picker/size-composition-api.vue (2 hunks)
  • examples/sites/demos/pc/app/date-picker/size.vue (2 hunks)
  • examples/sites/demos/pc/app/time-picker/is-range-composition-api.vue (1 hunks)
  • examples/sites/demos/pc/app/time-picker/is-range.vue (1 hunks)
  • examples/sites/demos/pc/app/time-picker/size-composition-api.vue (1 hunks)
  • examples/sites/demos/pc/app/time-picker/size.spec.ts (1 hunks)
  • examples/sites/demos/pc/app/time-picker/size.vue (1 hunks)
  • packages/design/saas/index.ts (2 hunks)
  • packages/design/saas/src/date-panel/index.ts (1 hunks)
  • packages/renderless/src/date-panel/vue.ts (3 hunks)
  • packages/theme-saas/src/picker/index.less (2 hunks)
  • packages/theme/src/date-panel/index.less (0 hunks)
  • packages/theme/src/picker/index.less (2 hunks)
  • packages/theme/src/picker/vars.less (0 hunks)
  • packages/vue/src/date-panel/src/pc.vue (2 hunks)
  • packages/vue/src/date-range/src/pc.vue (1 hunks)
  • packages/vue/src/picker/src/pc.vue (1 hunks)
💤 Files with no reviewable changes (4)
  • examples/sites/demos/pc/app/date-picker/date-range-composition-api.vue
  • examples/sites/demos/pc/app/date-picker/date-range.vue
  • packages/theme/src/date-panel/index.less
  • packages/theme/src/picker/vars.less
✅ Files skipped from review due to trivial changes (2)
  • examples/sites/demos/pc/app/date-picker/shortcuts-composition-api.vue
  • examples/sites/demos/pc/app/date-picker/shortcuts.vue
🔇 Additional comments (28)
examples/sites/demos/pc/app/time-picker/is-range-composition-api.vue (1)

Line range hint 1-18: Overall assessment: Changes align with PR objectives

The modifications to this file appear to be in line with the PR objectives of adapting the date-picker to the SMB theme. The removal of the explicit range-separator prop likely contributes to this goal by standardizing the component's appearance.

However, to ensure a smooth transition:

  1. Verify that the default separator aligns with the SMB theme requirements.
  2. Test the component in different locales to confirm that the user experience remains positive across languages.
  3. Consider the suggested refactoring to improve the component's flexibility.

These changes, combined with proper testing and verification, should successfully adapt the time-picker to the SMB theme while maintaining or improving its functionality.

examples/sites/demos/pc/app/time-picker/is-range.vue (1)

3-3: Clarify the rationale behind removing the range-separator attribute.

The removal of the range-separator attribute from the <tiny-time-picker> component might affect how the time range is displayed to users. While this change could be part of adapting to the SMB theme, it's not immediately clear how it relates to the PR objectives.

Could you please provide more context on:

  1. How this change specifically contributes to adapting the date-picker to the SMB theme?
  2. What will be used as the default separator now, and how does it align with the SMB theme guidelines?

Additionally, I recommend:

  1. Documenting this change in the component's documentation or release notes, as it might affect the behavior that users expect.
  2. Verifying that this change is consistently applied across all instances of the range time picker in the SMB theme implementation.

To ensure consistency, let's check for other occurrences of the range-separator attribute in time picker components:

This will help us identify if there are any inconsistencies in the implementation across the codebase.

✅ Verification successful

Verification Successful: No additional instances of range-separator found.

The removal of the range-separator attribute from the <tiny-time-picker> component in is-range.vue appears to be an isolated change and does not affect other parts of the codebase. This aligns with the PR objectives of adapting to the SMB theme without introducing inconsistencies.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for other occurrences of range-separator in time picker components
rg --type vue 'tiny-time-picker.*range-separator' .

Length of output: 81


Script:

#!/bin/bash
# Search for other occurrences of range-separator in tiny-time-picker components within .vue files
rg 'tiny-time-picker.*range-separator' --include '*.vue' .

Length of output: 502


Script:

#!/bin/bash
# Find all .vue files and search for range-separator in tiny-time-picker components
find . -type f -name '*.vue' -exec grep -H 'tiny-time-picker.*range-separator' {} +

Length of output: 87

examples/sites/demos/pc/app/date-picker/label-inside-composition-api.vue (2)

21-24: Summary: Style adjustments for SMB theme adaptation

The changes to the date picker styling align well with the PR objective of adapting to the SMB theme. The increased width of the date range picker and the repositioning of the close icon should improve usability.

To ensure these changes don't introduce any unintended side effects:

  1. Conduct thorough testing of the date picker component in various scenarios and screen sizes.
  2. Verify that the increased width doesn't cause layout issues on smaller screens.
  3. Check that the close icon is properly positioned and doesn't overlap with other elements.
  4. Consider adding responsive design rules if necessary to maintain consistency across different device sizes.

Run the following script to check for any responsive design rules that might need updating:

#!/bin/bash
# Description: Check for responsive design rules related to the date picker

# Test: Search for media queries or responsive classes used with the date picker
rg --type vue --type css --type html '(@media|tiny-col-|tiny-row-|tiny-span-).*tiny-(date-picker|date-editor|range)' -g '!label-inside-composition-api.vue'

23-24: LGTM! Verify visual appearance.

The adjustment of the close icon's position is likely necessary due to the increased width of the date range picker.

Please verify that this positioning doesn't cause any visual issues or overlap with other elements. Consider running visual regression tests if available.

Additionally, run the following script to check for any other uses of the .tiny-range__close-icon class that might be affected:

✅ Verification successful

Please run the following script to check for other uses of the .tiny-range__close-icon class:


Verified! No additional instances of .tiny-range__close-icon were found outside the reviewed file.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for other uses of the .tiny-range__close-icon class

# Test: Search for other occurrences of the .tiny-range__close-icon class
rg --type vue --type css --type html '\.tiny-range__close-icon' -g '!label-inside-composition-api.vue'

Length of output: 185


Script:

#!/bin/bash
# Description: Check for other uses of the .tiny-range__close-icon class

# Test: Search for other occurrences of the .tiny-range__close-icon class in .vue, .css, and .html files
rg '\.tiny-range__close-icon' --glob '!label-inside-composition-api.vue' -g '*.vue' -g '*.css' -g '*.html'

Length of output: 308

examples/sites/demos/pc/app/date-picker/label-inside.vue (2)

29-30: LGTM! Verify layout impact.

The increase in width from 280px to 360px for the date range picker input looks good. This change likely improves the user experience by providing more space for the selected date range.

Please verify that this width increase doesn't negatively impact the layout of surrounding elements or cause any overflow issues in the parent container.


31-32: LGTM! Verify visual alignment.

The addition of right: -4px; for the .tiny-range__close-icon looks good. This adjustment likely improves the alignment of the close icon within the date range picker.

Please verify the following:

  1. The close icon is visually well-aligned within the date range picker after this change.
  2. The icon doesn't overlap with other elements or get cut off at the edge of the input.
  3. The positioning works well across different screen sizes and browser zoom levels.
packages/design/saas/index.ts (2)

20-20: LGTM: Import statement for DatePanel is correct and consistent.

The import statement for DatePanel follows the established pattern in the file and is correctly implemented.


20-20: Clarify the relationship between DatePanel and DateRange, and alignment with PR objectives.

The PR objectives mention adapting the date-picker to the SMB theme, but the changes only introduce a new DatePanel component without modifying existing components. Could you please clarify:

  1. How does DatePanel relate to the existing DateRange component?
  2. How does this change align with the objective of adapting to the SMB theme?
  3. Are there any theme-specific modifications that should be applied to DatePanel or other components?

This information will help ensure that the PR fully meets its objectives and that the new component is properly integrated into the existing design system.

Also applies to: 44-44

examples/sites/demos/pc/app/date-picker/default-value-composition-api.vue (1)

37-37: LGTM! Verify layout impact of increased width.

The increase in width for the datetime range picker from 280px to 360px aligns with the PR objective of adapting the date-picker to the SMB theme. This change likely improves the visibility and usability of the component.

Please verify that this width increase doesn't negatively impact the layout of the parent container or surrounding elements in various screen sizes. Consider testing the component in different viewport widths to ensure responsiveness.

examples/sites/demos/pc/app/date-picker/default-value.vue (1)

45-45: LGTM! Consider verifying the visual impact.

The increase in width for the date-time range picker input from 280px to 360px aligns with the PR objective of adapting to the SMB theme. This change should provide better visibility and potentially accommodate longer date ranges.

To ensure the change meets the design requirements:

  1. Please verify that the new width of 360px matches the SMB theme specifications.
  2. Test the component with various date ranges to confirm that the increased width accommodates all use cases without causing layout issues.
  3. Consider adding before/after screenshots to the PR description to help reviewers visualize the impact of this change.
examples/sites/demos/pc/app/time-picker/size-composition-api.vue (1)

6-6: Improved order of size options

The reordering of the radio buttons for size selection is a good improvement. The new order (medium, default, small, mini) presents a more logical and intuitive sequence of sizes, which should enhance the user experience.

examples/sites/demos/pc/app/time-picker/size.spec.ts (2)

10-11: LGTM: Consistent height for default size time pickers

The change to 32px for both single and range time pickers in the default size improves consistency in the UI. This aligns well with the PR objective of adapting to the SMB theme.


10-23: Verify visual appearance and update documentation

The changes standardize heights across different sizes of time pickers, which improves UI consistency and aligns with the SMB theme adaptation. However, it's important to:

  1. Verify the visual appearance of the components with these new heights to ensure they meet design standards.
  2. Update any relevant documentation or design specifications to reflect these new standardized heights.

To assist with visual verification, you can run the following command to capture screenshots of the time picker components in different sizes:

Consider adding visual regression tests to automatically catch any unintended visual changes in the future.

examples/sites/demos/pc/app/date-picker/disabled.vue (1)

63-63: LGTM with suggestions: Width increase for daterange picker

The width increase from 280px to 360px for the daterange picker aligns with the PR objective of adapting to the SMB theme. This change likely provides more space for displaying two dates, improving usability.

However, I have a few suggestions:

  1. Consider adding a comment explaining why this specific width (360px) was chosen. This will help future maintainers understand the reasoning behind this change.

  2. Be aware that the parent container's width is still set to 280px. This might cause layout issues or unexpected behavior. Please verify that this doesn't create any visual problems.

  3. It's important to visually verify this change to ensure it looks correct and doesn't negatively impact the overall layout.

To ensure this change doesn't introduce any layout issues, please run the following verification steps:

  1. Build and run the demo application.
  2. Navigate to the date-picker demo page.
  3. Locate the daterange picker and verify that:
    • The input field displays correctly without any overflow or truncation.
    • The layout of surrounding elements is not negatively affected.
    • The date picker dropdown aligns correctly with the input field.

If any issues are found, please adjust the width accordingly or consider updating the parent container's width as well.

examples/sites/demos/pc/app/date-picker/size-composition-api.vue (2)

6-6: Please clarify the reasoning behind the radio button order change.

The order of size options has been changed, moving "small" after "default". This new order (medium, default, small, mini) doesn't follow a clear logical progression. Could you please explain the rationale behind this change? It might be helpful to consider maintaining a consistent order (e.g., from largest to smallest) for better user experience and intuition.


58-58: Approve width increase, but verify layout impact.

The increase in width for the date range picker from 280px to 360px is likely to improve visibility and usability. This change aligns with the PR objective of adapting to the SMB theme.

Please ensure that this width increase doesn't negatively impact the overall layout or responsiveness of the component, especially on smaller screens. Consider adding a comment explaining the reason for this specific width, if it's related to design requirements or user feedback.

examples/sites/demos/pc/app/date-picker/size.vue (2)

6-6: Improved order of size options

The reordering of the radio button options for sizes is a good change. It now follows a more logical sequence from larger to smaller sizes (medium, default, small, mini), which improves user experience and aligns with common UI practices.


64-64: Increased width for date range picker

The width increase for the date range picker from 280px to 360px could improve the readability and usability of the component. However, I have a couple of questions:

  1. Is this change part of the adaptation to the SMB theme mentioned in the PR objectives?
  2. Have you verified that this width increase doesn't negatively impact the layout in various use cases?

To ensure consistency, let's check if there are any other width definitions for date pickers in the codebase:

✅ Verification successful

The previous shell script encountered an issue with the unrecognized vue file type. Let's adjust the script to search for .vue, .less, and .css files by specifying their extensions.


Width Adjustment for Date Range Picker Verified

The width increase from 280px to 360px has been consistently applied across all relevant components, aligning with the SMB theme adaptation objectives. This change enhances the readability and usability of the date pickers without negatively impacting the overall layout.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for width definitions related to date pickers
rg --type=vue --type=less --type=css 'tiny-date-editor|tiny-input__inner' -C 2 | rg 'width'

Length of output: 119


Script:

#!/bin/bash
# Search for width definitions related to date pickers in .vue, .less, and .css files
rg 'tiny-date-editor|tiny-input__inner' -g '*.vue' -g '*.less' -g '*.css' -C 2 | rg 'width'

Length of output: 1704

packages/theme-saas/src/picker/index.less (2)

25-28: LGTM: New icon container class improves layout.

The addition of .@{input-prefix-cls}__icon-container with flexbox alignment is a good improvement. It provides better control over the icon positioning within the input, which aligns well with the PR's objective of adapting to the SMB theme.


Line range hint 1-285: Summary: Good progress on SMB theme adaptation, with room for improvement

The changes in this file generally align well with the PR objective of adapting the date-picker to the SMB theme. The new icon container class and the use of utility classes for the close icon improve layout consistency and maintainability.

However, there are a few areas that could use attention:

  1. Consider adopting a more consistent approach to styling throughout the file, preferring utility classes where possible.
  2. Clarify the intentionality and impact of removing the .baseClearicon class.
  3. Ensure that all changes maintain the existing functionality while improving the theme adaptation.

Once these points are addressed, the changes will contribute significantly to a more cohesive and maintainable SMB theme implementation for the date-picker component.

packages/theme/src/picker/index.less (2)

85-89: LGTM: Icon styling adjustments

The changes to the .@{range-prefix-cls}__icon class look good. The width adjustment and the addition of a negative margin-top will help in achieving better alignment and sizing for the SMB theme.


Line range hint 1-150: Overall feedback on date picker styling changes

The changes in this file generally align well with the PR objective of adapting the date-picker to the SMB theme. The modifications improve the visual styling and layout of various components within the date picker.

However, there are several opportunities to enhance the code's maintainability and flexibility:

  1. Consider replacing hardcoded color values with theme variables throughout the file. This will make it easier to maintain a consistent color scheme and adapt to different themes in the future.

  2. Look for opportunities to create mixins or utility classes for commonly repeated styles, such as the disabled state styling.

  3. Use flexible units (like percentages or rem) or CSS variables for dimensions where possible, instead of fixed pixel values. This will improve the component's adaptability to different screen sizes and user preferences.

  4. Ensure that all new CSS variables are properly documented in the theme variables file.

These improvements will make the date picker component more robust and easier to maintain in the long run, while still achieving the desired SMB theme adaptation.

packages/vue/src/picker/src/pc.vue (3)

122-128: Improved structure for close icon rendering.

The new structure for rendering the close icon improves the component's flexibility and aligns with the PR's objective of adapting to the SMB theme. The conditional rendering based on state.haveTrigger and the use of a separate tiny-range__close-box class provide better control over the icon's appearance and behavior.


130-134: Consider accessibility implications of conditional icon rendering.

The trigger icon is now conditionally rendered based on !state.isDisplayOnly. While this may improve the visual design, it's important to ensure that this doesn't negatively impact accessibility, especially for keyboard users who might rely on this icon for interaction.

Please verify that:

  1. The date picker remains fully functional and accessible when the trigger icon is not displayed.
  2. There are alternative ways for users to interact with the date picker when in display-only mode.

If these conditions are met, the changes can be approved.


120-134: Overall assessment of icon rendering changes.

The modifications to the icon rendering logic in this component appear to enhance its structure and flexibility, aligning well with the PR's objective of adapting to the SMB theme. The changes introduce better conditional rendering and class management for both the close and trigger icons.

While the changes generally look good, please address the following points:

  1. Remove the duplicate tiny-input__icon class.
  2. Verify the accessibility implications of the conditional trigger icon rendering.

Once these points are addressed, the changes can be fully approved.

packages/renderless/src/date-panel/vue.ts (2)

136-136: Verify the necessity of isShowFooter computed property.

The addition of isShowFooter computed property seems unrelated to the PR objective of adapting to the SMB theme. Can you clarify the purpose of this change and confirm if it's intended to be part of this PR?


137-138: LGTM! Good implementation of buttonType and buttonSize.

The addition of buttonType and buttonSize properties using the designConfig parameter is well-implemented:

  • It aligns with the PR objective of adapting to the SMB theme.
  • The use of optional chaining (?.) is a good practice to handle potential undefined values.
  • Default values are provided as a fallback, which is a robust approach.
packages/vue/src/date-panel/src/pc.vue (1)

Line range hint 212-233: Summary: Successful adaptation to SMB theme with improved flexibility.

The changes made to the date picker component successfully adapt it to the SMB theme by introducing more flexibility in the footer layout and button customization. These modifications allow the component to adjust its appearance based on different selection modes, improving its overall usability and adaptability.

Key improvements:

  1. Dynamic footer layout based on selection mode.
  2. Conditional visibility for the "Now" button.
  3. Customizable button size and type through dynamic bindings.

These changes enhance the component's versatility without introducing breaking changes, aligning well with the PR objectives.

To further improve the component, consider:

  1. Extracting complex conditions into computed properties for better readability.
  2. Ensuring consistent visibility rules for both footer buttons.
  3. Adding unit tests to verify the new dynamic behavior (if not already covered).

Great work on enhancing the date picker component!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants