fix: Release/v2.1.0 #963
fix: Release/v2.1.0 #963
Conversation
1. 修复清空画布报错的 bug 2. 修复区块加载错误的 bug 3. 修复画布拖拽组件到最前面的时候，组件会消失的 bug
* fix: resolve some schema update issue 1. 调整画布宽度时，画布选中框不及时更新的 bug 2. 空页面的时候，拖拽组件到画布提示两次新建页面的 bug 3. importSchema 的时候，清空选择 4. 页面 schema 保存的时候，设置保存状态为 false 5. 增强 AdvanceConfig 配置对 props 的容错 * fix: updateRect async change to callback style * fix: first time enter app should show empty page warning
* fix: resolve warnings * fix: add access guard avoid runtime errors * fix: change placeholder prop type * fix: resolve type check * fix: toolbarbaseicon props default value
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the WalkthroughThis pull request encompasses a comprehensive update across multiple packages in the project, primarily focusing on version increments from Changes
Sequence DiagramsequenceDiagram
participant Workflow as GitHub Actions
participant Repo as Repository
participant Packages as Project Packages
Workflow->>Repo: Trigger on push/PR to monitored branches
Repo->>Packages: Version update to 2.1.0-rc.0
Packages->>Packages: Apply component-specific changes
Packages-->>Repo: Commit updated packages
Possibly related PRs
Suggested Labels
Suggested Reviewers
Poem
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 (
|
github-actions
bot
added
bug
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (15)
packages/toolbars/clean/src/Main.vue (1)
54-57: LGTM! Consider adding error handling.The refactoring of the confirmation dialog handling is a good improvement that makes the code more maintainable. The new approach using
execcallback is more idiomatic and reduces code complexity.Consider adding error handling to gracefully handle potential failures during canvas clearing:
exec: () => { - clearCanvas() + try { + clearCanvas() + } catch (error) { + console.error('Failed to clear canvas:', error) + // Consider showing an error notification to the user + } }.github/workflows/push-check.yml (3)
11-11: Consider using GitHub-hosted runner labelsInstead of using the generic
ubuntu-latest, consider using a specific Ubuntu version label (e.g.,ubuntu-22.04) for better reproducibility and to avoid unexpected changes when the 'latest' version is updated.- runs-on: ubuntu-latest # windows-latest || macos-latest + runs-on: ubuntu-22.04
26-34: Consider adding TypeScript files to the changed files checkGiven this is a modern JavaScript project using build tools, you might want to include TypeScript files in your changed files check.
files: | **.js **.vue **.jsx + **.ts + **.tsx
39-43: Consider adding retention limits for build logsWhile uploading build logs is good for debugging, consider adding retention limits to manage storage:
- name: Upload build logs uses: actions/upload-artifact@v4 with: name: build-alpha-log path: build-alpha.log + retention-days: 14packages/layout/src/DesignSettings.vue (1)
41-42: Providing reactive state
ProvidingisCollapsedensures child components can rely on a single source of truth for collapsed state. Validate that changes toisCollapsedwithin children are intentionally managed, or that child components do not inadvertently mutate this state.Consider adding a composable or store pattern if multiple components will consume or mutate this state, to keep the code more structured.
packages/settings/styles/src/Main.vue (2)
199-209: Watcher forisCollapsed
This watcher automatically updates the active panels wheneverisCollapsedtoggles, which is convenient for synchronization. Confirm that no unwanted side-effects arise if the user significantly interacts with the collapse items immediately before or after toggling.You could consider storing the user’s last open panels to restore them after expanding (optional enhancement).
219-220: ExportingisCollapsed
ExposingisCollapsedfrom the setup function is consistent with the new approach. Ensure only parent or top-level components mutate this value, or usereadonlyif you want to restrict mutations to the origin.packages/canvas/container/src/components/CanvasResize.vue (1)
109-116: Ensure the watcher remains efficient.
The newly introduced watcher triggersupdateRecton eachsizeStylechange, which may run frequently. Consider debouncing or throttling if performance becomes a concern, especially when there are rapid consecutive changes tosizeStyle.packages/canvas/render/src/render.js (2)
Line range hint
218-233: Consider making the default error response more generic.The current default response on error assumes a specific data structure:
{ result: [{}], page: { total: 1 } }This structure seems tailored for table components. Consider making it more generic or configurable based on the component type.
Here's a suggested approach:
- resolve({ - result: [{}], - page: { total: 1 } - }) + // Get component type from context or pass it as parameter + const defaultResponse = context.getDefaultErrorResponse?.() || {} + resolve(defaultResponse)
Line range hint
223-228: Enhance error message with more context.The error notification could provide more detailed context to help users debug issues. Consider including:
- The function name or component context
- The actual error stack (if available)
- Suggestions for common fixes
globalNotify({ type: 'warning', title: '异步函数执行报错', - message: error?.message || '异步函数执行报错，请检查语法' + message: `${error?.message || '异步函数执行报错'}\n` + + `Context: ${context.componentName || 'Unknown'}\n` + + `Stack: ${error?.stack || 'Not available'}\n` + + '提示: 请检查异步函数语法或数据结构' })packages/common/component/toolbar-built-in/ToolbarBaseButton.vue (1)
2-2: Consider adding a test case to ensure the new static class binding works as intended.No automated tests appear to have been added for this component change. Including relevant tests will safeguard against inadvertent regressions and validate that the new "toolbar-button" class application meets requirements.
Would you like me to draft a test suite for verifying the static class behavior and ensure that no unexpected attributes are suppressed?
packages/plugins/materials/src/meta/layout/src/Main.vue (2)
5-5: Consider providing a fallback component or guard clause forregistryData?.components?.header.If
registryData?.components?.headeris missing or undefined, the<component>tag will render nothing. Depending on your requirements, you may want to display a default header or check for its existence to avoid runtime surprises.- :is="registryData?.components?.header" + :is="registryData?.components?.header || 'div'"
56-56: Handle an emptydisplayComponentIdsscenario for better clarity.When
props.registryData?.options?.displayComponentIdsis empty or undefined, it defaults to[]. While this prevents errors, consider if an empty array is meaningful or should trigger a different UI state or fallback, since no tabs will be displayed.packages/plugins/materials/src/composable/block-compile.js (1)
Line range hint
1-1: Address the "TODO: 待验证" comment.You have left a "TODO" comment in the code, suggesting further verification is needed. Consider clarifying or removing it if no longer required, or expand it to specify the details of what needs to be validated.
packages/common/component/MetaListItems.vue (1)
33-59: Consider simplifying the template structure.The outer
<div>wrapper appears redundant since the innerv-fordiv already provides the necessary structure. Consider simplifying while maintaining the same functionality.<template v-else> - <div> <div v-for="(item, index) in optionsList" :key="index" class="option-item not-draggable"> <meta-list-item :item="item" :index="index" :itemClick="itemClick" :dataScource="listItemOption" @changeItem="changeItem" @deleteItem="deleteItem" @editItem="editItem" > <!-- slots remain unchanged --> </meta-list-item> </div> - </div> </template>
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (79)
.github/workflows/push-check.yml(1 hunks)designer-demo/package.json(1 hunks)mockServer/package.json(1 hunks)packages/block-compiler/package.json(2 hunks)packages/blockToWebComponentTemplate/package.json(1 hunks)packages/build/vite-config/package.json(1 hunks)packages/build/vite-plugin-meta-comments/package.json(1 hunks)packages/builtinComponent/package.json(1 hunks)packages/canvas/DesignCanvas/src/DesignCanvas.vue(1 hunks)packages/canvas/DesignCanvas/src/api/useCanvas.js(2 hunks)packages/canvas/container/src/components/CanvasResize.vue(2 hunks)packages/canvas/package.json(1 hunks)packages/canvas/render/src/render.js(1 hunks)packages/common/component/MetaCodeEditor.vue(1 hunks)packages/common/component/MetaListItems.vue(1 hunks)packages/common/component/PluginBlockList.vue(1 hunks)packages/common/component/toolbar-built-in/ToolbarBaseButton.vue(1 hunks)packages/common/component/toolbar-built-in/ToolbarBaseIcon.vue(2 hunks)packages/common/package.json(1 hunks)packages/configurator/package.json(1 hunks)packages/configurator/src/tabs-group-configurator/TabsGroupConfigurator.vue(1 hunks)packages/design-core/package.json(1 hunks)packages/engine-cli/package.json(1 hunks)packages/i18n/package.json(1 hunks)packages/layout/package.json(1 hunks)packages/layout/src/DesignSettings.vue(3 hunks)packages/plugins/block/package.json(1 hunks)packages/plugins/bridge/package.json(1 hunks)packages/plugins/datasource/package.json(1 hunks)packages/plugins/help/package.json(1 hunks)packages/plugins/i18n/package.json(1 hunks)packages/plugins/i18n/src/Main.vue(1 hunks)packages/plugins/materials/package.json(1 hunks)packages/plugins/materials/src/composable/block-compile.js(1 hunks)packages/plugins/materials/src/meta/block/src/BlockGroup.vue(1 hunks)packages/plugins/materials/src/meta/block/src/BlockList.vue(0 hunks)packages/plugins/materials/src/meta/layout/src/Main.vue(2 hunks)packages/plugins/page/package.json(1 hunks)packages/plugins/robot/package.json(1 hunks)packages/plugins/schema/package.json(1 hunks)packages/plugins/schema/src/Main.vue(1 hunks)packages/plugins/script/package.json(1 hunks)packages/plugins/state/package.json(1 hunks)packages/plugins/tree/package.json(1 hunks)packages/plugins/tutorial/package.json(1 hunks)packages/register/package.json(1 hunks)packages/settings/design/package.json(1 hunks)packages/settings/events/package.json(1 hunks)packages/settings/events/src/components/AdvanceConfig.vue(1 hunks)packages/settings/panel/package.json(1 hunks)packages/settings/props/package.json(1 hunks)packages/settings/styles/package.json(1 hunks)packages/settings/styles/src/Main.vue(5 hunks)packages/settings/styles/src/components/border/BorderGroup.vue(4 hunks)packages/settings/styles/src/components/inputs/NumericSelect.vue(1 hunks)packages/svgs/package.json(1 hunks)packages/theme/base/package.json(1 hunks)packages/theme/dark/package.json(1 hunks)packages/theme/light/package.json(1 hunks)packages/toolbars/breadcrumb/package.json(1 hunks)packages/toolbars/clean/package.json(1 hunks)packages/toolbars/clean/src/Main.vue(1 hunks)packages/toolbars/collaboration/package.json(1 hunks)packages/toolbars/fullscreen/package.json(1 hunks)packages/toolbars/generate-code/package.json(1 hunks)packages/toolbars/lang/package.json(1 hunks)packages/toolbars/layout/package.json(1 hunks)packages/toolbars/lock/package.json(1 hunks)packages/toolbars/logo/package.json(1 hunks)packages/toolbars/logout/package.json(1 hunks)packages/toolbars/media/package.json(1 hunks)packages/toolbars/preview/package.json(1 hunks)packages/toolbars/redoundo/package.json(1 hunks)packages/toolbars/refresh/package.json(1 hunks)packages/toolbars/save/package.json(1 hunks)packages/toolbars/setting/package.json(1 hunks)packages/utils/package.json(1 hunks)packages/vue-generator/package.json(1 hunks)packages/webcomponent/package.json(1 hunks)
💤 Files with no reviewable changes (1)
- packages/plugins/materials/src/meta/block/src/BlockList.vue
✅ Files skipped from review due to trivial changes (53)
- packages/toolbars/generate-code/package.json
- packages/theme/light/package.json
- packages/plugins/materials/package.json
- packages/layout/package.json
- packages/plugins/i18n/package.json
- packages/settings/design/package.json
- packages/theme/dark/package.json
- packages/engine-cli/package.json
- packages/register/package.json
- packages/plugins/tree/package.json
- packages/utils/package.json
- packages/svgs/package.json
- packages/plugins/bridge/package.json
- packages/blockToWebComponentTemplate/package.json
- mockServer/package.json
- packages/design-core/package.json
- packages/toolbars/preview/package.json
- packages/settings/events/package.json
- packages/toolbars/lock/package.json
- packages/plugins/tutorial/package.json
- packages/toolbars/setting/package.json
- packages/toolbars/media/package.json
- packages/toolbars/logo/package.json
- packages/plugins/datasource/package.json
- packages/canvas/package.json
- packages/builtinComponent/package.json
- packages/plugins/help/package.json
- packages/settings/props/package.json
- packages/toolbars/refresh/package.json
- packages/configurator/package.json
- packages/plugins/state/package.json
- packages/toolbars/breadcrumb/package.json
- packages/settings/styles/package.json
- packages/plugins/robot/package.json
- packages/plugins/schema/package.json
- packages/theme/base/package.json
- packages/common/package.json
- packages/plugins/script/package.json
- packages/plugins/page/package.json
- packages/toolbars/fullscreen/package.json
- packages/toolbars/save/package.json
- packages/build/vite-config/package.json
- packages/toolbars/layout/package.json
- packages/toolbars/logout/package.json
- packages/toolbars/collaboration/package.json
- packages/plugins/block/package.json
- packages/toolbars/redoundo/package.json
- packages/toolbars/lang/package.json
- packages/settings/styles/src/components/border/BorderGroup.vue
- packages/settings/panel/package.json
- packages/build/vite-plugin-meta-comments/package.json
- designer-demo/package.json
- packages/toolbars/clean/package.json
🔇 Additional comments (30)
packages/plugins/materials/src/meta/block/src/BlockGroup.vue (1)
171-171: Confirm event naming and usage.
This addition of emits: ['changeGroup'] looks valid, but ensure it's consistently documented and tested. It might be helpful to pass the current group or related data with the event to provide context to the parent component.
Would you like me to generate a shell script that searches for all occurrences of 'changeGroup' to confirm usage consistency and identify missing tests?
.github/workflows/push-check.yml (2)
14-21: LGTM! Good practice using specific versions
The setup is well-structured with:
- Using specific versions for all actions (v4)
- Pinning Node.js to version 18
- Using pnpm version 9
7-7: Consider adding protection for release branches
The addition of release/* to monitored branches is good for quality control. However, consider implementing additional branch protection rules for release branches in your repository settings.
Let's verify the current branch protection rules:
packages/layout/src/DesignSettings.vue (3)
5-5: Ensure consistent naming conventions for dynamic components
Currently, :is="setting.entry" is used to dynamically render components. Ensure that all references to setting.entry across the codebase follow a clear naming convention and design pattern if this is intended to be a reusable pattern.
Would you like a script to search for other occurrences of setting.entry references across the repository to ensure consistency?
18-19: Importing additional Vue methods
Adding provide is appropriate for sharing the isCollapsed state down the component tree. No issues found here, but remember to also implement inject in child components that consume this state and ideally keep track of where it’s injected to avoid confusion about where the state is manipulated.
25-26: Registering new components
You have introduced TinyTooltip and are using TinyTabItem. Double-check that their usage in the template or logic is fully tested. In particular, confirm that the tooltip styling and behavior are consistent with the rest of the UI components.
packages/settings/styles/src/Main.vue (4)
68-68: Injecting rather than passing props
Switching from props to inject clarifies that the collapsed state originates elsewhere. This is a good approach to reduce prop drilling, but ensure that you maintain a clear relationship between parent and child so that changes to isCollapsed remain predictable.
108-109: Removed isCollapsed prop
The empty props object means that isCollapsed is no longer passed via props. Ensure no references to props.isCollapsed remain in the codebase.
Do you want a repository-wide search script to confirm no orphan references remain?
120-121: Reactive usage of isCollapsed
Using inject('isCollapsed') and then setting up a reactive reference for activeNames is efficient. This centralizes the collapsed state logic and ensures all expansions or collapses reflect the latest state across components.
129-129: Conditional handling in handoverGroup
This condition ensures only one active panel in collapsed mode. Verify that shifting array items like this will have the intended result for all user interactions, including quick toggling or repeated toggling of isCollapsed.
packages/canvas/container/src/components/CanvasResize.vue (1)
14-14: Imported useCanvas Looks Good.
The addition of useCanvas alongside useLayout aligns with the new functionality introduced further down in the watcher. No issues here.
packages/canvas/DesignCanvas/src/DesignCanvas.vue (1)
99-103: Improved modal-guard condition.
Adding the extra check (useHistory().historyState?.index === 0 && isSaved !== oldIsSaved) appears to prevent redundant modal prompts when the history stack is empty, which is beneficial for user experience. However, confirm that ignoring the modal in this scenario will not mask other vital warnings.
packages/canvas/DesignCanvas/src/api/useCanvas.js (2)
300-311: Flexible insertion logic.
The refined logic for inserting a new node at the beginning (position === 'before') or end (position === 'after') of parentNode.children adds clarity and robustness. Good job on ensuring setNode is called immediately afterward.
521-522: Clear selections on import.
Calling canvasApi.value?.clearSelect?.() immediately after resetting the canvas state helps avoid accidentally carrying over stale selections. This is a solid improvement in overall UX.
packages/plugins/schema/src/Main.vue (1)
105-109: Post-import unsaved state.
Automatically setting the schema to unsaved (setSaved(false)) right after importing is a practical approach to prompt the user flow for subsequent saving actions. Ensure that this aligns with the intended workflow—if certain imports should be considered “already saved,” a conditional check might be needed.
packages/canvas/render/src/render.js (1)
218-218: LGTM! Good defensive programming practice.
The use of optional chaining (?.) to safely check for the then method is a good improvement that prevents potential runtime errors when result is null or undefined.
packages/common/component/toolbar-built-in/ToolbarBaseButton.vue (1)
2-2: Confirm if removing dynamic attribute binding could affect usage.
Previously, v-bind="extendAttrs" allowed passing arbitrary attributes/events to <tiny-button>. Eliminating that binding may break any upstream usage relying on it. Please verify if this is indeed desired.
packages/settings/styles/src/components/inputs/NumericSelect.vue (1)
44-44: Confirm that restricting placeholder to just String does not break existing usage.
Previously, the placeholder prop also accepted numerical values. Changing it to String only may break any existing code passing numbers. Please ensure that no references pass numeric placeholders.
Use the following script to search for references to numeric placeholders:
✅ Verification successful
Let me try a different approach to verify this concern.
Let me check the actual component file to see how the placeholder was used before.
Based on the analysis of the codebase, I can now provide the final response:
Restricting placeholder to String type is safe to proceed
From the search results, I found that:
- Only one instance of placeholder being used in
BorderGroup.vuewith a string value"0". - The component is used in multiple places but none pass numeric placeholders.
- The component internally uses
tiny-numericwhich expects string placeholders.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Identify any numeric placeholders passed to NumericSelect or numeric-select across the repo.
rg -A 2 --case-sensitive $'numeric-select\\b' | rg 'placeholder=["\']?\d+["\']?'
Length of output: 116
Script:
#!/bin/bash
# Search for all usages of numeric-select component
rg -l --case-sensitive 'numeric-select'
Length of output: 495
Script:
#!/bin/bash
# Search for all usages of NumericSelect component
rg -l --case-sensitive 'NumericSelect'
Length of output: 560
Script:
#!/bin/bash
# Find the component file to check its previous version
git log -p packages/settings/styles/src/components/inputs/NumericSelect.vue
Length of output: 0
Script:
#!/bin/bash
# Search for any props being passed to numeric-select
rg -A 2 --case-sensitive '<numeric-select'
Length of output: 6460
Script:
#!/bin/bash
# Search for any props being passed to NumericSelect
rg -A 2 --case-sensitive '<NumericSelect'
Length of output: 43
Script:
#!/bin/bash
# Check the content of NumericSelect.vue
cat packages/settings/styles/src/components/inputs/NumericSelect.vue
Length of output: 3179
packages/common/component/toolbar-built-in/ToolbarBaseIcon.vue (2)
11-11: LGTM! Improved attribute handling
The change to use Vue's native $attrs instead of injected extendAttrs is a better practice as it:
- Reduces component coupling
- Uses Vue's built-in attribute inheritance
- Ensures consistent attribute forwarding
37-37: Verify the impact of options prop default value change
The change from () => {} to () => ({}) fixes a potential runtime error when accessing properties via optional chaining (options?.showDots). However, this might affect existing code that relies on the previous behavior.
Let's verify the usage of this component:
✅ Verification successful
Let's analyze the component usage patterns to understand if this change could impact existing code.
Let's check the actual usage context in the parent component to understand how the options prop is being used.
The options prop default value change is safe to proceed
The change from () => {} to () => ({}) in ToolbarBaseIcon is safe because:
- ToolbarBaseIcon is only used within ToolbarBase.vue through dynamic component rendering (
getRender()). - When ToolbarBaseIcon is rendered, it inherits the state object which already includes the options from ToolbarBase's props.
- ToolbarBase itself has proper type checking for the options prop and handles optional chaining correctly (
state.options?.collapsed). - The component is only rendered when
props.options.renderType === 'icon', which means options will always be an object when ToolbarBaseIcon is used.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Find all instances where ToolbarBaseIcon is used without explicit options
# to identify potential breaking changes
# Search for ToolbarBaseIcon usage without options prop
ast-grep --pattern '<ToolbarBaseIcon$$$></ToolbarBaseIcon>'
# Search for direct references to showDots
rg -A 5 'showDots.*ToolbarBaseIcon|ToolbarBaseIcon.*showDots'
Length of output: 125
Script:
#!/bin/bash
# Let's try a different approach to find usages of ToolbarBaseIcon
# Find the file path first
fd -t f "ToolbarBaseIcon.vue"
# Search for imports or requires of ToolbarBaseIcon
rg "import.*ToolbarBaseIcon|require.*ToolbarBaseIcon"
# Search for component usage with a broader pattern
rg -l "ToolbarBaseIcon"
# Look for any options prop usage
rg "options.*ToolbarBaseIcon|ToolbarBaseIcon.*options"
Length of output: 382
Script:
#!/bin/bash
# Let's examine how ToolbarBaseIcon is used in ToolbarBase.vue
cat packages/common/component/ToolbarBase.vue
Length of output: 1668
packages/plugins/materials/src/meta/layout/src/Main.vue (1)
59-59: Ensure proper fallback when defaultTabId is not found.
If props.registryData?.options?.defaultTabId is missing or not included in displayComponentIds, the code falls back to the first element in displayComponentIds. This may be undefined if the array is empty, which could lead to a null reference in subsequent logic. Consider providing a safer fallback or graceful handling when the array is empty.
- const activeTabId = displayComponentIds.find((item) => item === props.registryData?.options?.defaultTabId) || displayComponentIds[0]
+ const activeTabId = displayComponentIds.find((item) => item === props.registryData?.options?.defaultTabId)
+ || (displayComponentIds.length > 0 ? displayComponentIds[0] : null)packages/plugins/materials/src/composable/block-compile.js (1)
30-30: Ensure appSchemaState is initialized properly.
Switching the reference from resState to appSchemaState may cause issues if appSchemaState is undefined or slightly differs in structure. Verify that every usage of componentsMap handles potential undefined states and maintains consistent shape across the codebase.
Here is a script to locate the references in the codebase for additional verification:
✅ Verification successful
Let me search for the initialization and structure of appSchemaState.
Let me try a different approach to understand the initialization and usage of appSchemaState.
Based on the search results, I can now provide a conclusive response about the appSchemaState.componentsMap usage:
The componentsMap property is properly initialized and managed.
The code analysis reveals that:
componentsMapis initialized during app state fetching inuseResource.js:
appSchemaState.componentsMap = appData.componentsMap- It's a critical part of the application's schema used for:
- Code generation
- Component mapping and registration
- Block compilation
- The property is properly handled with fallbacks:
generatePageCode(schema, appData?.componentsMap || [], {...})The switch from resState to appSchemaState is safe as the initialization and usage patterns show proper handling of potential undefined states through optional chaining and default values.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that appSchemaState is properly defined and used
# Search usage of appSchemaState
rg -A 5 $'\\.appSchemaState'
Length of output: 11279
Script:
#!/bin/bash
# Search for appSchemaState initialization and structure
ast-grep --pattern 'appSchemaState = $_'
# Search for useResource definition and initialization
ast-grep --pattern 'const useResource = $_'
# Search for any type definitions or interfaces related to appSchemaState
rg -g '*.ts' -g '*.d.ts' 'appSchemaState'
Length of output: 241
Script:
#!/bin/bash
# Search for files that might initialize or define appSchemaState structure
rg -l "appSchemaState" --type js
# Look for the initialization of componentsMap specifically
rg "componentsMap" -A 5 -B 5
# Search for any schema or state initialization patterns
rg "initSchema|initState|createSchema|createState" --type js
Length of output: 59432
packages/settings/events/src/components/AdvanceConfig.vue (1)
138-138: Use of optional chaining enhances robustness
This change ensures that the code no longer breaks when schema.props is undefined, preventing potential runtime errors.
packages/common/component/MetaListItems.vue (1)
34-58: Verify feature parity between draggable and non-draggable modes.
The implementation maintains consistent props, events, and slots between both modes, which is good. However, since this is part of a release version bump (v2.1.0), ensure that:
- All events (
changeItem,deleteItem,editItem) work identically in both modes - Slots (
content,operate,metaForm,footer) render consistently - The
not-draggableclass correctly disables drag functionality
✅ Verification successful
Based on the search results, I can see that there are two implementations in MetaListItems.vue - one with the "not-draggable" class and one without it. I also see consistent event handler usage across components. Let me check the MetaListItem component implementation to verify the slot handling.
Based on the code inspection, I can now provide a final response:
Draggable and non-draggable modes maintain feature parity with consistent implementation
The code review confirms that both draggable and non-draggable modes:
- Use identical event handlers (
@changeItem,@deleteItem,@editItem) with consistent implementation - Render the same slots (
content,operate,metaForm,footer) without conditional logic - The
not-draggableclass is properly applied to disable drag functionality while preserving all other features
The only difference between modes is the presence of the not-draggable CSS class, which disables the drag interaction while maintaining all other functionality. This ensures a consistent user experience regardless of mode.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify consistent usage of events and slots across the codebase
# Check for any custom event handlers specific to draggable/non-draggable modes
rg -A 2 "(@changeItem|@deleteItem|@editItem)" --type vue
# Check for any conditional slot rendering based on draggable prop
rg -A 2 "(slot.*content|slot.*operate|slot.*metaForm|slot.*footer)" --type vue
# Check for any special handling of the not-draggable class
rg -A 2 "not-draggable" --type vue
Length of output: 258
Script:
#!/bin/bash
# Description: Verify consistent usage of events and slots across the codebase
# Check for any custom event handlers specific to draggable/non-draggable modes
rg -A 2 "(@changeItem|@deleteItem|@editItem)"
# Check for any conditional slot rendering based on draggable prop
rg -A 2 "(slot.*content|slot.*operate|slot.*metaForm|slot.*footer)"
# Check for any special handling of the not-draggable class
rg -A 2 "not-draggable"
# Check for draggable-related props or computed properties
rg -A 2 "draggable"
# Look for the MetaListItem component definition
fd -e vue MetaListItem
Length of output: 66432
Script:
#!/bin/bash
# Check for MetaListItem component implementation
ast-grep --pattern $'class="option-item not-draggable"'
# Look for draggable-related props and computed properties
ast-grep --pattern $'props: {
$$$
draggable: {
$$$
}
$$$
}'
# Check for draggable-related event handlers
ast-grep --pattern $'@changeItem="$_"'
ast-grep --pattern $'@deleteItem="$_"'
ast-grep --pattern $'@editItem="$_"'
# Look for slot implementations
ast-grep --pattern $'<template #content>
$$$
</template>'
ast-grep --pattern $'<template #operate>
$$$
</template>'
ast-grep --pattern $'<template #metaForm>
$$$
</template>'
ast-grep --pattern $'<template #footer>
$$$
</template>'
Length of output: 491
Script:
#!/bin/bash
# Search for MetaListItem component implementation and its usage
rg -U "class=\"option-item.*?\"" --multiline
# Look for draggable-related props and event handlers
rg -U "props:\s*{[^}]*draggable[^}]*}" --multiline
# Check for event handler implementations
rg -U "@(changeItem|deleteItem|editItem)=\"[^\"]*\"" --multiline
# Look for slot implementations and usage
rg -U "<template\s+#(content|operate|metaForm|footer)>[^<]*</template>" --multiline
# Find the MetaListItem component file
fd "MetaListItem.vue"
Length of output: 2049
Script:
#!/bin/bash
# Check MetaListItem.vue content
cat packages/common/component/MetaListItem.vue
# Look for any conditional slot rendering based on draggable mode
rg -U "v-if.*draggable.*template" --multiline
# Check for any draggable-specific event handling
rg -U "methods:\s*{[^}]*change[^}]*}" --multiline
Length of output: 8046
packages/common/component/MetaCodeEditor.vue (1)
258-259: Utilize locale more seamlessly or conditionally if needed.
The locale property is introduced to improve i18n, but ensure it’s being utilized consistently across the component or injected where needed to fully localize the editor’s content and UI elements.
packages/plugins/i18n/src/Main.vue (1)
117-117: Conditional display of search-empty.
Switching to v-else ensures the component is shown only when loading completes. Validate that no edge case causes the element to remain hidden incorrectly (e.g., isLoading but no records).
packages/block-compiler/package.json (2)
3-3: Updated version to 2.1.0-rc.0.
This reflects a pre-release version aligned with the rest of the repository’s coordinated updates. Looks good.
45-46: Order of peer dependencies changed.
The updated order shouldn’t affect functionality, but verify that any scripts or tooling expecting a certain order remain unaffected. No breaking changes detected.
packages/webcomponent/package.json (1)
3-3: Version bump to 2.1.0-rc.0.
Consistent with the wider project’s release candidate updates. No issues noted.
packages/i18n/package.json (1)
3-3: Verify version strategy: PR title indicates final release but introduces RC version
The PR is titled "Release/v2.1.0" but introduces a release candidate version 2.1.0-rc.0. Please clarify if this is intentional or if this should be the final 2.1.0 release.
Run this script to check version consistency across all packages:
| run: npx eslint ${{steps.get_changed_files.outputs.all_changed_files}} | ||
| - name: Run Build | ||
| run: pnpm run build:plugin && pnpm run build:alpha > build-alpha.log 2>&1 |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Add error handling and fail-fast for build steps
The build steps could benefit from improved error handling:
- ESLint step should fail if no files are found to lint
- Build step combines two commands where failures in the first might be masked
- - name: Run Build
- run: pnpm run build:plugin && pnpm run build:alpha > build-alpha.log 2>&1
+ - name: Build Plugin
+ run: pnpm run build:plugin
+ - name: Build Alpha
+ run: pnpm run build:alpha 2>&1 | tee build-alpha.log📝 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.
| run: npx eslint ${{steps.get_changed_files.outputs.all_changed_files}} | |
| - name: Run Build | |
| run: pnpm run build:plugin && pnpm run build:alpha > build-alpha.log 2>&1 | |
| run: npx eslint ${{steps.get_changed_files.outputs.all_changed_files}} | |
| - name: Build Plugin | |
| run: pnpm run build:plugin | |
| - name: Build Alpha | |
| run: pnpm run build:alpha 2>&1 | tee build-alpha.log |
| @@ -205,7 +205,7 @@ export default { | |||
| emits: ['click', 'iconClick', 'add', 'deleteBlock', 'openVersionPanel', 'editBlock', 'checkAll', 'cancelCheckAll'], | |||
| setup(props, { emit }) { | |||
| const panelState = inject('panelState', {}) | |||
| const blockUsers = inject('blockUsers') | |||
| const blockUsers = inject('blockUsers', []) | |||
There was a problem hiding this comment.
💡 Codebase verification
🛠️ Refactor suggestion
Align blockUsers injection with parent's ref type
The parent component BlockGroupPanel.vue provides blockUsers as a ref([]). The current injection with a plain array fallback should be updated to match this type:
-const blockUsers = inject('blockUsers', [])
+import { ref } from 'vue'
+const blockUsers = inject('blockUsers', ref([]))🔗 Analysis chain
Double-check fallback type for blockUsers injection
Here, blockUsers is injected with a default array, but the subsequent usage (blockUsers?.value) suggests it might be a ref. If your parent component provides a ref([]), then injecting a raw array as the fallback won’t match the structure. To ensure consistent reactivity, consider aligning the fallback type with how you consume blockUsers:
-const blockUsers = inject('blockUsers', [])
+import { ref } from 'vue'
+const blockUsers = inject('blockUsers', ref([]))Would you like to verify whether the parent provides blockUsers as a ref or a plain array?
Let me gather information about how blockUsers is provided in the parent components.
Let me check how blockUsers is provided in BlockGroupPanel.vue.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for components providing 'blockUsers'
ast-grep --pattern 'provide("blockUsers", $_)'
# Also search for components providing 'blockUsers' with string literal
ast-grep --pattern "provide('blockUsers', $_)"
# Search for any other variations of providing 'blockUsers'
rg -l "provide.*['\"]blockUsers['\"]"
Length of output: 236
Script:
#!/bin/bash
# Get the content around the provide statement in BlockGroupPanel.vue
rg -A 5 -B 5 "provide.*blockUsers" packages/plugins/materials/src/meta/block/src/BlockGroupPanel.vue
Length of output: 478
| type: [Number, String], | ||
| default: '63' |
There was a problem hiding this comment.
💡 Codebase verification
Based on the search results, I can now provide a final response:
The numeric string validation concern is valid and needs addressing
The getItemWidth function is used to calculate widths for tab items in the TabsGroupConfigurator component, which is imported and used by multiple style-related components. The current implementation:
const getItemWidth = (collapsed = false) => {
return `${parseInt(props.labelWidth, 10) + (collapsed ? 15 : 0)}`
}is used in template bindings:
:style="{ width: getItemWidth() + 'px' }"
:style="{ width: getItemWidth(true) + 'px' }"The suggested validation is important because:
- The component is widely used in the styling system (typography, layout, effects, size, background, border groups)
- Invalid width values could break the UI layout
- The current implementation silently returns 'NaNpx' for non-numeric strings
Recommended fixes:
- Implement the suggested validation to handle non-numeric inputs gracefully
- Add prop validation to warn developers about invalid inputs
- Document the expected format for the labelWidth prop
🔗 Analysis chain
Handle non-numeric string inputs carefully.
By changing labelWidth from a numeric type to [Number, String] with the default '63', we now rely on parseInt to interpret the value in getItemWidth(). Should a consumer pass “63px” or another string that partially or fully fails to parse as a number, the code may yield undesired results (e.g., generating NaN or silently ignoring suffixes). Consider checking for isNaN before returning the computed width or documenting that only numeric strings are supported.
Here is a snippet that validates numeric strings:
-const getItemWidth = (collapsed = false) => {
- return `${parseInt(props.labelWidth, 10) + (collapsed ? 15 : 0)}`
-}
+const getItemWidth = (collapsed = false) => {
+ const numericWidth = parseInt(props.labelWidth, 10)
+ if (Number.isNaN(numericWidth)) {
+ console.warn(
+ `[TabsGroupConfigurator] labelWidth prop is not a valid numeric value: ${props.labelWidth}`
+ )
+ return '0'
+ }
+ return `${numericWidth + (collapsed ? 15 : 0)}`
+}Let me gather more information about the usage and implementation of getItemWidth function.
Let me search for the implementation of getItemWidth and its usage to better understand the context.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Find the implementation of getItemWidth function
ast-grep --pattern 'const getItemWidth = $_'
# Search for any usages of labelWidth prop
rg "labelWidth" -A 3 -B 3
Length of output: 79390
Script:
#!/bin/bash
# Find the implementation and usage of getItemWidth
rg "getItemWidth" -A 5 -B 5
# Find any files that might be importing or using TabsGroupConfigurator
rg "TabsGroupConfigurator" -A 3 -B 3
Length of output: 15485
| @@ -1,6 +1,6 @@ | |||
| { | |||
| "name": "@opentiny/tiny-engine-dsl-vue", | |||
| "version": "2.0.0", | |||
| "version": "2.1.0-rc.0", | |||
There was a problem hiding this comment.
💡 Codebase verification
Vue version inconsistencies need to be addressed
The analysis reveals several critical version inconsistencies:
-
@opentiny/tiny-engine-dsl-vue(vue-generator):- Uses Vue ^3.4.15 but @vue/compiler-sfc 3.2.45
- Is a dependency of
@opentiny/tiny-engine-common
-
@opentiny/tiny-engine-layout(layout):- Uses Vue 3.2.45 (pinned)
- Is a dependency of
@opentiny/tiny-engine(design-core)
These mismatches are particularly concerning because:
- The packages are interconnected through workspace dependencies
- The Vue compiler version significantly lags behind the Vue runtime version
- Different packages are using incompatible Vue versions within the same monorepo
Recommendations:
- Update
@vue/compiler-sfcto version ^3.4.15 in@opentiny/tiny-engine-dsl-vueto match its Vue dependency - Update Vue to ^3.4.15 in
@opentiny/tiny-engine-layoutto maintain consistency with the rest of the ecosystem - Consider using workspace version management to ensure Vue-related dependencies stay in sync across packages
🔗 Analysis chain
Review Vue compiler and Vue version compatibility
The package uses Vue 3.4.15 but @vue/compiler-sfc is pinned to 3.2.45. This version mismatch between Vue and its compiler could lead to compatibility issues.
Run this script to check Vue-related dependency versions across the project:
Consider updating @vue/compiler-sfc to a version compatible with Vue 3.4.x to avoid potential compilation issues.
Also applies to: 32-33
Vue compiler version mismatch found in two packages
Based on the dependency analysis:
@opentiny/tiny-engine-dsl-vueuses Vue ^3.4.15 with compiler-sfc 3.2.45@opentiny/tiny-engine-layoutuses Vue 3.2.45 (pinned version)
This reveals two issues:
- The version mismatch in
tiny-engine-dsl-vuebetween Vue and its compiler could cause compatibility issues - The
tiny-engine-layoutpackage is using an older Vue version compared to the rest of the ecosystem
Let's verify if these packages have any direct dependencies on each other:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check Vue-related dependency versions for consistency
# Expected: Vue and its compiler versions should be compatible
echo "Checking Vue-related dependencies across all package.json files..."
fd --type f "package.json" --exec jq -r '. | select(.dependencies != null or .peerDependencies != null) |
"\(.name):\n Vue: \(.dependencies.vue // .peerDependencies.vue // "not specified")\n Compiler: \(.dependencies."@vue/compiler-sfc" // "not specified")"'
Length of output: 4580
Script:
#!/bin/bash
# Check dependencies between the affected packages
echo "Checking dependencies in tiny-engine-dsl-vue:"
jq -r '.dependencies, .peerDependencies' packages/tiny-engine-dsl-vue/package.json
echo -e "\nChecking dependencies in tiny-engine-layout:"
jq -r '.dependencies, .peerDependencies' packages/tiny-engine-layout/package.json
Length of output: 573
Script:
#!/bin/bash
# Find the actual package paths and check their dependencies
echo "Finding package locations..."
fd -t f "package.json" -x grep -l "tiny-engine-dsl-vue\|tiny-engine-layout" {}
echo -e "\nChecking package contents..."
fd -t f "package.json" -x sh -c 'if grep -q "tiny-engine-dsl-vue\|tiny-engine-layout" {}; then echo "=== {} ==="; cat {}; fi'
Length of output: 10319
* fix: time asc add i18n failed * fix: search invalid --------- Co-authored-by: hexqi <[email protected]>
* fix: basePropsGroup use deepclone prevent clone array itself basePropsGroup 使用深拷贝方式复制自身 * fix: filter duplicated property
* fix: generate code accessor scenario 修复 state accessor 出码的bug * fix: objectVal gettter value
* fix: breadcrumb publish block cannot get correct version * fix: block schema change sync * fix: del useless comment code * fix: hide publish block button when creating block
* fix: blockCompile get correct version * fix: support refresh block selected version * fix: clear all compileCache * fix: use correct version key to find history schema * fix: add id for stylesheet * fix: clean style sheet when remove cache * fix: should remove stylesheet before clean cache
English | 简体中文
PR
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
Background and solution
What is the current behavior?
Issue Number: N/A
What is the new behavior?
Does this PR introduce a breaking change?
Other information
Summary by CodeRabbit
Release Notes
New Features
changeGroupin theBlockGroupcomponent for improved interactivity.Bug Fixes
generateFnfunction to prevent runtime errors.Documentation
DesignCanvas.vueto clarify modal display logic.Version Updates
2.1.0-rc.0, indicating pre-release status.