v2.1.0 #963
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
|
Warning There were issues while running some tools. Please review the errors and either fix the tool’s configuration or disable the tool if it’s a critical failure. 🔧 eslint
packages/block-compiler/src/index.tsOops! Something went wrong! :( ESLint: 8.57.1 ESLint couldn't find the plugin "@typescript-eslint/eslint-plugin". (The package "@typescript-eslint/eslint-plugin" was not found when loaded as a Node module from the directory "/packages/block-compiler".) It's likely that the plugin isn't installed correctly. Try reinstalling by running the following: The plugin "@typescript-eslint/eslint-plugin" was referenced from the config file in "packages/block-compiler/.eslintrc.cjs". If you still can't figure out the problem, please stop by https://eslint.org/chat/help to chat with the team. WalkthroughThis pull request encompasses a comprehensive update across multiple packages in the project, primarily focusing on version increments from Changes
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:
packages/configurator/src/tabs-group-configurator/TabsGroupConfigurator.vue
Show resolved
Hide resolved
* 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
* fix: optimize save code button marker position * fix: resolve point style issues for page Schema and page JS
* fix: block switch select property failed * fix: del assignment
* fix: resolve block property issue * fix: block property form rename --------- Co-authored-by: hexqi <[email protected]>
…block error when type undefined (#988) * fix: preview breadcrumb don't exist useBlock method * fix: resolve block preview error when type is undefined --------- Co-authored-by: hexqi <[email protected]>
There was a problem hiding this comment.
Actionable comments posted: 1
🔭 Outside diff range comments (3)
packages/engine-cli/template/designer/package.json (1)
Documentation updates needed for version 2.1.0
The version upgrade to 2.1.0 requires documentation updates:
- The CHANGELOG.md is outdated (last entry is v1.0.0-alpha.0)
- The new
@opentiny/tiny-engine-utilspackage lacks documentation and description- No migration notes are available for the 2.1.0 release
Please provide:
- Update CHANGELOG.md with 2.1.0 release notes
- Add documentation for
@opentiny/tiny-engine-utilspackage including:
- Package description in package.json
- README.md with usage instructions
- If there are any breaking changes, include migration notes
🔗 Analysis chain
Line range hint
1-34: Document version upgrade changesWhile the version updates are consistent across packages, the PR objectives indicate that documentation hasn't been updated. Please provide:
- Changelog entries for the 2.1.0 release
- Migration notes if any breaking changes exist
- Documentation for the new
@opentiny/tiny-engine-utilspackage🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for changelog/migration docs fd -t f "CHANGELOG.md|MIGRATION.md|UPGRADING.md"Length of output: 63
Script:
#!/bin/bash # Check content of CHANGELOG.md for 2.1.0 release notes cat CHANGELOG.mdLength of output: 112
Script:
#!/bin/bash # Look for any documentation files related to @opentiny/tiny-engine-utils rg -g "*.md" -i "tiny-engine-utils"Length of output: 35
Script:
#!/bin/bash # Check if @opentiny/tiny-engine-utils existed in previous versions rg "@opentiny/tiny-engine-utils" -g "package*.json" -B2 -A2Length of output: 10693
Script:
#!/bin/bash # Check for documentation in the utils package fd -t f "README.md|index.md|docs" packages/utils/ # Also check package.json for description cat packages/utils/package.jsonLength of output: 935
Script:
#!/bin/bash # Look for any recent commits mentioning version 2.1.0 git log --oneline -n 10 | grep "2.1.0"Length of output: 0
packages/plugins/schema/src/Main.vue (1)
Tests needed for schema plugin functionality
Based on the verification results:
- The schema plugin lacks proper test coverage - the test files exist but are empty
- The existing schema-related tests in the codebase are focused on Vue SFC generation, not the schema plugin functionality
- The history stack TODO appears to be isolated to this component
To ensure reliability of the schema plugin, tests should cover:
- Schema saving functionality
- Schema validation
- Editor state management
- Schema import/export functionality
Locations needing attention:
packages/plugins/schema/test/test.js- Add test casespackages/plugins/schema/src/Main.vue- Track history stack TODO🔗 Analysis chain
Line range hint
1-247: Add tests and track TODOs.This PR is marked as a bugfix, but:
- Tests haven't been added as noted in the PR description
- There's a TODO comment about implementing history stack functionality
Would you like me to:
- Generate unit tests for the schema saving functionality?
- Create a GitHub issue to track the history stack implementation?
Run this script to check for existing tests:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for existing test files related to schema functionality # Look for test files fd -e spec.js -e test.js -e spec.ts -e test.ts . | grep -i "schema" # Look for TODO comments related to history functionality rg -i "todo.*history" --type vue --type js --type tsLength of output: 150
Script:
#!/bin/bash # Let's try a different approach to search for tests and TODOs # Search for test files using ripgrep echo "=== Searching for schema-related test files ===" rg -l "schema" -g "*.{spec,test}.{js,ts,jsx,tsx}" echo -e "\n=== Searching for TODO comments about history ===" # Search for TODO comments about history in all relevant files rg -i "todo.*history" --type js --type ts --type jsx --type tsx echo -e "\n=== Checking if this is the only file with history stack TODO ===" rg "history.*stack" --type js --type ts --type jsx --type tsxLength of output: 1201
Script:
#!/bin/bash # Let's examine the existing schema tests to see if they cover our functionality echo "=== Checking content of schema-related test files ===" for file in $(rg -l "schema" -g "*.test.js" packages/vue-generator/test/); do echo -e "\n=== Content of $file ===" head -n 20 "$file" done echo -e "\n=== Looking for schema plugin tests specifically ===" rg -l "schema.*plugin" -g "*.{js,ts}" echo -e "\n=== Checking for any existing test setup in the schema plugin directory ===" fd . packages/plugins/schema/ -t fLength of output: 9383
Script:
#!/bin/bash # Let's check the content of the schema plugin's test file and mock data echo "=== Checking schema plugin test content ===" cat packages/plugins/schema/test/test.js echo -e "\n=== Checking mock data ===" cat packages/plugins/schema/mock/test.js echo -e "\n=== Looking for any vitest/jest config ===" rg -l "vitest|jest" packages/plugins/schema/Length of output: 399
packages/canvas/render/src/builtin/builtin.json (1)
Schema standardization needs additional updates
The verification shows that while the main
builtin.jsonin the canvas package has been updated to use lowercase types (e.g., "string", "boolean"), there are still many files across the codebase that use uppercase type definitions. These need to be addressed for consistency:
- Test files in
packages/vue-generator/test/testcases/contain uppercase types- Mock files in
mockServer/,designer-demo/, and other locations use uppercase types- Schema files in
packages/settings/design/src/schemas/need updatesRecommendations:
- Update all schema files to use lowercase types consistently
- Include test and mock files in the type standardization
- Add a linting rule to enforce lowercase type definitions in JSON schema files
🔗 Analysis chain
Line range hint
1-558: Overall Assessment: Schema standardization looks goodAll type definitions have been consistently standardized from uppercase to lowercase across all components, following JSON Schema conventions. While these changes don't affect runtime behavior, they represent a breaking change in the schema definition.
Recommendations:
- Update the PR description to indicate this is a breaking change in the schema
- Add a migration guide for custom component authors
- Consider adding tests to verify schema compliance
Let me help verify the completeness of these changes:
The previous results show that there are still many uppercase type definitions across the codebase, particularly in mock and test files. Let's verify if the main schema files in the canvas package (which is the focus of the PR) have been properly updated and if there are any other schema files that need attention.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Verify no uppercase type definitions remain echo "Checking for any remaining uppercase type definitions..." rg '"type":\s*"(String|Boolean|Number|Object|Array)"' --type json # Check for any custom component definitions that might need updates echo "Checking for custom component definitions..." rg '"componentName":\s*"(Slot|Collection|Text|Icon|Img)"' --type json --type typescript --type javascriptLength of output: 22916
Script:
#!/bin/bash # Let's check the schema files in the canvas package specifically echo "Checking schema files in canvas package..." fd -e json -e schema.json . packages/canvas # Let's also check if there are any other schema files that might need updates echo "Checking all schema files..." fd -e schema.json . # Let's verify the type definitions in the canvas package echo "Checking type definitions in canvas package..." rg '"type":\s*"[a-z]' packages/canvas --type jsonLength of output: 5418
🧹 Nitpick comments (17)
packages/engine-cli/template/designer/public/mock/bundle.json (2)
4831-4937: LGTM! New TinyLayout component implementation looks good.The component is well structured with proper configuration for layout management. The nesting rules for TinyRow and TinyCol components are correctly defined.
Consider adding these improvements:
- Enhance the component description to better explain its layout capabilities
- Add validation for the
colsproperty to ensure it only accepts 12 or 24- Consider adding responsive layout properties (xs, sm, md, lg, xl)
"description": "定义 Layout 的行配置信息", +"description": "Layout component for defining grid-based responsive layouts with support for 12/24 column systems", "cols": { "widget": { "component": "ButtonGroupConfigurator", "props": { "options": [ { "label": "12", "value": 12 }, { "label": "24", "value": 24 } ] } } }, +"responsive": { + "xs": { "type": "number", "description": "Columns for extra small screens (<768px)" }, + "sm": { "type": "number", "description": "Columns for small screens (≥768px)" }, + "md": { "type": "number", "description": "Columns for medium screens (≥992px)" }, + "lg": { "type": "number", "description": "Columns for large screens (≥1200px)" }, + "xl": { "type": "number", "description": "Columns for extra large screens (≥1920px)" } +}
4921-4922: Enhance nesting rule documentation.The nesting rules are correctly configured but would benefit from clearer documentation about allowed child components.
"childWhitelist": ["TinyRow", "TinyCol"], +"childWhitelist": ["TinyRow", "TinyCol"], // Only TinyRow and TinyCol components can be nested inside TinyLayoutpackages/plugins/schema/src/Main.vue (2)
105-109: LGTM! Consider enhancing error handling.The changes correctly integrate the canvas state management by using
importSchemaandsetSaved. The order of operations is logical.Consider wrapping the schema import in a try-catch block to handle potential runtime errors:
const { importSchema, setSaved } = useCanvas() - importSchema(value) - setSaved(false) + try { + importSchema(value) + setSaved(false) + } catch (error) { + useNotify({ + type: 'error', + title: 'Schema import failed', + message: error.message + }) + return + }
207-215: LGTM! Consider adding ARIA attributes for accessibility.The red indicator styling is well-implemented with appropriate dimensions and positioning. The use of CSS variables for colors maintains theme consistency.
Consider adding ARIA attributes to improve accessibility for screen readers:
<span class="icon-wrap" @click="saveSchema"> - <i v-show="!showRed" class="red"></i> + <i v-show="!showRed" class="red" role="status" aria-label="Unsaved changes"></i> <tiny-button type="primary">保存</tiny-button> </span>packages/settings/props/src/composable/useProperty.js (1)
28-28: Consider using the spread operator for a more idiomatic assignment.While
Object.assignis valid, you could improve readability and avoid potential side effects by using the object spread syntax:- Object.assign(property, { - linked, - widget: { - props: { - modelValue: { - type: SCHEMA_DATA_TYPE.JSExpression, - value: `this.props.${linked.blockProperty}` - } - } - } - }) + property = { + ...property, + linked, + widget: { + props: { + modelValue: { + type: SCHEMA_DATA_TYPE.JSExpression, + value: `this.props.${linked.blockProperty}` + } + } + } + }packages/block-compiler/src/index.ts (1)
89-89: Handle undefined or malformed file names gracefully.When injecting code via string concatenation, consider validating or sanitizing
fileNameto avoid potential edge cases (e.g., invalid or empty filenames) that could break your build or cause runtime issues. Introducing checks or fallback logic prior to code generation could make this more robust.packages/engine-cli/template/designer/src/composable/http/index.js (4)
12-17: Consider renaming "procession" for clarity.
The object name “procession” may not clearly convey its purpose. A more descriptive name (e.g.,loginSession) might improve readability.
18-24: Ensure no sensitive user data is logged.
showErrornotifies errors, but be cautious about potentially sensitive information inmessage. If security constraints exist, filter or sanitize the content before displaying it.
43-48: Consider preserving full response for debug.
preResponseonly returnsres.data?.dataor rejects if there's anerror. If partial data is needed for diagnostics, consider returning the entire response or storing it in logs.
52-81: Assess concurrency control for openLogin.
If multiple 401 responses triggeropenLoginsimultaneously, only the first call setsprocession.promiseLogin. Subsequent calls wait but share the same resource, which can be fragile. Evaluate concurrency handling or a global session manager to prevent potential race conditions.packages/common/component/BlockDeployDialog.vue (4)
108-109: Document emitted events
The newchangeSchemaevent and theupdate:visibleevent work well. Consider adding brief JSDoc-style comments for these emits to clarify their usage.
162-168: Re-initialize fields when dialog opens
Watchingprops.visibleto setformState.versionis a clear approach. Ensure that other fields (e.g.deployInfo) are also reset if needed, especially if the dialog can reopen multiple times without a full component re-mount.
197-199: Ensure asynchronous error handling
When fetchingremoteviaapi.getBlockById(block?.id), consider handling network or parsing errors. The current code is good, but a try/catch could provide a more robust user-facing error message if needed.
227-228: Handling JSON parse results
EmittingchangeSchemawithin the try/catch is good for error containment. Consider logging the error details in the catch block for improved debugging.packages/plugins/block/src/js/blockSetting.jsx (1)
425-434: Concurrent state updates
MultipleObject.assigncalls mergenewBlockdata into bothblockand the currently edited block. This can effectively keep the state in sync, but be mindful of potential side effects if other watchers rely on the old references.packages/plugins/materials/src/meta/block/index.js (1)
9-10: Document additional API methods
Listing bothfetchGroupsandfetchGroupBlocksByIdsinapisis coherent. Ensure these new exports are included in any official documentation or type definitions to keep references up to date.packages/toolbars/breadcrumb/src/Main.vue (1)
80-81: Consider validatinguseBlockcalls before accessing methods.While optional chaining avoids errors when
useBlockreturns undefined, consider ensuring thatuseBlock()is always defined and not null for improved clarity.- const currentBlock = computed(() => useBlock?.()?.getCurrentBlock?.()) + const currentBlock = computed(() => { + const blockApi = useBlock() + return blockApi ? blockApi.getCurrentBlock() : null + })
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (82)
designer-demo/package.json(1 hunks)mockServer/package.json(1 hunks)packages/block-compiler/package.json(2 hunks)packages/block-compiler/src/index.ts(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/container/src/container.js(1 hunks)packages/canvas/package.json(1 hunks)packages/canvas/render/src/RenderMain.js(2 hunks)packages/canvas/render/src/builtin/builtin.json(8 hunks)packages/canvas/render/src/render.js(2 hunks)packages/common/component/BlockDeployDialog.vue(6 hunks)packages/common/component/PluginSetting.vue(1 hunks)packages/common/component/toolbar-built-in/ToolbarBaseButton.vue(2 hunks)packages/common/package.json(1 hunks)packages/configurator/package.json(1 hunks)packages/design-core/package.json(1 hunks)packages/engine-cli/package.json(1 hunks)packages/engine-cli/template/designer/package.json(1 hunks)packages/engine-cli/template/designer/public/mock/bundle.json(2 hunks)packages/engine-cli/template/designer/registry.js(1 hunks)packages/engine-cli/template/designer/src/composable/http/Login.vue(1 hunks)packages/engine-cli/template/designer/src/composable/http/index.js(1 hunks)packages/engine-cli/template/designer/src/preview.js(2 hunks)packages/i18n/package.json(1 hunks)packages/layout/package.json(1 hunks)packages/plugins/block/package.json(1 hunks)packages/plugins/block/src/BlockPropertyForm.vue(2 hunks)packages/plugins/block/src/BlockSetting.vue(4 hunks)packages/plugins/block/src/composable/useBlock.js(1 hunks)packages/plugins/block/src/js/blockSetting.jsx(2 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(3 hunks)packages/plugins/materials/package.json(1 hunks)packages/plugins/materials/src/composable/block-compile.js(4 hunks)packages/plugins/materials/src/composable/useMaterial.js(2 hunks)packages/plugins/materials/src/meta/block/index.js(1 hunks)packages/plugins/materials/src/meta/block/src/BlockGroup.vue(4 hunks)packages/plugins/materials/src/meta/block/src/BlockVersionSelect.vue(1 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(3 hunks)packages/plugins/script/package.json(1 hunks)packages/plugins/script/src/Main.vue(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/panel/package.json(1 hunks)packages/settings/props/package.json(1 hunks)packages/settings/props/src/composable/useProperty.js(1 hunks)packages/settings/styles/package.json(1 hunks)packages/svgs/package.json(1 hunks)packages/theme/base/package.json(1 hunks)packages/theme/base/src/component-common.less(3 hunks)packages/theme/dark/package.json(1 hunks)packages/theme/light/package.json(1 hunks)packages/toolbars/breadcrumb/package.json(1 hunks)packages/toolbars/breadcrumb/src/Main.vue(2 hunks)packages/toolbars/breadcrumb/src/composable/useBreadcrumb.js(1 hunks)packages/toolbars/clean/package.json(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)
⛔ Files not processed due to max files limit (9)
- packages/toolbars/setting/package.json
- packages/utils/package.json
- packages/vue-generator/package.json
- packages/vue-generator/src/generator/vue/sfc/generateAttribute.js
- packages/vue-generator/src/generator/vue/sfc/generateScript.js
- packages/vue-generator/test/testcases/sfc/accessor/accessor.test.js
- packages/vue-generator/test/testcases/sfc/accessor/expected/Accessor.vue
- packages/vue-generator/test/testcases/sfc/accessor/schema.json
- packages/webcomponent/package.json
✅ Files skipped from review due to trivial changes (3)
- packages/common/component/PluginSetting.vue
- packages/engine-cli/template/designer/registry.js
- packages/canvas/container/src/container.js
🚧 Files skipped from review as they are similar to previous changes (56)
- packages/theme/dark/package.json
- packages/theme/base/package.json
- packages/toolbars/lang/package.json
- packages/toolbars/collaboration/package.json
- packages/configurator/package.json
- packages/plugins/tutorial/package.json
- packages/toolbars/media/package.json
- packages/common/package.json
- packages/plugins/bridge/package.json
- packages/toolbars/fullscreen/package.json
- packages/engine-cli/package.json
- packages/toolbars/lock/package.json
- packages/plugins/datasource/package.json
- packages/svgs/package.json
- packages/plugins/schema/package.json
- packages/plugins/tree/package.json
- packages/settings/panel/package.json
- packages/toolbars/logout/package.json
- packages/toolbars/preview/package.json
- packages/builtinComponent/package.json
- packages/plugins/page/package.json
- packages/plugins/materials/package.json
- packages/toolbars/layout/package.json
- packages/plugins/state/package.json
- packages/layout/package.json
- packages/plugins/help/package.json
- packages/theme/light/package.json
- packages/toolbars/generate-code/package.json
- packages/canvas/package.json
- packages/settings/design/package.json
- packages/toolbars/save/package.json
- packages/toolbars/clean/package.json
- designer-demo/package.json
- packages/register/package.json
- packages/settings/events/package.json
- packages/blockToWebComponentTemplate/package.json
- packages/toolbars/logo/package.json
- packages/plugins/robot/package.json
- packages/plugins/i18n/package.json
- packages/plugins/script/package.json
- packages/toolbars/breadcrumb/package.json
- packages/toolbars/refresh/package.json
- packages/build/vite-plugin-meta-comments/package.json
- packages/settings/props/package.json
- packages/toolbars/redoundo/package.json
- packages/design-core/package.json
- packages/settings/styles/package.json
- packages/plugins/block/package.json
- packages/plugins/materials/src/meta/block/src/BlockGroup.vue
- packages/common/component/toolbar-built-in/ToolbarBaseButton.vue
- packages/build/vite-config/package.json
- mockServer/package.json
- packages/i18n/package.json
- packages/canvas/render/src/render.js
- packages/block-compiler/package.json
- packages/plugins/i18n/src/Main.vue
🔇 Additional comments (61)
packages/plugins/block/src/BlockPropertyForm.vue (3)
8-8: Great label clarification.Changing the label to "属性名(ID)" clearly conveys that it can serve both as a property name and an identifier.
11-11: Improved descriptive label.Renaming "值类型" to "属性值类型" provides a clearer indication of the field's purpose.
85-85: Clearer semantics.Using "属性显示名" instead of a generic descriptor better communicates the field's role.
packages/theme/base/src/component-common.less (2)
504-504: Confirm reduced padding maintains visual hierarchy.The padding reduction from 42px to 20px in both numeric input scenarios affects:
- The space available for the controls (increase/decrease buttons)
- The alignment of the unit indicator
Please ensure these changes:
- Don't cause overflow of the numeric controls
- Maintain proper spacing for the unit indicator
- Align with the design system's spacing guidelines
Also applies to: 525-525
✅ Verification successful
Let me gather more information about the numeric input component's structure and related styles.
The padding changes are consistent with the component's design
Based on the verification of the styles, the padding reduction is actually well-aligned with the component's structure:
- The numeric controls (increase/decrease buttons) are 14px wide with a border, which fits comfortably within the 20px right padding
- The unit indicator has a defined width of 14px with a 4px right margin, also accommodating well within the padding space
- The left padding remains unchanged at 12px, maintaining the text alignment
- The same padding values (20px right, 12px left) are consistently applied in both control scenarios: with controls-right and with unit
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any related numeric input styles that might be affected # by this padding change # Search for related numeric input styles rg -A 5 "tiny-numeric__input.*padding|tiny-numeric__controls|tiny-numeric__unit"Length of output: 1433
Script:
#!/bin/bash # Search for the complete numeric input component structure and styles rg -A 10 "tiny-numeric" packages/theme/base/src/component-common.lessLength of output: 1352
15-17: Verify the select dropdown icon alignment.The added
padding-right: 30pxensures space for the dropdown icon, but please verify that this value maintains proper alignment with the caret icon (.tiny-select__caret).✅ Verification successful
Based on the search results, I can now provide a definitive response about the padding-right adjustment for the select input:
The padding-right value of 30px is consistent with existing select component styles.
The search results show that:
- The value of 30px for padding-right is already being used in other select-related styles (e.g., in
.tiny-toggle-menu .tiny-input__innerand.tiny-input-suffix .tiny-input__inner)- The select component has specific caret icon styling with defined color variables and font sizes
- The padding ensures proper spacing for the caret icon which is a crucial part of the select component's visual design
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check if there are any existing padding-right declarations for .tiny-input__inner # that might conflict with this new style rg -A 2 "tiny-input__inner.*padding-right"Length of output: 44
Script:
#!/bin/bash # Let's check for any existing styles related to tiny-input__inner and tiny-select__caret # to understand the layout relationship rg "tiny-(input__inner|select__caret)" -A 3Length of output: 34436
Script:
#!/bin/bash # Let's also check for any other padding declarations for tiny-input__inner # to get a complete picture of the spacing rg "\.tiny-input__inner\s*{[^}]*}" --multilineLength of output: 183
Script:
#!/bin/bash # Let's look for any select-related styles that might affect the icon positioning # This will help us understand the overall select component layout ast-grep --pattern '.tiny-select { $$$ }'Length of output: 1919
packages/engine-cli/template/designer/package.json (2)
28-29: Add tests for version upgradeThe PR objectives indicate that tests haven't been added. Please add appropriate tests to verify the compatibility and functionality with the upgraded package versions.
Would you like me to help create a test plan or open a GitHub issue to track this requirement?
14-17: Verify documentation for the new tiny-engine-utils packageThe addition of
@opentiny/tiny-engine-utils@^2.1.0needs proper documentation to help users understand its purpose and usage.packages/block-compiler/src/index.ts (1)
61-61: Confirm the existence of the global function.By defaulting
globalGetterNametoloadBlockComponent, this code relies onwindow.loadBlockComponentbeing defined at runtime. Ensure there is a corresponding global function or fallback mechanism to prevent possible runtime errors.✅ Verification successful
Let me check the implementation of
loadBlockComponentto understand how it's defined and used.
The global function
loadBlockComponentis properly defined and exposedThe code in
packages/canvas/render/src/render.jsshows that:
loadBlockComponentis defined as an async function that handles component loading- It's explicitly assigned to
window.loadBlockComponent, making it globally available- The function is actively used in the codebase for dynamic component loading
Therefore, the default value in
resolveRelativeImportcorrectly relies on an existing global function.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify definitions or usage references to window.loadBlockComponent # Searching for loadBlockComponent usage across the repository rg "loadBlockComponent"Length of output: 416
Script:
#!/bin/bash # Get the implementation context of loadBlockComponent rg "loadBlockComponent" packages/canvas/render/src/render.js -B 2 -A 5Length of output: 555
packages/toolbars/breadcrumb/src/composable/useBreadcrumb.js (1)
26-27: Confirm usage of the updated function signature.By removing the
historiesparameter, any external code passing that argument will break. Verify that all calls tosetBreadcrumbBlockhave been updated accordingly to avoid runtime errors or unexpected behavior.packages/plugins/block/src/composable/useBlock.js (1)
290-290: Validate removal ofhistoriesreference.This change reflects the updated
setBreadcrumbBlocksignature. Ensure thatblock.historiesis no longer needed or used elsewhere. If a block's history is still relevant, consider providing an alternative approach to track it.packages/engine-cli/template/designer/src/composable/http/index.js (6)
1-11: Imports and constants look cohesive.
The usage ofcreateApp,HttpService,useBroadcastChannel, andconstantsis consistent. No immediate concerns regarding naming or side effects.
27-38: Verify overlapping environment conditions.
preRequestassigns an emptybaseURLfor dev environment and again ifwindow.vscodeBridgeis detected. Confirm whether these conditions are distinct or could conflict.
82-101: Validate additional error status codes.
errorResponsechecks for a 401 status and attempts a login flow or resolves directly in a VSCode environment. Confirm that other HTTP error scenarios are handled appropriately to avoid masking legitimate failures or user-facing confusion.
105-116: Handle missing tenant ID gracefully.
getTenant()may returnnull. Ifx-lowcode-orgexpects a valid tenant, consider omitting the header or providing a default identifier to avoid downstream issues.
121-133: Configuration approach is well-structured.
Encapsulating interceptors and configuration incustomizeHttpServiceis clean. It centralizes HTTP logic, improving maintainability and reusability.
135-135: Exporting a pre-configured service is convenient.
Default-exportingcustomizeHttpService()ensures all modules share the same configuration, simplifying usage across the codebase.packages/engine-cli/template/designer/src/preview.js (2)
17-17: Importing HttpService for preview environment.
The new import indicates thatHttpServiceis now part of the engine’s preview lifecycle. Confirm there are no circular dependencies with the composable index.
27-27: Registering HttpService in metas.
By addingHttpServiceto themetasarray, the preview environment can leverage new login or request functionalities. Ensure the correct initialization order so the service is fully available when needed.packages/engine-cli/template/designer/src/composable/http/Login.vue (3)
1-9: Proper structure for SSO popup template.
The conditional rendering of the login wrapper and an iframe is straightforward and flexible for an SSO flow. Make sure the displayed URL is properly sanitized if it can be influenced by untrusted sources.
11-41: Reactive login methods support async flows.
openLoginreturns a Promise that resolves or rejects based onmePromise. This pattern effectively centralizes the login flow. Just ensure concurrency or repeated calls remain stable.
43-83: Styling is clean and localized.
Scoped LESS styles provide a clear presentation for the popup. The usage oftransform: translate(-50%, -50%)centers the modal effectively. Overall design approach is appropriate.packages/common/component/BlockDeployDialog.vue (6)
3-3: Ensure prop-based visibility flow is complete
Now thattiny-dialog-boxreceives:visible="visible"from the prop, confirm that any previously used$attrs.visiblewatchers or references have been removed or updated to prevent conflicts.
83-83: Import usage
All imported functions (useNotify,getMetaApi, andMETA_APP) appear to be used correctly throughout. This import line is fine.
99-105: Validateblockprop usage
Definingblockas an object with a default is helpful, but consider settingrequired: trueif the component always needs a block. Also verify if references toblock.historieshandle edge cases where no histories are present.
144-159: Edge case handling in version calculation
getNextVersiondefaults to1.0.0if no valid version is found, then increments the patch number. Ensure thatbackupListis never null or undefined, and handle any malformed versions (non-X.Y.Z format) that could break the regex replacement.
176-180: Check for block ID existence
When constructingpublishBlockparams, confirm thatprops.block.idexists to avoid server-side errors if the block is not yet stored.
204-204: Comparing local schema
Assigningstate.codeto the local block content is clear. Confirm that large block content does not cause performance or memory issues in the diff editor.packages/plugins/block/src/js/blockSetting.jsx (3)
422-422: Null check onpublic_scope_tenants
When verifyingif (newBlock?.public_scope_tenants?.length), ensurepublic_scope_tenantsis always an array. Otherwise, consider a safe default or additional null checks to avoid runtime errors.
740-748: Switching request functions
UsingupdateGrouporupdateCategorydepending onreplaceCategoryWithGroupis concise. Confirm that any failing requests are handled gracefully, and consider a fallback UI or error message.
751-755: Creating new category or group
WhenisEditis false, your code switches tocreateGrouporcreateCategory. Ensure thatparams.category_id = categoryIdis only set when dealing with categories. Good approach for reusing function parameters.packages/plugins/materials/src/meta/block/index.js (1)
3-3: Expand usage of new API
fetchGroupBlocksByIdsis newly imported. Confirm that all call sites are properly updated to utilize it, and that user flows are tested to avoid unexpected 404 or undefined behaviors when blocks are fetched by ID.packages/plugins/script/src/Main.vue (1)
152-158: Adjusted .dots styling
Decreasing the size and shifting its position slightly can improve or reduce visibility. Validate this change with design requirements to ensure the error indicator remains noticeable.packages/plugins/materials/src/meta/block/src/BlockVersionSelect.vue (1)
91-91: Refresh compile cache on version rollback
CallinguseMaterial().updateBlockCompileCache()after changing the block version ensures an up-to-date environment. Confirm that any watchers dependent on the old block version also re-initialize appropriately.packages/toolbars/breadcrumb/src/Main.vue (5)
20-20: Conditionally show "发布区块" button only if a block is selected.Nice use of optional chaining for
currentBlock?.id. This ensures the button only appears when a valid block is selected.
27-31: Prop and event usage with<block-deploy-dialog>looks consistent.Passing
:block="currentBlock"and handling thechangeSchemaevent are aligned with the new approach of managing the active block. Ensure that the dialog properly handles edge cases where no block is present.
39-39: New import ofuseBlockis appropriate.The import effectively brings in the block composable to retrieve the current block.
82-84: Ensure schema replacement is properly handled.
handleChangeSchemafully replaces the block content withnewSchema. Validate that any existing fields or partial changes are not accidentally lost.
91-93: No concerns returning these properties from setup.Exposing
open,currentBlock, andhandleChangeSchemaprovides a clear API for the template.packages/plugins/block/src/BlockSetting.vue (5)
78-82: New usage of<block-deploy-dialog>is consistent with the shared schema change logic.Passing
publishBlockand handlingchangeSchemaunifies the block deployment workflow across components.
88-88: ImportinguseBlockanduseModalfosters a cohesive setup.No issues found. This import aligns with the code’s need to manage block data and modal dialogs.
262-267: Selective schema update preserves independence for non-active blocks.When
getEditBlock().idmatchesuseBlock().getCurrentBlock().id, reimporting the schema is correct. Good approach!
283-285: Exposing the new methods is consistent with existing pattern.Returning
handleShowGuide,handleChangeSchema, andpublishBlockfrom the setup fosters reusability with minimal duplication.
142-151: Validate block identity check inpublishBlockcomputed.Comparing
currentBlock.idwithcurrentEditBlock.idis sensible, but ensure that these references do not desynchronize in complex editing.✅ Verification successful
Let me generate additional verification scripts to check the block synchronization logic more thoroughly.
Block synchronization logic is properly implemented
The verification shows that the block identity check in
publishBlockcomputed property is safe and properly synchronized. Here's why:
- The
currentBlockis obtained fromuseBlock().getCurrentBlock()which represents the active block in the canvas- The
currentEditBlockfromgetEditBlock()represents the block being edited in the settings- The synchronization is maintained through:
setEditBlockwhich updates the edit state when a block is selectedinitBlockwhich properly initializes/updates both canvas and edit statesupdateBlockwhich saves changes and reinitializes both states- The ID comparison ensures the correct block instance is used for publishing
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check if multiple references to blocks might cause conflicts. # We look for all usage of publishBlock, currentBlock, currentEditBlock to see if there's any mismatch. rg -A 5 'publishBlock|currentBlock|currentEditBlock'Length of output: 9265
Script:
#!/bin/bash # Check the implementation of useBlock().getCurrentBlock() and getEditBlock() ast-grep --pattern 'function getCurrentBlock() { $$$ }' # Check setEditBlock implementation ast-grep --pattern 'function setEditBlock($_) { $$$ }' # Check for any block update or sync logic rg -A 5 'setEditBlock|initBlock|updateBlock'Length of output: 16642
packages/plugins/materials/src/composable/block-compile.js (9)
4-4: Use ofMapforblockVersionMapandblockCompileCacheis a good choice.
Mapoptimizes lookups for block versions and compiled results compared to plain objects.
7-23: Verify that all blocks have validfileNameandcurrent_version.When using
fetchGroupBlocksByIds, consider fallback behavior iffileNameorcurrent_versionis missing. This prevents undefined entries inblockVersionMap.
29-32: Clearing multiple caches at once can affect in-progress operations.Ensure that no other processes rely on
blockVersionMaporblockCompileCacheimmediately after clearing.
46-46: AccessingappSchemaState.componentsMapis consistent with new resource structure.Switching from
resStatetoappSchemaStateis aligned with updated code references.
49-50: Ensure correct relative path for block code generation.
blockRelativePath: './'is valid, but confirm it matches the actual directory hierarchy.
53-57: Single-object approach forblocksSourceCodesimplifies block compilation.Consolidating the source code into one object is efficient for the compiler interface.
67-71: Loading all group blocks on-demand is efficient.This lazy approach populates
blockVersionMaponly if needed. No issues found.
80-81: Ensure version retrieval logic aligns with block naming conventions.
const historyVersion = blockVersionMap.get(name)presumes the block name is the same as the file name inblockVersionMap. Confirm this is always consistent.
86-86: Conditional usage of history versus current schema is logical.Respecting
historyVersionfallback fosters comparison or rollback to prior versions.packages/plugins/materials/src/composable/useMaterial.js (4)
28-28: ImportingdeepClonefrom utils is a solid choice.Deep cloning guards against inadvertent mutations of shared data structures.
116-119: Filtered insertion prevents duplicate base properties.This check ensures each property is unique by matching
prop.property === item.property.
121-123: Conditional insertion position is a neat approach.Using
splicefor the start case andpushotherwise is straightforward. No issues found.
126-126: Appending a deep-cloned group if not found in existing properties.Preserves the original structure while ensuring broad reusability.
packages/canvas/render/src/builtin/builtin.json (5)
86-86: LGTM! Type definitions standardized for Slot componentThe type definitions for
nameandparamsproperties have been correctly standardized to lowercase, following JSON Schema conventions.Also applies to: 100-100
246-246: LGTM! Type definition standardized for Text componentThe type definition for the
textproperty has been correctly standardized to lowercase.
318-318: LGTM! Type definition standardized for Icon componentThe type definition for the
nameproperty has been correctly standardized to lowercase.
388-388: LGTM! Type definition standardized for Img componentThe type definition for the
srcproperty has been correctly standardized to lowercase.Since this is a schema change, please ensure the documentation is updated. Run this script to locate documentation files that might need updates:
✅ Verification successful
Type standardization is consistent, no documentation updates needed
The verification shows that:
- All type definitions in
builtin.jsonconsistently use lowercase "string"- No explicit documentation about the Img component's schema was found that would need updating
- The change aligns with the schema format used throughout the codebase
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for documentation files that might reference these components rg -l "type.*String|type.*Boolean" --type=md --glob="**/docs/**"Length of output: 66
Script:
#!/bin/bash # Let's try a broader search for documentation files and markdown files fd -e md -e mdx # Also search for any files that might contain documentation about the Img component rg -i "img.*component|component.*img" --type=md --type=mdx -lLength of output: 1815
Script:
#!/bin/bash # Let's check if there are any references to the Img component in the documentation files rg -i "img.*component|component.*img|image.*component" --type=md # Also let's check the schema usage in the codebase to ensure consistency rg -l "type.*String|type.*string" packages/canvas/render/src/builtin/Length of output: 547
Script:
#!/bin/bash # Let's check the actual type definitions in these files to ensure consistency rg "type.*[sS]tring" packages/canvas/render/src/builtin/builtin.json -C 2Length of output: 1356
160-160: LGTM! Type definitions standardized for Collection componentThe type definitions for
condition,style, anddataSourceproperties have been correctly standardized to lowercase, following JSON Schema conventions.Since this is a breaking schema change, please ensure that all consumers of this schema are updated accordingly. Run this script to check for any custom components that might be extending this schema:
Also applies to: 176-176, 192-192
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.Logincomponent for Single Sign-On (SSO) functionality.deepCloneutility function to enhance object handling in theuseMaterial.jsfile.Bug Fixes
generateFnfunction to prevent runtime errors.delBlockfunction to ensure correct error messages on deletion failures.Documentation
DesignCanvas.vueto clarify modal display logic.Version Updates
2.1.0, indicating stable releases.2.1.0-rc.0, indicating pre-release status.