feat: blockCompiler #906
feat: blockCompiler #906
Conversation
WalkthroughA new ESLint configuration file has been introduced in the Changes
Suggested reviewers
Poem
Tip CodeRabbit's docstrings feature is now available as part of our Early Access Program! Simply use the command 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
enhancement
chilingling
force-pushed
the
feat/blockCompiler
branch
2 times, most recently
from
6ab1e32 to
c789546
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 34
🔭 Outside diff range comments (6)
packages/plugins/materials/package.json (1)
Line range hint
28-32: Add test coverage requirementsThe PR indicates that tests haven't been added. Given that this package handles core material functionality and now includes block compilation:
- Unit tests for block compiler integration
- Integration tests with existing materials
- Migration test cases
are essential for maintaining stability.
Would you like me to help create a test plan or generate initial test cases for the block compiler integration?
packages/common/component/PluginBlockList.vue (3)
Line range hint
72-72: Fix empty title attribute for accessibilityThe empty title attribute
title=" "can cause accessibility issues. Either provide meaningful text or remove the attribute if not needed.- title=" " + :title="getTitle(item)"
Line range hint
229-236: Add error handling for element traversalThe
getParentNodefunction could throw an error if an LI element is not found in the parent chain. Consider adding error handling.const getParentNode = (el) => { + let maxDepth = 10; // Prevent infinite loop while (el.nodeName !== 'LI') { + if (!el.parentNode || maxDepth-- <= 0) { + throw new Error('LI element not found in parent chain'); + } el = el.parentNode } return el }
Line range hint
516-603: Clean up unused stylesRemove unused styles related to removed features (progress and deployment status). This includes:
.deployclass.loadingclass and its animation.successclass and its animation.errorclass and its animation- .deploy { - position: absolute; - top: 10px; - left: 10px; - width: 114px; - color: var(--ti-lowcode-toolbar-icon-color); - font-weight: bold; - vertical-align: middle; - text-align: center; - margin: -10px -11px; - padding: 40px 10px; - } - .loading { - animation-duration: 5s; - animation-name: roll; - animation-iteration-count: infinite; - animation-timing-function: linear; - background: repeating-linear-gradient( - 135deg, - rgba(39, 115, 214, 0.6) 0px, - rgba(39, 115, 214, 0.6) 10px, - rgba(255, 255, 255, 0.6) 10px, - rgba(255, 255, 255, 0.6) 20px - ); - } - .success { - width: 100%; - height: 100%; - position: absolute; - top: 10px; - animation: greenGrow 800ms ease-out 10 alternate; - background: rgb(55 68 58 / 60%); - } - .error { - width: 100%; - height: 100%; - position: absolute; - top: 10px; - animation: redGrow 800ms ease-out 20 alternate; - background: rgb(86 52 52 / 60%); - } - @keyframes roll { - from { - background-position: 0 0; - } - to { - background-position: 128px 0; - } - } - @keyframes greenGrow { - 0% { - box-shadow: inset 0px 0px 3px green; - } - 100% { - box-shadow: inset 0px 0px 7px green; - } - } - @keyframes redGrow { - 0% { - box-shadow: inset 0px 0px 3px red; - } - 100% { - box-shadow: inset 0px 0px 7px red; - } - }packages/plugins/materials/src/composable/useResource.js (1)
Line range hint
162-167: Improve error handling for critical initialization stepsThe error handling is too generic and simply logs errors to console. Since this is part of the critical initialization path for the block compiler feature, it should handle errors more robustly.
Consider implementing proper error handling:
try { await useMaterial().fetchMaterial() if (isInit) { await initPageOrBlock() } await useTranslate().initI18n({ host: id, hostType: type, init: true }) } catch (error) { - console.log(error) // eslint-disable-line + const errorMessage = `Failed to initialize resources: ${error.message}` + useMessage().error(errorMessage) + throw new Error(errorMessage) }packages/canvas/DesignCanvas/src/DesignCanvas.vue (1)
Line range hint
1-194: Add tests for the block compiler featureThe PR checklist indicates that tests haven't been added for this feature. Given that this is a breaking change affecting core block management functionality, tests are critical.
Would you like me to help create:
- Unit tests for the block compiler feature
- Integration tests for the new block management flow
- Migration guide for users updating from the old
registerBlocktogetBlockByName
🧹 Nitpick comments (28)
packages/plugins/materials/package.json (1)
28-28: Consider version constraint for block-compilerWhile
workspace:*is appropriate for monorepo development, consider if a more specific version constraint might be beneficial for the initial release of this breaking change.packages/common/component/PluginBlockList.vue (2)
110-110: Optimize import using destructuringConsider using destructured import for better tree-shaking.
-import { Tooltip } from '@opentiny/vue' +import Tooltip from '@opentiny/vue/tooltip'
Line range hint
229-252: Add TypeScript type definitions for better maintainabilityConsider adding TypeScript type definitions for function parameters to improve code maintainability and catch potential type-related issues early.
- const getParentNode = (el) => { + const getParentNode = (el: HTMLElement): HTMLElement => { while (el.nodeName !== 'LI') { el = el.parentNode } return el } - const openBlockShotPanel = (item, event) => { + const openBlockShotPanel = (item: BlockItem, event: MouseEvent): void => { state.currentBlock = item state.top = `${getParentNode(event.target).getBoundingClientRect().top}px` state.hover = true state.hoverItemId = item.idpackages/block-compiler/tsconfig.node.json (2)
3-8: Consider adding essential compiler options for Node.js environmentWhile the basic configuration is good, consider adding these Node.js-specific options for better compatibility:
"types": ["node"]- for Node.js type definitions"allowJs": true- useful when mixing JavaScript and TypeScript"resolveJsonModule": true- for importing JSON files{ "compilerOptions": { "tsBuildInfoFile": "./node_modules/.tmp/tsconfig.node.tsbuildinfo", "target": "ES2022", "lib": ["ES2023"], "module": "ESNext", "skipLibCheck": true, + "types": ["node"], + "allowJs": true, + "resolveJsonModule": true
1-24: Documentation needed for breaking changesSince this PR introduces breaking changes and the configuration file is new, please add a comment section at the top of the file explaining:
- The purpose of this Node-specific configuration
- How it relates to other TypeScript configurations in the package
- Any breaking changes in the configuration that affect existing applications
{ + // This configuration is specific to Node.js environment for the block compiler. + // It extends the base tsconfig.json and adds Node-specific settings. + // Breaking changes: + // - Uses "Bundler" moduleResolution which may affect how existing applications import the compiler + // - Enforces strict type checking which may reveal type errors in existing code "compilerOptions": {🧰 Tools
🪛 Biome (1.9.4)
[error] 9-9: JSON standard does not allow comments.
(parse)
[error] 10-10: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 10-10: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 10-10: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 10-10: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 11-11: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 11-11: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 11-11: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 11-11: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 12-12: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 12-12: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 12-12: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 12-12: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 13-13: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 13-13: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 13-13: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 13-13: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 14-14: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 14-14: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 14-14: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 14-16: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 16-16: JSON standard does not allow comments.
(parse)
[error] 17-17: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 17-17: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 17-17: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 17-17: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 18-18: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 18-18: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 18-18: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 18-18: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 19-19: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 19-19: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 19-19: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 19-19: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 20-20: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 20-20: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 20-20: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 20-20: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 21-21: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 21-21: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 21-21: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 22-22: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 23-23: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 23-23: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 23-23: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 23-24: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
packages/block-compiler/vite.config.ts (3)
8-11: Document the reason for using @ts-ignoreWhile the polyfill setup is necessary, the use of
@ts-ignoreshould be documented to explain why type checking needs to be bypassed here.Add comments explaining the type issues:
-// @ts-ignore +// @ts-ignore: Default export type definitions are missing in CJS modules const nodeGlobalsPolyfillPlugin = nodeGlobalsPolyfillPluginCjs.default -// @ts-ignore +// @ts-ignore: Default export type definitions are missing in CJS modules const nodeModulesPolyfillPlugin = nodeModulesPolyfillPluginCjs.default
15-15: Enable source map generation for better debuggingThe configuration should include source map generation to facilitate debugging in production environments.
Add source map configuration:
- plugins: [dts({ rollupTypes: true }), vue()], + plugins: [dts({ rollupTypes: true }), vue()], + build: { + sourcemap: true, + ...
27-33: Consider additional module formats and versioned filenamesThe current build configuration might limit compatibility and cause caching issues:
- Only ES module format might not work for all consumers
- Fixed filename without version could lead to caching problems
Consider the following improvements:
build: { lib: { entry: path.resolve(__dirname, './src/index.ts'), name: 'block-compiler', - fileName: () => 'index.js', + fileName: (format) => `index.${format}.js`, - formats: ['es'] + formats: ['es', 'cjs'] },packages/plugins/block/src/js/blockSetting.jsx (1)
498-500: Consider externalizing the success message for localizationThe success message
'区块发布成功!'is hardcoded in Chinese. To support internationalization, consider using localization functions to manage message strings.Apply this diff to externalize the message:
- useNotify({ message: '区块发布成功!', type: 'success' }) + useNotify({ message: t('block.publish.success'), type: 'success' })Ensure that the key
'block.publish.success'is added to your localization files.packages/block-compiler/test/sample/slotModelValueTest.vue (4)
2-3: Remove unnecessary div nestingThe nested div structure adds no value and can be simplified.
<template> - <div> - <div> + <div> <tiny-grid :editConfig="{ trigger: 'click', mode: 'cell', showStatus: true }" :columns="state.columns" :data="[
31-33: Optimize importsThe script setup syntax provides auto-imports for Vue composition API functions.
import { Grid as TinyGrid, Numeric as TinyNumeric, Input as TinyInput } from '@opentiny/vue' -import * as vue from 'vue' -import { defineProps, defineEmits } from 'vue' +import { reactive } from 'vue'
35-37: Remove unused props and emits definitionsSince this is a test component, either document its purpose and expected usage or remove the empty definitions.
-const props = defineProps({}) - -const emit = defineEmits([])
1-89: Structure this as a proper test caseThis file appears to be a test component but lacks proper test structure. Consider:
- Adding documentation about test scenarios
- Integrating with a test framework (e.g., Vitest)
- Adding proper assertions
- Separating test data from component logic
Would you like assistance in restructuring this as a proper test case with a testing framework?
packages/block-compiler/test/sample/BlockHead.vue (2)
1-6: Consider implementing i18n for text contentThe hardcoded Chinese text "这里是头部" should be externalized for internationalization support, especially since this appears to be a reusable block component.
- <h1 class="head-title">这里是头部</h1> + <h1 class="head-title">{{ t('blockHead.title') }}</h1>
17-21: Enhance component styling for better usabilityConsider adding essential header styles:
- Layout properties (padding, margin)
- Responsive design considerations
- Consistent color variables instead of hardcoded values
<style scoped> .head-title { - color: red; + color: var(--primary-color); + padding: 1rem; + margin-bottom: 1rem; } +@media (max-width: 768px) { + .head-title { + font-size: 1.5rem; + padding: 0.5rem; + } +} </style>packages/plugins/materials/src/composable/block-compile.js (1)
33-33: Address the TODO commentThe comment
// TODO: 待验证indicates that this section requires validation. Please ensure this part of the code is thoroughly tested and verified.Would you like assistance in verifying this code? I can help create tests or provide further validation.
packages/canvas/render/src/render.js (2)
272-280: Prevent Duplicate Styles and Potential Memory LeaksWhen injecting styles for blocks, new
<style>elements are appended to the document head without a unique identifier. This may result in duplicate styles and potential memory leaks if the same block is loaded multiple times.Apply the following diff to assign a unique
idto the stylesheet for effective management:const newStylesheet = document.createElement('style') +newStylesheet.id = fileName newStylesheet.innerHTML = value.style document.head.appendChild(newStylesheet)
662-676: OptimizeSuspenseUsage for Asynchronous ComponentsWrapping components with
Suspenseenhances user experience during loading states. However, ensure thatBlockLoadingprovides adequate feedback without introducing performance issues.Consider evaluating the impact of
Suspenseon rendering performance and adjust the fallback component as necessary.packages/canvas/render/src/BlockLoading.vue (1)
2-2: Implement Internationalization for User-Facing TextThe loading message is hardcoded in Chinese:
"区块 {{ name }} 加载中". To support multiple languages and improve accessibility, implement internationalization (i18n) practices.Modify the template to use i18n:
<template> <div>{{ $t('block_loading', { name }) }}</div> </template>And ensure the translation key
block_loadingis added to your localization files.packages/canvas/render/src/lowcode.js (1)
62-67: Refine Regular Expression for Function DetectionThe regex
/this\.dataSourceMap\.[0-9a-zA-Z_]+\.load\(\)/is used to detect function calls todataSourceMap. Using\w+instead of[0-9a-zA-Z_]+is more concise and equally effective.Apply the following diff:
-} else if (/this\.dataSourceMap\.[0-9a-zA-Z_]+\.load\(\)/.test(fnString)) { +} else if (/this\.dataSourceMap\.\w+\.load\(\)/.test(fnString)) {packages/block-compiler/src/index.ts (1)
125-152: Consider optimizing thecompileFilefunction for better readabilityThe
compileFilefunction combines script, template, and style compilation but could be refactored for clarity. Separating concerns and adding comments would enhance maintainability.Consider restructuring the function as follows:
- Add comments explaining each major step (compiling script, compiling template, handling scoped styles).
- Extract sub-functions if necessary to handle complex logic.
packages/block-compiler/test/sample/BlockFileName.vue (2)
21-21: Remove unnecessarydefineEmitsdeclarationThe
defineEmits([])declaration is unnecessary since no events are being emitted. Removing it simplifies the code.Apply this diff to remove the redundant declaration:
const props = defineProps({ testSlot: { type: Object, default: () => ({}) } }) -const emit = defineEmits([])
16-16: Refactor import statements for consistencyImporting the entire
vuenamespace asvueis unnecessary since specific functions are imported separately. This can lead to confusion and larger bundle sizes.Apply this diff to remove the unnecessary import:
-import * as vue from 'vue'Ensure that you are importing
reactivedirectly:+import { reactive } from 'vue'packages/canvas/DesignCanvas/src/importMap.js (1)
19-19: Specify exact version for@opentiny/tiny-engine-builtin-componentCDN URLUsing a version range with
^in a CDN URL may not resolve correctly and can lead to unexpected behavior. It's better to specify the exact version number.Apply this diff to specify the exact version:
'@opentiny/tiny-engine-builtin-component': `${VITE_CDN_DOMAIN}/@opentiny/tiny-engine-builtin-component@^2.0.0/dist/index.mjs` + '@opentiny/tiny-engine-builtin-component': `${VITE_CDN_DOMAIN}/@opentiny/[email protected]/dist/index.mjs`packages/block-compiler/src/dev.ts (1)
2-2: Consider using import maps instead of hardcoded CDN URLsImporting Vue from a hardcoded CDN URL may lead to version mismatches or caching issues. Since an import map is used elsewhere, consider using it for consistency.
Update the import statement to use the import map:
-import { createApp, defineAsyncComponent, h } from 'https://unpkg.com/[email protected]/dist/vue.runtime.esm-browser.js' +import { createApp, defineAsyncComponent, h } from 'vue'packages/build/vite-config/src/vite-plugins/devAliasPlugin.js (1)
64-65: Document the new block-compiler featureSince this introduces a new feature for block compilation:
- Add documentation explaining the purpose and usage of the block compiler
- Update the README or relevant documentation to reflect this addition
- Include examples of how to use the block compiler in development mode
packages/canvas/render/src/BlockLoadError.vue (1)
5-14: Enhance error handling capabilitiesThe component could benefit from additional props to handle different error scenarios and provide retry functionality.
<script setup> import { defineProps } from 'vue' defineProps({ name: { type: String, default: '' + }, + error: { + type: Error, + default: null + }, + onRetry: { + type: Function, + default: null } }) </script>packages/plugins/materials/src/composable/useResource.js (1)
129-129: Document the structure and purpose of componentsMapThe newly added
componentsMapproperty lacks documentation about its structure and purpose. This is particularly important as it appears to be part of a breaking change related to the block compiler feature.Add JSDoc comments to describe the structure and purpose:
+ /** @type {Object.<string, Object>} Map of component names to their configurations + * Used by the block compiler to resolve component dependencies + */ resState.componentsMap = appData.componentsMap
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (46)
packages/block-compiler/.eslintrc.cjs(1 hunks)packages/block-compiler/README.md(1 hunks)packages/block-compiler/index.html(1 hunks)packages/block-compiler/package.json(1 hunks)packages/block-compiler/src/dev.ts(1 hunks)packages/block-compiler/src/index.ts(1 hunks)packages/block-compiler/src/transformJsx.ts(1 hunks)packages/block-compiler/src/vite-env.d.ts(1 hunks)packages/block-compiler/test/sample/BlockFileName.vue(1 hunks)packages/block-compiler/test/sample/BlockHead.vue(1 hunks)packages/block-compiler/test/sample/BlockMenu.vue(1 hunks)packages/block-compiler/test/sample/BlockTest.vue(1 hunks)packages/block-compiler/test/sample/slotModelValueTest.vue(1 hunks)packages/block-compiler/tsconfig.app.json(1 hunks)packages/block-compiler/tsconfig.json(1 hunks)packages/block-compiler/tsconfig.node.json(1 hunks)packages/block-compiler/vite.config.ts(1 hunks)packages/build/vite-config/src/vite-plugins/devAliasPlugin.js(1 hunks)packages/canvas/DesignCanvas/src/DesignCanvas.vue(1 hunks)packages/canvas/DesignCanvas/src/importMap.js(1 hunks)packages/canvas/container/src/container.js(1 hunks)packages/canvas/package.json(1 hunks)packages/canvas/render/src/BlockLoadError.vue(1 hunks)packages/canvas/render/src/BlockLoading.vue(1 hunks)packages/canvas/render/src/RenderMain.js(4 hunks)packages/canvas/render/src/lowcode.js(2 hunks)packages/canvas/render/src/render.js(8 hunks)packages/canvas/render/src/runner.js(0 hunks)packages/canvas/render/src/supportUmdBlock.js(0 hunks)packages/common/component/PluginBlockList.vue(1 hunks)packages/common/component/ProgressBar.vue(0 hunks)packages/common/component/index.js(0 hunks)packages/common/composable/generateCode/index.js(1 hunks)packages/design-core/package.json(1 hunks)packages/design-core/src/preview/src/preview/importMap.json(1 hunks)packages/layout/src/DesignToolbars.vue(1 hunks)packages/plugins/block/src/BlockSetting.vue(0 hunks)packages/plugins/block/src/js/blockSetting.jsx(1 hunks)packages/plugins/block/src/js/http.js(0 hunks)packages/plugins/materials/package.json(1 hunks)packages/plugins/materials/src/composable/block-compile.js(1 hunks)packages/plugins/materials/src/composable/useMaterial.js(6 hunks)packages/plugins/materials/src/composable/useResource.js(1 hunks)packages/plugins/materials/src/meta/block/src/BlockList.vue(2 hunks)packages/plugins/materials/src/meta/block/src/BlockVersionSelect.vue(2 hunks)packages/vue-generator/src/constant/index.js(1 hunks)
💤 Files with no reviewable changes (6)
- packages/common/component/index.js
- packages/plugins/block/src/BlockSetting.vue
- packages/plugins/block/src/js/http.js
- packages/canvas/render/src/runner.js
- packages/common/component/ProgressBar.vue
- packages/canvas/render/src/supportUmdBlock.js
✅ Files skipped from review due to trivial changes (7)
- packages/block-compiler/src/vite-env.d.ts
- packages/block-compiler/README.md
- packages/block-compiler/tsconfig.json
- packages/block-compiler/.eslintrc.cjs
- packages/block-compiler/package.json
- packages/vue-generator/src/constant/index.js
- packages/block-compiler/index.html
🧰 Additional context used
🪛 Biome (1.9.4)
packages/block-compiler/tsconfig.node.json
[error] 9-9: JSON standard does not allow comments.
(parse)
[error] 10-10: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 10-10: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 10-10: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 10-10: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-16: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 16-16: JSON standard does not allow comments.
(parse)
[error] 17-17: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 17-17: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 17-17: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 17-17: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 18-18: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 18-18: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 18-18: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 18-18: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 22-22: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 23-23: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 23-23: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 23-23: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 23-24: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
packages/block-compiler/tsconfig.app.json
[error] 10-10: JSON standard does not allow comments.
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-15: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-15: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-15: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-15: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 16-16: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 16-16: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 16-16: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 16-18: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 18-18: JSON standard does not allow comments.
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 22-22: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 22-22: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 22-22: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 22-22: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 23-23: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 23-23: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 23-23: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 24-24: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 25-25: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 25-25: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 25-25: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 25-26: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
🔇 Additional comments (27)
packages/plugins/materials/package.json (1)
28-28: Verify integration with existing components
The addition of the block compiler could affect existing material implementations.
Let's verify the impact:
✅ Verification successful
Let me check the actual implementation details of the block compiler integration by examining the relevant files.
Based on the code analysis, I can now provide the final response:
Block compiler integration is properly isolated and backwards compatible
The block compiler is cleanly integrated through the block-compile.js module with proper caching mechanisms and version checking in place. The implementation:
- Uses isolated compilation cache through
blockCompileCache - Maintains backward compatibility with existing block implementations
- Handles dependency versioning through
blockDepsVersion - Properly integrates with the existing material system through
useMaterial().addBlockResources
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for existing block-related implementations that might need updates
rg -g '!dist' -g '!node_modules' -l 'block' packages/plugins/materials/src/
# Check for potential breaking patterns in material implementations
ast-grep --pattern 'export default {
$$$
blocks {
$$$
}
$$$
}'
Length of output: 1198
Script:
#!/bin/bash
# Check block-compile.js implementation
cat packages/plugins/materials/src/composable/block-compile.js
# Check how block compiler is used in useMaterial
rg -A 5 "block.*compiler" packages/plugins/materials/src/composable/useMaterial.js
# Look for existing compiler usage patterns
rg -A 5 "compiler" packages/plugins/materials/src/
Length of output: 4299
packages/block-compiler/tsconfig.node.json (2)
16-21: LGTM: Strong type-checking configuration
The strict type-checking options are well configured for a compiler package:
strict: trueensures comprehensive type checkingnoUnusedLocalsandnoUnusedParametershelp maintain clean codenoUncheckedSideEffectImportsis particularly important for a compiler package
🧰 Tools
🪛 Biome (1.9.4)
[error] 16-16: JSON standard does not allow comments.
(parse)
[error] 17-17: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 17-17: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 17-17: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 17-17: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 18-18: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 18-18: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 18-18: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 18-18: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
9-15: Verify bundler configuration impact on existing applications
The bundler mode settings, particularly moduleResolution: "Bundler" and isolatedModules: true, might affect how existing applications import and use the block compiler. Since this PR is marked as having breaking changes, ensure these settings are documented.
✅ Verification successful
Let me gather more information about the potential impact of these changes.
Based on the gathered information, I can now provide the final response:
Bundler configuration changes are safe and aligned with the package setup
The module resolution changes in tsconfig.node.json are consistent with the package's setup as it's already configured as an ES module ("type": "module" in package.json) and uses Vite for building. The package is properly distributed through the dist directory as specified in the files field, so the internal TypeScript configuration won't affect consumers. The breaking changes in this PR are likely related to other modifications, not these TypeScript compiler settings.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for existing module resolution strategies in the codebase
rg -g '*.json' '"moduleResolution":\s*"[^"]*"'
# Look for potential import statements that might be affected
ast-grep --pattern 'import { $$$ } from "$_"'
Length of output: 251
Script:
#!/bin/bash
# Check for package.json to understand dependencies and build setup
cat packages/block-compiler/package.json
# Check for any documentation about module resolution or breaking changes
fd README.md packages/block-compiler/ --exec cat {}
# Look for import statements specifically in the block-compiler package
rg -g '*.ts' -g '*.js' 'import' packages/block-compiler/
Length of output: 4050
🧰 Tools
🪛 Biome (1.9.4)
[error] 9-9: JSON standard does not allow comments.
(parse)
[error] 10-10: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 10-10: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 10-10: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 10-10: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
packages/layout/src/DesignToolbars.vue (1)
42-42: LGTM!
The import of reactive and its usage in the setup function is appropriate.
packages/canvas/package.json (1)
45-45: Verify compatibility with the new @vue/babel-plugin-jsx version
The version update from 1.1.1 to ^1.2.5 allows minor updates. Since this is part of a breaking change:
- Ensure compatibility with other Vue-related dependencies
- Document any breaking changes in the plugin's changelog
✅ Verification successful
Update to @vue/babel-plugin-jsx ^1.2.5 is safe to proceed
The version update from 1.1.1 to ^1.2.5 is safe as:
- No breaking changes were introduced after version 1.1.1
- Changes between these versions are primarily bug fixes and features:
- Bug fixes for v-model, v-slots, and import handling
- New features for TypeScript support and JSX improvements
- Compatible with current Vue-related dependencies (eslint-plugin-vue ^8.0.0)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for breaking changes in @vue/babel-plugin-jsx changelog
gh api repos/vuejs/babel-plugin-jsx/releases | jq -r '.[].body' | grep -i "breaking"
# Verify compatibility with Vue version
grep -r "vue.*:" package.json | grep -v "@vue/babel-plugin-jsx"
Length of output: 296
Script:
#!/bin/bash
# Get the full changelog content to understand the breaking changes context
gh api repos/vuejs/babel-plugin-jsx/releases | jq -r '.[].body'
# Check Vue version in package.json
grep -r "\"vue\":" package.json
# Check Vue version in package-lock.json for actual resolved version
grep -A 5 "\"vue\":" package-lock.json 2>/dev/null || echo "package-lock.json not found"
Length of output: 8335
packages/design-core/package.json (1)
92-92: Maintain version consistency across packages
The version update to ^1.2.5 matches the canvas package, which is good for consistency.
✅ Verification successful
Version consistency verified across packages
The @vue/babel-plugin-jsx dependency is consistently set to version ^1.2.5 across all relevant packages:
- packages/block-compiler/package.json
- packages/canvas/package.json
- packages/design-core/package.json
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify consistent @vue/babel-plugin-jsx versions across all package.json files
fd package.json | xargs grep "@vue/babel-plugin-jsx"
Length of output: 269
packages/block-compiler/test/sample/BlockMenu.vue (1)
1-25: Add unit tests for the block components
These components are in the test/sample directory but lack actual test coverage. Given that this is a new feature with breaking changes, please add:
- Unit tests for both components
- Integration tests for component interaction
- Snapshot tests for UI regression
Would you like help creating a test suite for these components?
✅ Verification successful
Add unit tests for the block components
The review comment is valid. The evidence shows:
- The
test/sampledirectory only contains Vue component files without corresponding test files - Other packages in the repository have proper test coverage (as seen in register, utils, and vue-generator packages)
- The block-compiler package lacks any test files despite having test samples
- The package.json shows the project uses Vue 3 and TypeScript, but has no test configuration
Please add:
- Unit tests for the BlockMenu.vue and related components in the test/sample directory
- Integration tests to verify component interactions
- Snapshot tests for UI regression
Recommended test file structure:
packages/block-compiler/test/unit/BlockMenu.spec.tspackages/block-compiler/test/integration/BlockComponents.spec.ts
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for existing test files
fd -e spec.ts -e test.ts . packages/block-compiler/test/
Length of output: 58
Script:
#!/bin/bash
# Let's check the structure of the test directory and look for any test files with different extensions
fd . packages/block-compiler/test/
# Also check if there are test files in other locations that might test these components
rg -l "BlockMenu" --type ts --type vue
Length of output: 403
Script:
#!/bin/bash
# Let's check if there are any test files in the entire packages directory
fd -e spec.js -e test.js -e spec.ts -e test.ts . packages/
# Also check the content of package.json to understand the testing setup
cat packages/block-compiler/package.json
Length of output: 2385
packages/common/composable/generateCode/index.js (1)
52-80: The code improvements enhance error handling and schema processing
The updates to the getAllNestedBlocksSchema function improve the clarity and robustness of the code by:
- Properly handling promises and checking for fulfillment status.
- Refining the logic for retrieving
schemaContent, ensuring the most relevant content is used. - Adding a
versionproperty toschemaContentfor better tracking. - Assigning sub-block dependencies to
schemaContent.
These enhancements align with best practices and improve the maintainability of the code.
packages/design-core/src/preview/src/preview/importMap.json (1)
13-13: Verify compatibility with the new major version
The import of @opentiny/tiny-engine-builtin-component has been updated to version ^2.0.0. Please ensure that the codebase is compatible with this new major version, as it may introduce breaking changes.
packages/plugins/materials/src/meta/block/src/BlockVersionSelect.vue (2)
39-39: LGTM: New imports align with functionality changes
The addition of useMaterial and useCanvas imports supports the new direct update approach for block version changes.
90-100: 🛠️ Refactor suggestion
Verify the impact of removing page refresh requirement
The removal of the confirmation dialog and page refresh might lead to potential issues:
- Users might accidentally switch versions without confirmation
- The application state might become stale without a page refresh
Let's verify the block version switching implementation across the codebase:
Consider implementing a less disruptive approach:
- useMaterial().updateBlockCompileCache(selectedRow.block_id)
- useCanvas().canvasApi.value?.updateCanvas()
+ // Show a non-blocking notification instead of confirmation
+ message({
+ type: 'success',
+ message: `${selectedBlock.value.label}区块已切换为${selectedRow.version}版本`,
+ duration: 3000
+ })
+ // Update cache and canvas
+ await useMaterial().updateBlockCompileCache(selectedRow.block_id)
+ await useCanvas().canvasApi.value?.updateCanvas()✅ Verification successful
Based on the search results, I can now provide a final response:
Block version switching implementation is safe to use without page refresh
The code changes are safe because:
-
The implementation properly handles version switching through two key operations:
updateBlockCompileCache()clears and updates the block's cached compilation dataupdateCanvas()triggers a re-render of the canvas with the new version
-
The canvas rendering system is designed to handle dynamic updates through these methods, making a full page refresh unnecessary.
-
The removed confirmation dialog was redundant since the canvas updates immediately reflect the version change.
-
The implementation follows the proper update sequence:
- First updates the block cache
- Then triggers canvas refresh
- Changes are applied synchronously
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other version switching implementations
rg -l "updateBlockCompileCache|updateCanvas" --type vue --type js
# Check for any version-related state management
rg "version.*state|state.*version" --type vue --type js
Length of output: 181
Script:
#!/bin/bash
# Search for other version switching implementations without file type filters
rg -l "updateBlockCompileCache|updateCanvas"
# Check for any version-related state management
rg "version.*state|state.*version"
# Look for block version related code
rg "block.*version|version.*block" -A 3
Length of output: 65996
Script:
#!/bin/bash
# Search for block version related code with more context
rg "updateBlockCompileCache|updateCanvas" -A 3 -B 3
# Search for block version state management
rg "block.*version|version.*block" -A 3 -B 3
# Look for block version switching logic
ast-grep --pattern $'updateBlockCompileCache($$$)'
Length of output: 71602
packages/plugins/materials/src/meta/block/src/BlockList.vue (1)
79-79:
Breaking Change: Block registration pattern has changed
The switch from registerBlock to getBlockByName represents a significant change in how blocks are managed. This is a breaking change that could affect existing applications.
Let's verify the impact of this change:
packages/canvas/render/src/RenderMain.js (3)
19-26: Confirm Accurate Import of removeBlockCompsCacheByName
The removeBlockCompsCacheByName function is imported from ./render. Verify that it is correctly exported and accessible to avoid runtime errors.
398-401: Ensure Reactive State Update in updateCanvas Function
The updateCanvas function increments refreshKey.value to trigger a re-render. Confirm that refreshKey is a reactive reference to ensure the canvas updates as intended.
470-472: Expose New Methods in API Export
The methods setDesignMode, removeBlockCompsCacheByName, and updateCanvas are added to the exported API. This enhances the module's functionality and provides necessary control for cache management and canvas updates.
packages/canvas/container/src/container.js (3)
910-915: 🛠️ Refactor suggestion
Add error handling and documentation for new methods.
The new methods added to canvasApi need additional safeguards and documentation:
- Add null checks for
canvasState.renderer:
setDataSourceMap: (...args) => {
+ if (!canvasState.renderer) {
+ console.warn('Canvas renderer is not initialized');
+ return;
+ }
return canvasState.renderer.setDataSourceMap(...args)
},- Add JSDoc documentation for each method:
+ /**
+ * Sets the data source map in the canvas renderer
+ * @param {...*} args - Arguments to pass to the renderer's setDataSourceMap
+ * @returns {*} Result from the renderer's setDataSourceMap
+ */
setDataSourceMap: (...args) => {
return canvasState.renderer.setDataSourceMap(...args)
},Let's verify the usage of these methods:
911-913: Ensure backward compatibility for block compiler feature.
The removeBlockCompsCacheByName method is part of a breaking change. Consider:
- Adding a version check or deprecation warning for existing applications
- Documenting migration steps for users
- Adding examples of usage in the documentation
Consider implementing a caching strategy that:
- Uses a cache invalidation policy
- Handles memory management for large block components
- Provides cache statistics for monitoring
Let's check for existing cache implementations:
914-915: Document the canvas update lifecycle.
The updateCanvas method needs clear documentation about:
- When it should be called
- What triggers a canvas update
- Performance implications
Would you like me to help create:
- Unit tests for the new methods
- Documentation for the block compiler feature
- Migration guide for existing applications
Let's check the update patterns:
✅ Verification successful
Let me gather more context about the canvas update implementation to better understand its lifecycle.
Based on the gathered information, I can now generate the final response since I have a clear picture of the canvas update lifecycle from the codebase analysis.
Document the canvas update lifecycle and its implications
The updateCanvas method is a critical rendering mechanism that:
- Should be called when the canvas content needs a full refresh, such as after:
- Block version changes (as seen in BlockVersionSelect.vue)
- Material dependency updates (via updateCanvasDependencies)
- Data source map modifications
- Triggers a refresh by incrementing a reactive
refreshKey, forcing a re-render of the entire canvas - Performance implications:
- Causes a complete re-render of the canvas components
- Should be used judiciously as it impacts rendering performance
- Consider using more granular updates (like updateRect) for localized changes
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for existing update patterns
rg -A 3 "update.*Canvas|refresh.*Canvas|render.*Canvas"
Length of output: 4620
Script:
#!/bin/bash
# Search for the renderer implementation and canvas update logic
ast-grep --pattern 'const updateCanvas = $_'
# Look for canvas state changes and render triggers
rg -A 5 "canvasState.renderer"
# Find component refresh patterns
rg -A 3 "refreshKey|forceUpdate"
Length of output: 3274
packages/block-compiler/src/index.ts (1)
48-67: Ensure correct transformation of JSX code
The functions compileBlockTemplate and compileBlockScript handle JSX transformation when isJsx is true. However, if transformVueJsx returns undefined or an empty string, it may lead to issues.
Please verify that transformVueJsx always returns valid code when isJsx is true. If there is a possibility of it returning falsy values, you should add checks or default values to prevent potential errors.
Run the following script to search for usages of transformVueJsx and ensure it handles all cases:
✅ Verification successful
Let me gather more information about the implementation and usage context.
Based on the results, I can now generate the final response since we have found the implementation and usage of transformVueJsx.
The JSX transformation is properly handled with fallback
The implementation in transformJsx.ts shows that transformVueJsx uses Babel's transformSync with the vueJsx plugin, and the code already handles potential undefined returns by using the OR (||) operator with an empty string in both usage locations:
code = transformVueJsx(code) || ''This ensures that even if the transformation returns undefined, the code will fall back to an empty string, preventing any potential issues.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that `transformVueJsx` handles all cases properly
# Search for the implementation of `transformVueJsx`
rg -A 5 'function transformVueJsx'
# Search for all calls to `transformVueJsx`
rg 'transformVueJsx\('
Length of output: 213
Script:
#!/bin/bash
# Search for the transformVueJsx implementation and its surrounding context
ast-grep --pattern 'const transformVueJsx = $_'
# Search for the full context of where transformVueJsx is used
rg -B 5 -A 5 'transformVueJsx\('
# Check if there's any error handling or validation related to this transformation
rg -B 3 -A 3 'isJsx.*true'
Length of output: 1771
packages/canvas/DesignCanvas/src/importMap.js (1)
17-17: Update the version of @opentiny/vue to match tinyVue version
Ensure that the version of @opentiny/vue-icon matches the tinyVue version specified in importMapVersions for consistency.
Run the following script to check for version consistency:
packages/block-compiler/src/dev.ts (1)
80-82: Handle potential errors when mounting the app
The App.mount call assumes that the element #app exists. If it doesn't, querySelector will return null, leading to an error.
Ensure that the element with ID app exists in the HTML file. Alternatively, add a check or provide a meaningful error message.
You can apply this diff to handle the case when the element is not found:
const appElement = document.querySelector('#app')
-if (appElement) {
- App.mount(appElement)
-}
+if (appElement) {
+ App.mount(appElement)
+} else {
+ console.error('Failed to mount app: #app element not found.')
+}packages/build/vite-config/src/vite-plugins/devAliasPlugin.js (2)
64-65: Verify development-only alias behavior
The block compiler alias is only active in development mode (serve). Please confirm if this is intentional, as it might cause issues in production builds where the alias won't be available.
✅ Verification successful
Development-only alias is intentional and correct
The development-only alias behavior is intentional and properly implemented. The code shows that:
- The
devAliasPluginis explicitly designed to work only in 'serve' mode (development), as indicated by the comment "devAlias 只在 serve 模式下生效" and the conditionif (command === 'serve'). - In production, the package
@opentiny/tiny-engine-block-compileris properly handled through workspace dependencies as seen inpackage.jsonfiles. - The block compiler is used as a direct dependency in the materials plugin, which ensures it's available in production builds through proper package resolution.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for block compiler imports in the codebase
echo "Checking for block compiler usage..."
rg -l "@opentiny/tiny-engine-block-compiler"
# Check build configuration
echo "Checking build configuration..."
fd "vite.config" -x cat {} \; | rg -A 5 "build.*config"
Length of output: 507
Script:
#!/bin/bash
# Let's check how the devAliasPlugin is being used in the build configuration
echo "Checking devAliasPlugin usage..."
rg -A 10 "devAliasPlugin" packages/build/vite-config/src/
# Check where block-compiler is actually imported/used
echo "Checking block-compiler usage with context..."
rg -C 3 "@opentiny/tiny-engine-block-compiler"
# Check if there are different configurations for dev vs prod
echo "Checking for environment-specific configurations..."
rg -C 3 "process.env.(NODE_ENV|MODE)" packages/build/vite-config/src/
Length of output: 5493
64-65: Verify TypeScript configuration for block-compiler module
The new alias points to a TypeScript file (index.ts). Please ensure:
- TypeScript configuration is properly set up in the Vite config
- The block-compiler package has the necessary TypeScript dependencies
✅ Verification successful
Let me check the TypeScript configuration content and Vite setup to ensure proper TypeScript support.
Let me check the TypeScript configuration in more detail to ensure it's properly set up.
TypeScript configuration is properly set up for block-compiler module
The TypeScript support is correctly configured:
- TypeScript compiler options are properly set up in both
tsconfig.app.jsonandtsconfig.node.json - Required dependencies are installed:
typescript,vite-plugin-dts, and TypeScript ESLint plugins - Vite is configured with Vue plugin and TypeScript declaration generation (
vite-plugin-dts) - The module's source files are properly included in the TypeScript compilation scope
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for TypeScript configuration
echo "Checking for TypeScript configuration..."
fd -t f "tsconfig.json|vite.config.ts"
# Check for TypeScript dependencies
echo "Checking for TypeScript dependencies..."
fd "package.json" -x jq -r '.dependencies,.devDependencies | select(. != null) | with_entries(select(.key | contains("typescript")))'
Length of output: 875
Script:
#!/bin/bash
# Check TypeScript configuration in block-compiler
echo "Content of block-compiler's tsconfig.json:"
cat packages/block-compiler/tsconfig.json
echo -e "\nContent of block-compiler's vite.config.ts:"
cat packages/block-compiler/vite.config.ts
echo -e "\nChecking for TypeScript plugin in Vite config:"
rg "@vitejs/plugin-vue-jsx|@vitejs/plugin-vue|@vitejs/plugin-react" -A 5
Length of output: 51878
Script:
#!/bin/bash
# Check TypeScript app configuration
echo "Content of block-compiler's tsconfig.app.json:"
cat packages/block-compiler/tsconfig.app.json
echo -e "\nContent of block-compiler's tsconfig.node.json:"
cat packages/block-compiler/tsconfig.node.json
# Check for TypeScript-related dependencies in block-compiler
echo -e "\nChecking block-compiler's package.json for TypeScript dependencies:"
cat packages/block-compiler/package.json | jq '.dependencies,.devDependencies | select(. != null) | with_entries(select(.key | contains("typescript") or contains("ts-") or contains("vite")))'
Length of output: 2190
packages/canvas/render/src/BlockLoadError.vue (1)
16-22: Review styling approach and canvas limitations
The comment suggests limitations with CSS variables in the canvas environment.
Let's verify the canvas CSS variable limitations:
Consider:
- Document the CSS variable limitation in the component's documentation
- Create a shared color tokens file for consistent error states
- Add responsive padding using relative units
packages/canvas/DesignCanvas/src/DesignCanvas.vue (1)
184-185:
Document breaking changes in block registration system
The addition of getBlockByName and removal of registerBlock represents a breaking change in how blocks are managed. This needs to be properly documented and tested.
- Add documentation about the breaking change:
controller: {
// 需要在canvas/render或内置组件里使用的方法
getMaterial: useMaterial().getMaterial,
addHistory: useHistory().addHistory,
request: getMetaApi(META_SERVICE.Http).getHttp(),
+ /** @breaking-change Replaces registerBlock
+ * Retrieves block configuration by name for the block compiler
+ * @param {string} name - Block name
+ * @returns {Promise<Object>} Block configuration
+ */
ast,
getBlockByName: useMaterial().getBlockByName
},- Let's verify the impact of this breaking change:
packages/block-compiler/tsconfig.app.json (2)
25-25: Verify source file organization
The include pattern assumes all source files are under src/. Let's verify this assumption and ensure no source files are missed.
✅ Verification successful
TypeScript/Vue files outside src/ are test files and configuration
The files found outside the src/ directory are:
- Test files under
test/directories - Configuration file (
vite.config.ts) - Common components that appear to be in a separate package
- Test case files for Vue generator
The tsconfig.app.json include pattern is correct as it specifically targets source files for the block-compiler package. The files outside src/ are either test files, configuration, or belong to different packages which have their own TypeScript configurations.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for TypeScript/Vue files outside src/
fd -e ts -e tsx -e vue . --exclude src --exclude node_modules --exclude dist
Length of output: 4058
🧰 Tools
🪛 Biome (1.9.4)
[error] 25-25: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 25-25: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 25-25: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 25-26: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
2-9: Verify browser compatibility requirements
The configuration targets ES2020 and includes DOM types, suggesting browser usage. Please ensure this aligns with the project's browser support matrix.
✅ Verification successful
Browser compatibility requirements are properly aligned
The ES2020 target in the block-compiler's tsconfig.json aligns with the project's documented browser support requirements found in package.json. The project's browserslist configuration ("> 1%, last 2 versions, not dead") is compatible with ES2020 features, and the DOM types inclusion is appropriate for the browser environment.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if browser compatibility is documented
rg -l "browser.*support|compatibility" --type md
Length of output: 50
Script:
#!/bin/bash
# Let's check for any documentation about supported environments or browser targets
fd README.md
# Also check package.json for browserslist config or similar browser-related fields
fd package.json --exec cat {} | jq -r 'select(.browserslist or .engines or .targets)'
# Check for any .browserslistrc file
fd .browserslistrc
# Look for any ESLint or other config files that might specify environment
fd .eslintrc
Length of output: 10468
There was a problem hiding this comment.
Actionable comments posted: 5
♻️ Duplicate comments (2)
packages/block-compiler/src/index.ts (2)
84-103:⚠️ Potential issueCritical: Remove @ts-ignore and implement error handling
The function has two critical issues:
- The @ts-ignore annotation is masking potential type issues
- Missing error handling as noted in the TODO comment
228-230:⚠️ Potential issueCritical: Implement error handling for parse errors
🧹 Nitpick comments (5)
packages/block-compiler/tsconfig.app.json (1)
26-26: Consider expanding include patternsThe current include patterns might miss important files. Consider adding:
- Test files:
"./test/**/*.ts","./__tests__/**/*.ts"- Type declaration files:
"./src/**/*.d.ts"- Configuration types:
"./config/**/*.ts"- "include": ["./src/**/*.ts", "./src/**/*.tsx", "./src/**/*.vue"] + "include": [ + "./src/**/*.ts", + "./src/**/*.tsx", + "./src/**/*.vue", + "./src/**/*.d.ts", + "./test/**/*.ts", + "./__tests__/**/*.ts", + "./config/**/*.ts" + ]🧰 Tools
🪛 Biome (1.9.4)
[error] 26-26: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 26-26: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 26-26: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 26-27: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
packages/block-compiler/tsconfig.node.json (1)
3-8: Consider relocating tsBuildInfoFile outside node_modulesStoring build info in
node_modules/.tmpmay cause issues as this directory is typically excluded from version control and cleaned during CI/CD processes. Consider moving it to a more stable location.- "tsBuildInfoFile": "./node_modules/.tmp/tsconfig.node.tsbuildinfo", + "tsBuildInfoFile": "./.temp/tsconfig.node.tsbuildinfo",packages/block-compiler/src/index.ts (3)
186-195: Improve readability of dependency filtering logicThe current implementation could be more readable with better variable naming and simplified logic.
const filterNextCompileFiles = (files: IParsedFileItem[], compiledFilesSet: Set<string>) => { + const isFileCompiled = (file: string) => compiledFilesSet.has(file) + const areAllDependenciesCompiled = (file: IParsedFileItem) => + file.importedFiles.every(isFileCompiled) + return files.filter((fileItem) => { - return ( - !compiledFilesSet.has(fileItem.fileNameWithRelativePath) && - !fileItem.importedFiles.some((item) => !compiledFilesSet.has(item)) - ) + return !isFileCompiled(fileItem.fileNameWithRelativePath) && + areAllDependenciesCompiled(fileItem) }) }
267-276: Implement cache size limits and invalidation strategyThe current caching mechanism lacks size limits and invalidation strategy, which could lead to memory issues in long-running applications.
Consider implementing:
- Maximum cache size
- LRU eviction policy
- Cache invalidation based on file modification time
+const MAX_CACHE_SIZE = 1000 // or appropriate number + export interface IConfig { compileCache: Map<string, ICompileCacheItem> + maxCacheSize?: number }
203-219: Add JSDoc documentation for public APIsThe exported interfaces and functions lack documentation, making it harder for other developers to understand and use the API correctly.
+/** + * Represents a file to be compiled + */ export interface IFileItem { fileName: string sourceCode: string subBlockDeps?: string[] } +/** + * Configuration options for the compiler + * @property compileCache - Cache for compiled results + */ export interface IConfig { compileCache: Map<string, ICompileCacheItem> }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (8)
packages/block-compiler/.eslintrc.cjs(1 hunks)packages/block-compiler/package.json(1 hunks)packages/block-compiler/src/dev.ts(1 hunks)packages/block-compiler/src/index.ts(1 hunks)packages/block-compiler/tsconfig.app.json(1 hunks)packages/block-compiler/tsconfig.json(1 hunks)packages/block-compiler/tsconfig.node.json(1 hunks)packages/block-compiler/vite.config.ts(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (5)
- packages/block-compiler/tsconfig.json
- packages/block-compiler/src/dev.ts
- packages/block-compiler/.eslintrc.cjs
- packages/block-compiler/package.json
- packages/block-compiler/vite.config.ts
🧰 Additional context used
🪛 Biome (1.9.4)
packages/block-compiler/tsconfig.node.json
[error] 10-10: JSON standard does not allow comments.
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-15: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-15: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-15: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-17: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 17-17: JSON standard does not allow comments.
(parse)
[error] 18-18: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 18-18: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 18-18: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 18-18: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 22-22: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 22-22: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 22-22: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 23-23: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 24-24: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 24-24: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 24-24: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 24-25: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
packages/block-compiler/tsconfig.app.json
[error] 11-11: JSON standard does not allow comments.
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-15: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-15: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-15: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-15: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 16-16: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 16-16: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 16-16: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 16-16: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 17-17: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 17-17: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 17-17: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 17-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: JSON standard does not allow comments.
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 22-22: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 22-22: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 22-22: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 22-22: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 23-23: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 23-23: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 23-23: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 23-23: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 24-24: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 24-24: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 24-24: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 25-25: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 26-26: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 26-26: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 26-26: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 26-27: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
🔇 Additional comments (9)
packages/block-compiler/tsconfig.app.json (4)
11-17: Document TypeScript version requirements
The use of moduleResolution: "Bundler" requires TypeScript 5.0+. This should be documented as it's a breaking change.
🧰 Tools
🪛 Biome (1.9.4)
[error] 11-11: JSON standard does not allow comments.
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-15: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-15: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-15: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-15: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 16-16: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 16-16: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 16-16: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 16-16: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 17-17: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 17-17: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 17-17: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
19-24: Add tests to validate strict TypeScript configurations
The configuration enables strict type checking and various linting rules. However, the PR indicates that tests haven't been added.
🧰 Tools
🪛 Biome (1.9.4)
[error] 19-19: JSON standard does not allow comments.
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 22-22: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 22-22: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 22-22: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 22-22: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 23-23: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 23-23: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 23-23: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 23-23: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 24-24: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 24-24: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 24-24: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
1-27: Breaking changes need documentation for v2.0.0-rc.2
The package is currently at version 2.0.0-rc.2, but the CHANGELOG.md needs to be updated with these breaking changes.
🧰 Tools
🪛 Biome (1.9.4)
[error] 11-11: JSON standard does not allow comments.
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-15: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-15: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-15: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-15: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 16-16: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 16-16: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 16-16: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 16-16: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 17-17: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 17-17: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 17-17: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 17-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: JSON standard does not allow comments.
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 22-22: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 22-22: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 22-22: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 22-22: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 23-23: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 23-23: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 23-23: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 23-23: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 24-24: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 24-24: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 24-24: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 25-25: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 26-26: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 26-26: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 26-26: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 26-27: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
3-8: Verify browser compatibility requirements
The configuration targets ES2020 and uses modern features like class fields. This might affect browser compatibility, especially for older browsers.
Consider:
- Documenting minimum browser version requirements
- Adding appropriate polyfills
- Using a more conservative target if wider browser support is needed
packages/block-compiler/tsconfig.node.json (4)
10-15: LGTM! Modern bundler configuration
The bundler mode configuration is well-structured and follows modern TypeScript practices for use with Vite.
🧰 Tools
🪛 Biome (1.9.4)
[error] 10-10: JSON standard does not allow comments.
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-15: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-15: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-15: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
17-22: LGTM! Comprehensive type safety configuration
The linting options enforce strict type checking and prevent common issues, which is crucial for a compiler package.
🧰 Tools
🪛 Biome (1.9.4)
[error] 17-17: JSON standard does not allow comments.
(parse)
[error] 18-18: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 18-18: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 18-18: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 18-18: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 22-22: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 22-22: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 22-22: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
24-24: Expand include patterns for source and test files
The current include patterns only cover configuration files. For a compiler package, you should include:
- Source files for the compiler implementation
- Test files as mentioned in PR objectives
- "include": ["./vite.config.ts", "./.eslintrc.cjs"]
+ "include": [
+ "./vite.config.ts",
+ "./.eslintrc.cjs",
+ "src/**/*.ts",
+ "src/**/*.tsx",
+ "tests/**/*.ts",
+ "tests/**/*.spec.ts"
+ ]🧰 Tools
🪛 Biome (1.9.4)
[error] 24-24: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 24-24: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 24-24: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 24-25: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
1-25: Document breaking changes
The PR indicates this introduces breaking changes, but there's no documentation explaining the impact. Please:
- Document the breaking changes in the package's README or CHANGELOG
- Consider adding a comment in this config file explaining any TypeScript-level breaking changes
🧰 Tools
🪛 Biome (1.9.4)
[error] 10-10: JSON standard does not allow comments.
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-15: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-15: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-15: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-17: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 17-17: JSON standard does not allow comments.
(parse)
[error] 18-18: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 18-18: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 18-18: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 18-18: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 22-22: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 22-22: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 22-22: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 23-23: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 24-24: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 24-24: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 24-24: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 24-25: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
packages/block-compiler/src/index.ts (1)
1-4: Consider pinning Vue compiler version
To ensure consistent behavior across different environments, consider pinning the Vue compiler version in your package.json.
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Nitpick comments (1)
packages/block-compiler/tsconfig.json (1)
2-10: Consider relocating the tsBuildInfo fileStoring the build info file in
node_modules/.tmpmight lead to unexpected rebuilds when thenode_modulesdirectory is cleaned. Consider moving it to a more persistent location likedistor.cache.- "tsBuildInfoFile": "./node_modules/.tmp/tsconfig.app.tsbuildinfo", + "tsBuildInfoFile": "./dist/.tsbuildinfo",
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
packages/block-compiler/src/index.ts(1 hunks)packages/block-compiler/tsconfig.json(1 hunks)packages/block-compiler/tsconfig.node.json(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- packages/block-compiler/tsconfig.node.json
🔇 Additional comments (8)
packages/block-compiler/tsconfig.json (2)
11-18: Verify JSX handling compatibility with Vue SFC compilation
The jsx: "preserve" setting needs verification to ensure it properly handles Vue's JSX/TSX components in the block compiler context.
#!/bin/bash
# Check for Vue JSX/TSX usage patterns in the codebase
echo "Checking for Vue JSX/TSX usage patterns..."
# Look for Vue components using JSX/TSX
ast-grep --pattern 'export default defineComponent({
$$$
render() {
return $$$
}
$$$
})'
# Check for potential JSX pragma definitions
rg -l "^/// <reference types=\"vue/jsx\"" 25-26: 🛠️ Refactor suggestion
Add output directory configuration and verify referenced config
The configuration should specify an output directory to prevent cluttering source directories with compiled files. Also, ensure the referenced tsconfig.node.json exists.
#!/bin/bash
# Verify the referenced tsconfig.node.json and suggest outDir configuration
echo "Checking for tsconfig.node.json..."
if [ -f "packages/block-compiler/tsconfig.node.json" ]; then
echo "Found tsconfig.node.json"
cat "packages/block-compiler/tsconfig.node.json"
else
echo "Missing tsconfig.node.json"
fi },
+ "outDir": "./dist",
"include": ["./src/**/*.ts", "./src/**/*.tsx", "./src/**/*.vue"],
"references": [{ "path": "./tsconfig.node.json" }]packages/block-compiler/src/index.ts (6)
20-49: Improve type safety and error handling in template compilation
The template compilation has unsafe type assertions and incomplete error handling.
This issue was previously identified in an earlier review. Please refer to the existing comment for the proposed solution.
85-112: Add error handling in script compilation
This issue was previously identified in an earlier review. Please refer to the existing comment about adding try-catch implementation.
197-201: Prevent memory leaks from unrevoked Blob URLs
This issue was previously identified in an earlier review. Please refer to the existing comment about implementing blob URL cleanup.
232-235:
Implement TODO items for file validation
The TODO comments indicate missing validations that are critical for proper functionality.
Apply this diff to implement the validations:
+ // Validate file extension
+ if (!fileName.endsWith('.vue')) {
+ throw new Error('Only .vue files are supported')
+ }
+
+ // Validate style language
+ if (descriptor.styles.some(style => style.lang && style.lang !== 'css')) {
+ throw new Error('Only CSS styles are supported')
+ }
+
+ // Validate template language
+ if (descriptor.template?.lang) {
+ throw new Error('Template language is not supported')
+ }Likely invalid or redundant comment.
221-222:
Remove @ts-ignore and implement proper typing
Using @ts-ignore suppresses potential type safety issues that should be addressed.
Apply this diff to fix typing:
-// @ts-ignore
-export const compile = (fileList: IFileList, config) => {
+export const compile = (fileList: IFileList, config?: IConfig) => {Likely invalid or redundant comment.
61-80:
Add security validations for import resolution
The resolveRelativeImport function modifies import paths without proper validation, which could lead to security vulnerabilities.
Apply this diff to add security validations:
const resolveRelativeImport = (code: string, resultMap: IResultMap) => {
+ if (!code || typeof code !== 'string') {
+ throw new Error('Invalid code input')
+ }
+
const magicStr = new MagicString(code)
- const ast = babelParse(code, { sourceType: 'module', plugins: ['jsx'] }).program.body
+ let ast
+ try {
+ ast = babelParse(code, { sourceType: 'module', plugins: ['jsx'] }).program.body
+ } catch (error) {
+ throw new Error(`Failed to parse code: ${error.message}`)
+ }
for (const node of ast) {
if (node.type === 'ImportDeclaration') {
const source = node.source.value
+ if (typeof source !== 'string') {
+ throw new Error('Invalid import source')
+ }
if (source.startsWith('./')) {
+ // Sanitize file name to prevent path traversal
+ if (source.includes('..')) {
+ throw new Error('Path traversal not allowed')
+ }
const fileName = node.source.value.replace(/^(\.\/+)/, '').slice(0, -4)
if (resultMap[fileName]) {
magicStr.overwrite(node.source.start!, node.source.end!, `'${resultMap[fileName].blobURL}'`)
}
}
}
}
return magicStr.toString()
}Likely invalid or redundant comment.
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
packages/block-compiler/src/index.ts (2)
22-26: Avoid mutating the expressionPlugins arrayConsider creating a new array instead of mutating the existing one.
- const expressionPlugins: CompilerOptions['expressionPlugins'] = [] - if (isJsx) { - expressionPlugins.push('jsx') - } + const expressionPlugins: CompilerOptions['expressionPlugins'] = isJsx ? ['jsx'] : []
51-55: Export the compiledItem interfaceThe interface is used in exported interfaces but is not exported itself.
-interface compiledItem { +export interface compiledItem { js: string style: string blobURL: string }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
packages/block-compiler/src/dev.ts(1 hunks)packages/block-compiler/src/index.ts(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- packages/block-compiler/src/dev.ts
🔇 Additional comments (6)
packages/block-compiler/src/index.ts (6)
5-18: Add error handling for style compilation
The style compilation lacks proper error handling and language validation.
31-32: Improve type safety for template compilation
The code uses non-null assertion without validating template existence.
41-48: Improve error handling in template compilation
The template compilation errors are returned but not handled properly.
92-102: Add error handling in compileBlockScript function
The function lacks proper error handling when calling compileScript.
195-199: Prevent memory leaks from unrevoked Blob URLs
The current implementation creates Blob URLs but doesn't provide a mechanism to revoke them.
225-227: Throw errors when parsing fails in compile function
The function currently does not throw errors if parsing the source code fails.
There was a problem hiding this comment.
Actionable comments posted: 8
🧹 Nitpick comments (5)
packages/canvas/render/src/render.js (2)
219-223: Consider Customizable Error ResponseThe catch block returns a hardcoded empty result structure which might not be suitable for all API responses.
Consider making the error response structure configurable:
- resolve({ - result: [{}], - page: { total: 1 } - }) + resolve(configure.defaultErrorResponse || { + result: [{}], + page: { total: 1 } + })
612-615: Simplify Conditional Rendering LogicThe nested conditional structure could be simplified for better readability.
- if (isNative) { - return renderDefault(renderChildren, mergeScope, schema) - } else { - return isGroup ? renderGroup(renderChildren, mergeScope, schema) : renderSlot(renderChildren, mergeScope, schema) - } + return isNative + ? renderDefault(renderChildren, mergeScope, schema) + : isGroup + ? renderGroup(renderChildren, mergeScope, schema) + : renderSlot(renderChildren, mergeScope, schema)packages/block-compiler/src/index.ts (1)
98-98: Address TODO comment about type declarationsThe TODO comment indicates that type declarations need to be split into another function. This separation would improve code organization and maintainability.
Would you like me to help create a separate function for handling type declarations?
packages/plugins/materials/src/composable/block-compile.js (2)
4-4: Consider implementing cache limits and cleanupThe global
blockCompileCacheMap could potentially grow unbounded. Consider implementing:
- Maximum cache size
- Cache expiration mechanism
- Memory usage monitoring
9-9: Clarify or remove TODO commentThe comment "待验证" (waiting for verification) should be replaced with specific details about what needs to be verified.
Would you like me to help create validation tests for this function?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
packages/block-compiler/src/dev.ts(1 hunks)packages/block-compiler/src/index.ts(1 hunks)packages/canvas/render/src/render.js(8 hunks)packages/plugins/materials/src/composable/block-compile.js(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- packages/block-compiler/src/dev.ts
🔇 Additional comments (9)
packages/canvas/render/src/render.js (4)
14-14: Avoid Importing Internal APIs from '@vue/shared'
Importing isHTMLTag from @vue/shared relies on internal Vue APIs that may change without notice. This can lead to compatibility issues in the future. Consider using public APIs or implementing a custom check if necessary.
670-680: LGTM: Well-implemented Suspense Integration
The integration of Suspense for Block components is well-implemented, providing a good user experience during loading states.
210-210:
Improve Promise Detection
The check if (result.then) is not a reliable way to detect Promises. The then property might exist but not be a function.
Use this more robust check:
-if (result.then) {
+if (result && typeof result.then === 'function') {Likely invalid or redundant comment.
266-269:
Fix Key Inconsistency in Component Cache
The component is cached with fileName but retrieved with name, which could lead to cache misses.
- fileName,
+ name,Likely invalid or redundant comment.
packages/block-compiler/src/index.ts (5)
5-18: Add error handling for style compilation
The existing review comment about adding error handling for style compilation is still applicable here.
20-49: Improve template compilation safety
The existing review comments about improving type safety and error handling in template compilation are still applicable here.
125-152: Add error handling in script compilation
The existing review comment about adding error handling in the compileBlockScript function is still applicable here.
163-190: Add comprehensive error handling
The existing review comment about adding comprehensive error handling in the compileFile function is still applicable here.
235-239: Prevent memory leaks from unrevoked Blob URLs
The existing review comment about preventing memory leaks from unrevoked Blob URLs is still applicable here.
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (3)
packages/canvas/render/src/render.js (1)
675-685: Consider adding error boundaries around SuspenseWhile the Suspense wrapper provides loading states, it doesn't handle rendering errors that might occur after loading.
Consider wrapping the Suspense component with an error boundary:
+const ErrorBoundary = { + name: 'ErrorBoundary', + setup() { + const error = ref(null) + onErrorCaptured((err) => { + error.value = err + return false + }) + return { error } + }, + render() { + return this.error + ? h(BlockLoadError, { error: this.error }) + : this.$slots.default() + } +} if (schema.componentType === 'Block') { return h( + ErrorBoundary, + {}, + () => h( Suspense, {}, { default: () => Ele, fallback: () => h(BlockLoading, { name: componentName }) } + ) ) }packages/block-compiler/src/index.ts (2)
1-3: Consider pinning the Vue compiler versionThe Vue compiler is a critical dependency. To ensure consistent behavior across environments and prevent unexpected breaking changes, consider pinning the version in your package.json.
51-55: Follow TypeScript naming conventionsInterface names should use PascalCase. Rename
compiledItemtoCompiledItemto follow TypeScript conventions.-interface compiledItem { +interface CompiledItem { js: string style: string blobURL: string }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
packages/block-compiler/src/index.ts(1 hunks)packages/canvas/render/src/render.js(8 hunks)
🔇 Additional comments (6)
packages/canvas/render/src/render.js (4)
14-14: Avoid using internal Vue.js APIs
Using isHTMLTag from @vue/shared relies on Vue's internal APIs that may change without notice in future versions.
Consider implementing a custom HTML tag validation or using a public API alternative.
210-210:
Improve Promise detection logic
The check if (result.then) is not a reliable way to detect Promises as it doesn't verify if then is actually a function.
Use this more reliable Promise detection:
-if (result.then) {
+if (result && typeof result.then === 'function') {Likely invalid or redundant comment.
277-286:
Add cleanup for injected styles
Styles injected into the document head are never cleaned up when components are removed or updated.
Add cleanup logic in the removeBlockCompsCacheByName function:
if (blockComponentsMap.has(name)) {
blockComponentsMap.delete(name)
+ const stylesheet = document.querySelector(`#${name}`)
+ stylesheet?.parentNode?.removeChild(stylesheet)
}Likely invalid or redundant comment.
249-250: Verify block component cache cleanup
The implementation uses Maps for caching components and blob URLs. Let's verify that all cached resources are properly cleaned up.
✅ Verification successful
Based on the results, I can now generate the final response as the scripts have provided comprehensive information about the block component caching implementation and cleanup.
Block component cache cleanup is properly implemented
The codebase shows a well-structured cleanup mechanism:
removeBlockCompsCacheByNamefunction properly cleans up both Maps (blockComponentsMap and blockComponentsBlobUrlMap)- The cleanup is accessible through the canvas API and is being used in the materials plugin
- The cache is properly scoped and managed within the render context
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for all block component references and their cleanup
echo "Searching for block component references..."
rg -A 5 "blockComponentsMap"
echo "Searching for cleanup implementations..."
rg -A 5 "removeBlockCompsCacheByName"
echo "Checking for potential memory leak patterns..."
ast-grep --pattern 'new Map()'
Length of output: 6008
packages/block-compiler/src/index.ts (2)
5-18: Add error handling for style compilation
This issue was previously identified in a past review. The function needs proper error handling for compilation failures and style language validation.
246-247: Address FIXME: Clarify parsing results reuse
The FIXME comment suggests potential issues with reusing parsing results. This needs to be clarified and properly documented.
Would you like help implementing a solution that safely handles parsing result modifications?
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
packages/plugins/materials/src/composable/block-compile.js (1)
6-7:⚠️ Potential issueAdd error handling for API requests
The function needs proper error handling for:
- Network failures
- Invalid blockName parameter
- Request timeouts
- Non-200 responses
🧹 Nitpick comments (2)
packages/plugins/materials/src/composable/block-compile.js (2)
1-4: Consider migrating to TypeScript for better type safetyGiven this is a new file introducing critical block compilation functionality, TypeScript would provide:
- Type safety for the cache Map entries
- Better IDE support and documentation
- Clearer interfaces for the imported services
9-9: Address the TODO commentThe TODO comment "待验证" (waiting for verification) needs to be addressed before merging.
Would you like me to help create verification tests for this functionality?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
packages/plugins/materials/src/composable/block-compile.js(1 hunks)
🔇 Additional comments (4)
packages/plugins/materials/src/composable/block-compile.js (4)
19-53:
Add input validation and error handling for compilation process
The function lacks proper validation and error handling for critical operations:
- Schema validation
- External service calls
- Compilation process
Additionally, consider caching the componentsMap to avoid repeated lookups:
export const getBlockCompileRes = async (schema) => {
+ if (!schema?.fileName) {
+ throw new Error('Invalid schema: fileName is required')
+ }
const name = schema.fileName
if (blockCompileCache.has(name)) {
return {
[name]: blockCompileCache.get(name)
}
}
const generateCodeService = getMetaApi('engine.service.generateCode')
+ if (!generateCodeService) {
+ throw new Error('Code generation service not available')
+ }
+ const componentsMap = useResource().resState.componentsMap || []
+ if (!componentsMap.length) {
+ console.warn('Components map is empty')
+ }
- const blocks = await generateCodeService.getAllNestedBlocksSchema(schema, fetchBlockSchema)
+ let blocks
+ try {
+ blocks = await generateCodeService.getAllNestedBlocksSchema(schema, fetchBlockSchema)
+ } catch (error) {
+ throw new Error(`Failed to fetch nested blocks: ${error.message}`)
+ }Likely invalid or redundant comment.
10-16:
Add error handling and logging for cache operations
The cache operations could fail silently. Consider:
- Adding logging for cache operations
- Verifying canvas API availability
- Handling errors from removeBlockCompsCacheByName
export const updateBlockCompileCache = (name) => {
+ if (!name) {
+ console.warn('updateBlockCompileCache: name parameter is required')
+ return
+ }
+
if (blockCompileCache.has(name)) {
+ console.debug(`Removing ${name} from block compile cache`)
blockCompileCache.delete(name)
- useCanvas().canvasApi.value?.removeBlockCompsCacheByName(name)
+ const canvas = useCanvas()
+ if (!canvas.canvasApi?.value) {
+ console.warn('Canvas API not available')
+ return
+ }
+ try {
+ canvas.canvasApi.value.removeBlockCompsCacheByName(name)
+ } catch (error) {
+ console.error(`Failed to remove block components cache for ${name}:`, error)
+ }
}
}Likely invalid or redundant comment.
56-85:
Document breaking changes and add proper error handling
This function introduces breaking changes but lacks:
- Documentation of the breaking changes
- Migration guide for existing users
- Proper error handling instead of silent returns
Please add:
- Documentation explaining the breaking changes
- Migration guide for existing applications
- Error handling as shown in the diff:
export const getBlockByName = async (name) => {
+ if (!name) {
+ throw new Error('Block name is required')
+ }
const block = await fetchBlockSchema(name)
const blockItem = block?.[0]
if (!blockItem) {
- return
+ throw new Error(`Block not found: ${name}`)
}
// ... rest of the function
if (!schemaContent) {
- return
+ throw new Error(`No content found for block: ${name}`)
}
+ try {
useMaterial().addBlockResources(name, schemaContent)
+ } catch (error) {
+ throw new Error(`Failed to add block resources: ${error.message}`)
+ }
return getBlockCompileRes(schemaContent)
}Would you like me to help create:
- Breaking changes documentation?
- Migration guide?
Likely invalid or redundant comment.
1-85: Verify the impact of breaking changes
Let's verify the usage of these new functions across the codebase to assess the impact of breaking changes.
✅ Verification successful
Breaking changes appear to be safely contained
Based on the search results, the block compilation functions are used in a controlled manner across the codebase:
- The block compilation functionality is only used within the materials plugin and related core components
blockCompileCacheis only used withinblock-compile.jsand not exposed directly- The functions are imported and used in expected locations:
packages/common/composable/generateCode/index.jspackages/toolbars/generate-code/src/http.jspackages/plugins/materials/src/composable/useMaterial.jspackages/design-core/src/preview/src/preview/http.jspackages/canvas/render/src/render.js
No error handling patterns were found that would be affected by these changes, and the block compiler import is properly configured in the build system.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check usage of block compilation functions across the codebase
echo "Checking function usage patterns..."
# Check for direct function calls
rg -l "fetchBlockSchema|updateBlockCompileCache|getBlockCompileRes|getBlockByName" \
--type js --type vue --type ts
# Check for potential error handling patterns
echo "\nChecking error handling patterns..."
rg "try.*catch.*fetchBlockSchema|try.*catch.*getBlockByName" \
--type js --type vue --type ts -C 2
# Look for existing block compilation patterns that might break
echo "\nChecking existing block compilation patterns..."
rg "registerBlock|compileBlock|blockCompiler" \
--type js --type vue --type ts -C 2
Length of output: 657
Script:
#!/bin/bash
# Description: Check usage of block compilation functions across the codebase with correct file type flags
echo "Checking function usage patterns..."
# Check for direct function calls
rg -l "fetchBlockSchema|updateBlockCompileCache|getBlockCompileRes|getBlockByName" \
--type javascript --type typescript
echo "\nChecking error handling patterns..."
# Check for potential error handling patterns
rg "try.*catch.*fetchBlockSchema|try.*catch.*getBlockByName" \
--type javascript --type typescript -C 2
echo "\nChecking block compilation imports and usage..."
# Check imports and usage of block compiler
rg "@opentiny/tiny-engine-block-compiler" \
--type javascript --type typescript -C 2
# Check usage of block compilation cache
rg "blockCompileCache" \
--type javascript --type typescript -C 2
Length of output: 786
Script:
#!/bin/bash
# Description: Check usage of block compilation functions across the codebase using basic file extensions
echo "Checking function usage patterns..."
# Check for direct function calls
rg -l "fetchBlockSchema|updateBlockCompileCache|getBlockCompileRes|getBlockByName" \
-g "*.js" -g "*.ts"
echo "\nChecking error handling patterns..."
# Check for potential error handling patterns
rg "try.*catch.*fetchBlockSchema|try.*catch.*getBlockByName" \
-g "*.js" -g "*.ts" -C 2
echo "\nChecking block compilation imports and usage..."
# Check imports and usage of block compiler
rg "@opentiny/tiny-engine-block-compiler" \
-g "*.js" -g "*.ts" -C 2
# Check usage of block compilation cache
rg "blockCompileCache" \
-g "*.js" -g "*.ts" -C 2
Length of output: 4410
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (4)
packages/block-compiler/src/index.ts (4)
22-26: Consider using a more type-safe approach for expressionPluginsThe current implementation modifies the array after initialization. Consider initializing it with the required plugins based on the JSX condition.
- const expressionPlugins: CompilerOptions['expressionPlugins'] = [] - - if (isJsx) { - expressionPlugins.push('jsx') - } + const expressionPlugins: CompilerOptions['expressionPlugins'] = isJsx ? ['jsx'] : []
98-98: Address TODO comment about type declarationsThe TODO comment suggests that type declarations need to be extracted to another function. This separation would improve code organization and maintainability.
Would you like me to help create a separate function for handling type declarations?
101-118: Simplify Vue import handling logicThe current implementation has complex nested conditions for handling Vue imports. Consider extracting this logic into a separate function for better maintainability.
+const addDefineAsyncComponentImport = (magicStr: MagicString, vueImportNode: any, ast: any[]) => { + if (vueImportNode) { + const asyncSpec = vueImportNode.specifiers.find( + (spec) => spec.type === 'ImportSpecifier' && spec.local.name === 'defineAsyncComponent' + ) + if (!asyncSpec) { + const firstRelativeSpec = vueImportNode.specifiers.find((spec) => spec.type === 'ImportSpecifier') + firstRelativeSpec + ? magicStr.appendLeft(firstRelativeSpec.start!, 'defineAsyncComponent, ') + : magicStr.appendRight(vueImportNode.specifiers[0].end!, ', { defineAsyncComponent }') + } + } else { + magicStr.appendLeft(ast[0].start!, "import { defineAsyncComponent } from 'vue'\n") + } +}
243-308: Consider implementing a more robust compilation pipelineThe current implementation could benefit from:
- A proper error aggregation system
- Progress tracking for long-running compilations
- Memory management for large compilations
Consider implementing:
- An event emitter for compilation progress
- A streaming compilation pipeline for large files
- A proper cleanup mechanism for compilation artifacts
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
packages/block-compiler/package.json(1 hunks)packages/block-compiler/src/index.ts(1 hunks)packages/block-compiler/vite.config.ts(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- packages/block-compiler/vite.config.ts
- packages/block-compiler/package.json
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
packages/plugins/materials/src/meta/block/src/BlockVersionSelect.vue (1)
90-100: Document breaking change in version handlingThis change significantly modifies the version switching behavior by removing the page refresh step. This is a breaking change that needs to be documented:
- The previous behavior required a page refresh after version changes
- The new behavior updates in-place using cache and canvas refresh
Consider:
- Adding a comment explaining why the refresh is no longer needed
- Updating the documentation to reflect this behavioral change
- Adding a migration guide for users updating from previous versions
Would you like me to help create a migration guide or documentation update?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
packages/plugins/materials/src/meta/block/src/BlockVersionSelect.vue(2 hunks)
🔇 Additional comments (3)
packages/plugins/materials/src/meta/block/src/BlockVersionSelect.vue (3)
39-39: LGTM: Import changes align with new functionality
The new imports from '@opentiny/tiny-engine-meta-register' are necessary for the block cache update and canvas refresh functionality.
94-100: Remove commented out code
The commented-out confirmation dialog code should be removed as it's no longer needed.
90-93:
Verify error handling for cache and canvas updates
The new cache update and canvas refresh operations could potentially fail. Consider adding error handling for these operations:
Suggested implementation:
- useMaterial().updateBlockCompileCache(selectedRow.content?.fileName)
- useCanvas().canvasApi.value?.updateCanvas()
+ try {
+ await useMaterial().updateBlockCompileCache(selectedRow.content?.fileName)
+ await useCanvas().canvasApi.value?.updateCanvas()
+ } catch (error) {
+ message({
+ title: '更新失败',
+ message: `更新区块缓存或画布失败：${error.message || error}`
+ })
+ }
chilingling
force-pushed
the
feat/blockCompiler
branch
from
ceb73e0 to
51d6716
Compare
There was a problem hiding this comment.
Actionable comments posted: 8
🧹 Nitpick comments (11)
packages/plugins/block/src/js/blockSetting.jsx (1)
502-504: Consider awaiting the async refresh call before showing success notification.Since refreshBlockData is an async function, you might want to ensure it completes before displaying a success message. This helps users avoid a scenario where they see a “success” notification even though the data hasn’t finished updating.
Example approach:
requestDeployBlock(params) - .then(() => { - refreshBlockData(block) - useNotify({ message: '区块发布成功!', type: 'success' }) - }) + .then(async () => { + await refreshBlockData(block) + useNotify({ message: '区块发布成功!', type: 'success' }) + }) .catch((error) => { ... })packages/canvas/render/src/RenderMain.js (1)
380-380: Convert TODO comment to tracked issueThe TODO comment indicates a significant architectural change regarding i18n handling and webComponent support. This should be tracked as a separate issue to ensure proper planning and implementation.
Would you like me to help create a GitHub issue to track this architectural change? The issue would include:
- Current state: Using webComponent-based i18n provider
- Target state: Remove webComponent dependency for blocks
- Impact analysis
- Migration steps
packages/canvas/render/src/render.js (2)
227-229: Consider Configurable Error Response StructureThe hardcoded error response structure might not be suitable for all API endpoints.
Consider making it configurable:
+const DEFAULT_ERROR_RESPONSE = { + result: [{}], + page: { total: 1 } +} resolve({ - result: [{}], - page: { total: 1 } + ...(configure.defaultErrorResponse || DEFAULT_ERROR_RESPONSE) })
683-693: Consider Adding Error BoundaryWhile Suspense handles the loading state well, consider adding an error boundary to gracefully handle runtime errors in the block components.
Consider implementing an error boundary component:
const BlockErrorBoundary = { name: 'BlockErrorBoundary', props: ['name'], errorCaptured(err) { return h(BlockLoadError, { name: this.name, error: err }) }, render() { return this.$slots.default() } }Then wrap the Suspense with it:
+return h(BlockErrorBoundary, + { name: componentName }, + () => h( Suspense, {}, { default: () => Ele, fallback: () => h(BlockLoading, { name: componentName }) } ) +)packages/block-compiler/tsconfig.node.json (1)
3-8: Consider relocating the build info fileThe
tsBuildInfoFileis currently stored innode_modules/.tmp, which is typically gitignored. Consider moving it to a more permanent location like.tsbuildinfoin the package root or a dedicatedbuilddirectory.- "tsBuildInfoFile": "./node_modules/.tmp/tsconfig.node.tsbuildinfo", + "tsBuildInfoFile": "./build/tsconfig.node.tsbuildinfo",packages/plugins/materials/src/composable/useMaterial.js (2)
161-161: Deprecated function usage.
This function is annotated with “@deprecated” but still appears active. Consider removing it or providing a clear alternative if it is truly deprecated.
431-438: Input validation for addBlockResources.
While this function is straightforward, consider adding simple checks to ensure “id” and “resource” are valid before storing them in blockResource.packages/canvas/DesignCanvas/src/importMap.js (1)
17-19: Hard-coded version references.
“[email protected]” and other pinned versions can cause incompatibilities if consumers need different patch releases. Ensure alignment with project-wide versioning policies.packages/plugins/materials/src/composable/block-compile.js (2)
18-53: Consider validating schema before compilation.
If schema.fileName is undefined or schema is invalid, blockCompiler may fail. Consider adding validation checks.
55-85: getBlockByName: No error notification on returning undefined.
When “schemaContent” doesn’t exist, the function simply returns, giving no user-facing feedback. For consistency, you might consider throwing an error or using a notification to inform users that the block is missing or invalid.packages/plugins/materials/src/meta/block/src/BlockVersionSelect.vue (1)
90-100: Refined version switch flow.
Replacing the old UI confirm/refresh approach with “updateBlockCompileCache” and “updateCanvas” is user-friendly and more direct. However, if a manual page refresh is still necessary in certain scenarios, consider adding an optional prompt.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (45)
packages/block-compiler/.eslintrc.cjs(1 hunks)packages/block-compiler/README.md(1 hunks)packages/block-compiler/index.html(1 hunks)packages/block-compiler/package.json(1 hunks)packages/block-compiler/src/dev.ts(1 hunks)packages/block-compiler/src/index.ts(1 hunks)packages/block-compiler/src/transformJsx.ts(1 hunks)packages/block-compiler/src/vite-env.d.ts(1 hunks)packages/block-compiler/test/sample/BlockFileName.vue(1 hunks)packages/block-compiler/test/sample/BlockHead.vue(1 hunks)packages/block-compiler/test/sample/BlockMenu.vue(1 hunks)packages/block-compiler/test/sample/BlockTest.vue(1 hunks)packages/block-compiler/test/sample/slotModelValueTest.vue(1 hunks)packages/block-compiler/tsconfig.json(1 hunks)packages/block-compiler/tsconfig.node.json(1 hunks)packages/block-compiler/vite.config.ts(1 hunks)packages/build/vite-config/src/vite-plugins/devAliasPlugin.js(1 hunks)packages/canvas/DesignCanvas/src/DesignCanvas.vue(1 hunks)packages/canvas/DesignCanvas/src/importMap.js(1 hunks)packages/canvas/container/src/container.js(1 hunks)packages/canvas/package.json(1 hunks)packages/canvas/render/src/BlockLoadError.vue(1 hunks)packages/canvas/render/src/BlockLoading.vue(1 hunks)packages/canvas/render/src/RenderMain.js(4 hunks)packages/canvas/render/src/lowcode.js(2 hunks)packages/canvas/render/src/render.js(8 hunks)packages/canvas/render/src/runner.js(0 hunks)packages/canvas/render/src/supportUmdBlock.js(0 hunks)packages/common/component/PluginBlockList.vue(1 hunks)packages/common/component/ProgressBar.vue(0 hunks)packages/common/component/index.js(0 hunks)packages/common/composable/generateCode/index.js(1 hunks)packages/design-core/package.json(1 hunks)packages/design-core/src/preview/src/preview/importMap.json(1 hunks)packages/layout/src/DesignToolbars.vue(1 hunks)packages/plugins/block/src/BlockSetting.vue(0 hunks)packages/plugins/block/src/js/blockSetting.jsx(1 hunks)packages/plugins/block/src/js/http.js(0 hunks)packages/plugins/materials/package.json(1 hunks)packages/plugins/materials/src/composable/block-compile.js(1 hunks)packages/plugins/materials/src/composable/useMaterial.js(6 hunks)packages/plugins/materials/src/composable/useResource.js(1 hunks)packages/plugins/materials/src/meta/block/src/BlockList.vue(2 hunks)packages/plugins/materials/src/meta/block/src/BlockVersionSelect.vue(2 hunks)packages/vue-generator/src/constant/index.js(1 hunks)
💤 Files with no reviewable changes (6)
- packages/plugins/block/src/BlockSetting.vue
- packages/common/component/index.js
- packages/canvas/render/src/runner.js
- packages/plugins/block/src/js/http.js
- packages/common/component/ProgressBar.vue
- packages/canvas/render/src/supportUmdBlock.js
✅ Files skipped from review due to trivial changes (1)
- packages/block-compiler/src/vite-env.d.ts
🚧 Files skipped from review as they are similar to previous changes (27)
- packages/block-compiler/test/sample/BlockTest.vue
- packages/block-compiler/tsconfig.json
- packages/block-compiler/README.md
- packages/block-compiler/test/sample/BlockMenu.vue
- packages/canvas/render/src/BlockLoading.vue
- packages/block-compiler/test/sample/BlockHead.vue
- packages/plugins/materials/package.json
- packages/block-compiler/.eslintrc.cjs
- packages/block-compiler/test/sample/BlockFileName.vue
- packages/canvas/render/src/BlockLoadError.vue
- packages/design-core/package.json
- packages/block-compiler/vite.config.ts
- packages/block-compiler/src/dev.ts
- packages/canvas/package.json
- packages/design-core/src/preview/src/preview/importMap.json
- packages/block-compiler/index.html
- packages/block-compiler/test/sample/slotModelValueTest.vue
- packages/block-compiler/src/transformJsx.ts
- packages/plugins/materials/src/meta/block/src/BlockList.vue
- packages/canvas/render/src/lowcode.js
- packages/layout/src/DesignToolbars.vue
- packages/block-compiler/package.json
- packages/common/composable/generateCode/index.js
- packages/build/vite-config/src/vite-plugins/devAliasPlugin.js
- packages/common/component/PluginBlockList.vue
- packages/canvas/container/src/container.js
- packages/vue-generator/src/constant/index.js
🧰 Additional context used
🪛 Biome (1.9.4)
packages/block-compiler/tsconfig.node.json
[error] 10-10: JSON standard does not allow comments.
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-15: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-15: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-15: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-17: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 17-17: JSON standard does not allow comments.
(parse)
[error] 18-18: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 18-18: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 18-18: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 18-18: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 22-22: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 23-23: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 23-23: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 23-23: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 23-24: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
🔇 Additional comments (26)
packages/canvas/render/src/RenderMain.js (3)
470-472: LGTM: API exports properly updated
The new methods removeBlockCompsCacheByName and updateCanvas are correctly added to the public API, maintaining consistency with the existing export pattern.
398-400: Verify canvas update trigger points
The new updateCanvas function forces a full canvas re-render by incrementing refreshKey. While this is a valid approach, it could impact performance if not used judiciously.
✅ Verification successful
Based on the search results, I can now generate the final response as the usage pattern of updateCanvas is clear from the codebase:
Canvas update trigger is used appropriately
The updateCanvas function is only called in specific, user-initiated scenarios:
- When switching block versions in
BlockVersionSelect.vue - The function is exposed through the canvas API but shows limited usage
This implementation follows good practices as the canvas refresh is triggered only during necessary UI updates, not in any high-frequency operations or loops that could impact performance.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for potential usage of updateCanvas to ensure it's not called too frequently
rg "updateCanvas" --type js --type ts -C 3
Length of output: 4158
19-26: Verify usage of new block cache management function
The newly imported removeBlockCompsCacheByName function should be used consistently across the codebase where block component cache management is needed.
✅ Verification successful
The search results provide a clear picture of how removeBlockCompsCacheByName is integrated into the codebase. Let me generate the final response:
Import of removeBlockCompsCacheByName is correctly integrated
The function is properly integrated in a consistent flow:
- Defined in
render.jsas a cache cleanup function for block components - Exposed through
RenderMain.jsas part of the public API - Accessible via canvas container's API surface
- Utilized in materials plugin's block compilation logic
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for usage of removeBlockCompsCacheByName across the codebase
rg "removeBlockCompsCacheByName" --type js --type ts -C 2
Length of output: 1854
packages/canvas/render/src/render.js (4)
13-14: Avoid Importing Internal APIs from '@vue/shared'
The use of isHTMLTag from @vue/shared relies on internal Vue APIs that may change without notice.
218-218:
Improve Promise Detection
The check if (result.then) may not reliably detect Promise objects, as then could be a property rather than a function.
Apply this diff:
-if (result.then) {
+if (result && typeof result.then === 'function') {Likely invalid or redundant comment.
274-277:
Ensure Consistent Key Usage in Component Map
The component is stored with fileName as key but retrieved with name, which could lead to retrieval failures.
Apply this diff:
blockComponentsMap.set(
- fileName,
+ name,
defineAsyncComponent(() => import(/* @vite-ignore */ value.blobURL))
)Likely invalid or redundant comment.
285-294: 🛠️ Refactor suggestion
Add Style Cleanup on Component Removal
Injected styles are never cleaned up when components are removed or updated.
Add cleanup logic in the removeBlockCompsCacheByName function:
export const removeBlockCompsCacheByName = (name) => {
if (blockComponentsMap.has(name)) {
blockComponentsMap.delete(name)
+ const stylesheet = document.querySelector(`#${name}`)
+ stylesheet?.parentNode?.removeChild(stylesheet)
}
}Likely invalid or redundant comment.
packages/block-compiler/tsconfig.node.json (2)
17-21: LGTM! Good type-safety configuration
The strict type-checking options will help catch potential issues early in development.
🧰 Tools
🪛 Biome (1.9.4)
[error] 17-17: JSON standard does not allow comments.
(parse)
[error] 18-18: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 18-18: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 18-18: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 18-18: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
23-23: Consider expanding include patterns for source and test files
The current include patterns only cover configuration files. Consider adding:
- Source files:
src/**/*.ts,src/**/*.tsx - Test files:
tests/**/*.ts,tests/**/*.spec.ts - Type declaration files:
*.d.ts
- "include": ["vite.config.ts", ".eslintrc.cjs"]
+ "include": [
+ "vite.config.ts",
+ ".eslintrc.cjs",
+ "src/**/*.ts",
+ "src/**/*.tsx",
+ "tests/**/*.ts",
+ "tests/**/*.spec.ts",
+ "*.d.ts"
+ ]🧰 Tools
🪛 Biome (1.9.4)
[error] 23-23: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 23-23: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 23-23: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 23-24: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
packages/plugins/materials/src/composable/useMaterial.js (4)
26-26: Import is correct and consistent.
The addition of “getBlockCompileRes”, “getBlockByName”, and “updateBlockCompileCache” aligns well with the new block-compile functionalities.
308-310: Asynchronous operations are not awaited.
This code calls getBlockCompileRes(item) within a map without using await or Promise.all, which may lead to unhandled rejections and race conditions.
311-321: Block grouping logic appears correct.
The new code ensures that blocks are placed in the default group if no group exists. This approach is straightforward and seems logically correct.
454-458: Exported items and function organization.
All relevant block-compile methods (getBlockByName, getBlockCompileRes, etc.) are re-exported here. The structure looks neat and consistent with the existing pattern.
packages/canvas/DesignCanvas/src/importMap.js (1)
21-24: Import styles logic is consistent.
By including Element Plus CSS in the importStyles array, the approach for style injection remains consistent with how other components are handled.
packages/plugins/materials/src/composable/block-compile.js (3)
1-5: Initialization of the block compilation cache.
The new Map-based cache is a good way to store compiled results. Ensure concurrency conflicts or concurrent modifications are properly handled in multi-thread or asynchronous scenarios.
6-8:
fetchBlockSchema lacks error handling.
Since it calls “getMetaApi(META_SERVICE.Http).get(...)” directly, consider wrapping in try/catch to manage network errors or invalid “blockName” values.
-export const fetchBlockSchema = async (blockName) =>
- getMetaApi(META_SERVICE.Http).get(`/material-center/api/block?label=${blockName}`)
+export const fetchBlockSchema = async (blockName) => {
+ if (!blockName) {
+ throw new Error('Block name is required')
+ }
+ try {
+ const result = await getMetaApi(META_SERVICE.Http).get(`/material-center/api/block?label=${blockName}`)
+ return result
+ } catch (error) {
+ console.error('Failed to fetch block schema:', error)
+ throw error
+ }
+}Likely invalid or redundant comment.
9-16: 🛠️ Refactor suggestion
updateBlockCompileCache may need asynchronous handling.
Since it calls removeBlockCompsCacheByName, which might rely on asynchronous operations, consider making this function async and awaiting that call to confirm successful cleanups.
-export const updateBlockCompileCache = (name) => {
+export const updateBlockCompileCache = async (name) => {
if (blockCompileCache.has(name)) {
blockCompileCache.delete(name)
- useCanvas().canvasApi.value?.removeBlockCompsCacheByName(name)
+ await useCanvas().canvasApi.value?.removeBlockCompsCacheByName(name)
}
}Likely invalid or redundant comment.
packages/plugins/materials/src/meta/block/src/BlockVersionSelect.vue (1)
39-39: useMaterial, useCanvas usage.
Added imports for block management and canvas updates. This is consistent with the usage below for clearing caches and updating the canvas.
packages/canvas/DesignCanvas/src/DesignCanvas.vue (1)
184-185:
Breaking Change: Document migration from registerBlock to getBlockByName
The removal of registerBlock and addition of getBlockByName represents a breaking change in block management. This change needs:
- Documentation of the new approach
- Migration guide for existing applications
- Examples of using the new
getBlockByNamemethod
Let's verify the impact of removing registerBlock:
packages/block-compiler/src/index.ts (7)
224-228:
Prevent memory leaks from unrevoked Blob URLs
The current implementation creates Blob URLs but doesn't provide a mechanism to revoke them, which could lead to memory leaks.
+const createdBlobUrls = new Set<string>()
+
const getJSBlobURL = (str: string) => {
const blob = new Blob([str], { type: 'application/javascript' })
- return URL.createObjectURL(blob)
+ const url = URL.createObjectURL(blob)
+ createdBlobUrls.add(url)
+ return url
}
+
+export const cleanup = () => {
+ createdBlobUrls.forEach(URL.revokeObjectURL)
+ createdBlobUrls.clear()
+}Likely invalid or redundant comment.
275-305: 🛠️ Refactor suggestion
Improve cache implementation
The current caching mechanism lacks proper invalidation strategy and could lead to stale data.
+interface ICacheEntry {
+ js: string
+ style: string
+ blobURL: string
+ hash: string
+}
+
+const createHash = (content: string): string => {
+ return content // Replace with proper hashing implementation
+}
+
const compileCache = config?.compileCache || new Map()
for (const fileItem of parsedFileList) {
const fileName = fileItem.fileName
const cache = compileCache.get(fileName)
+ const contentHash = createHash(fileItem.sourceCode)
let js = ''
let style = ''
// 优先使用缓存
- if (cache?.js && cache?.style) {
+ if (cache?.js && cache?.style && cache.hash === contentHash) {
js = cache.js
style = cache.style
} else {
const compileRes = compileFile(fileItem)
js = compileRes.js
style = compileRes.style
+
+ compileCache.set(fileName, {
+ js: resolvedImportJs,
+ style,
+ blobURL: getJSBlobURL(resolvedImportJs),
+ hash: contentHash
+ })
}
const resolvedImportJs = resolveRelativeImport(js, config?.globalGetterName)
resultMap[fileName] = {
js: resolvedImportJs,
style,
blobURL: getJSBlobURL(resolvedImportJs)
}
- compileCache.set(fileName, resultMap[fileName])
compiledFilesSet.add(fileItem.fileNameWithRelativePath)
}Likely invalid or redundant comment.
243-308: 🛠️ Refactor suggestion
Add circular dependency detection
The compilation process should detect and prevent circular dependencies between files.
export const compile = (fileList: IFileList, config: IConfig) => {
+ const detectCircularDeps = (files: IParsedFileItem[]) => {
+ const graph = new Map<string, Set<string>>()
+ files.forEach(file => {
+ graph.set(file.fileNameWithRelativePath, new Set(file.importedFiles))
+ })
+
+ const visited = new Set<string>()
+ const recursionStack = new Set<string>()
+
+ const hasCycle = (node: string): boolean => {
+ if (recursionStack.has(node)) return true
+ if (visited.has(node)) return false
+
+ visited.add(node)
+ recursionStack.add(node)
+
+ const deps = graph.get(node) || new Set()
+ for (const dep of deps) {
+ if (hasCycle(dep)) return true
+ }
+
+ recursionStack.delete(node)
+ return false
+ }
+
+ for (const file of files) {
+ if (hasCycle(file.fileNameWithRelativePath)) {
+ throw new Error(`Circular dependency detected involving ${file.fileNameWithRelativePath}`)
+ }
+ }
+ }
+
+ detectCircularDeps(parsedFileList)Likely invalid or redundant comment.
125-152:
Implement error handling in script compilation
The function needs proper error handling for both script compilation and JSX transformation.
const compileBlockScript = (descriptor: SFCDescriptor, id: string): [string, BindingMetadata | undefined] => {
const isJsx = testIsJsx(descriptor)
const expressionPlugins: CompilerOptions['expressionPlugins'] = []
if (isJsx) {
expressionPlugins.push('jsx')
}
- // TODO: try catch
- const compiledScript = compileScript(descriptor, {
- genDefaultAs: DEFAULT_COMPONENT_NAME,
- inlineTemplate: true,
- id,
- templateOptions: {
- compilerOptions: {
- expressionPlugins
+ try {
+ const compiledScript = compileScript(descriptor, {
+ genDefaultAs: DEFAULT_COMPONENT_NAME,
+ inlineTemplate: true,
+ id,
+ templateOptions: {
+ compilerOptions: {
+ expressionPlugins
+ }
}
- }
- })
+ })
- let code = compiledScript.content
+ let code = compiledScript.content
- if (isJsx) {
- code = transformVueJsx(code) || ''
- }
+ if (isJsx) {
+ const transformed = transformVueJsx(code)
+ if (!transformed) {
+ throw new Error('JSX transformation failed')
+ }
+ code = transformed
+ }
- return [code, compiledScript.bindings]
+ return [code, compiledScript.bindings]
+ } catch (error) {
+ throw new Error(`Script compilation failed: ${error.message}`)
+ }
}Likely invalid or redundant comment.
5-18:
Add error handling for style compilation results
The compileStyle function can return errors, but they're not being handled. This could lead to silent failures.
const compileBlockStyle = (descriptor: SFCDescriptor, id: string) => {
const cssResArr = descriptor.styles.map((style) => {
const result = compileStyle({
id,
filename: descriptor.filename,
source: style.content,
scoped: style.scoped
})
+ if (result.errors?.length > 0) {
+ throw new Error(`Style compilation failed: ${result.errors.map(e => e.message).join(', ')}`)
+ }
+
return result.code || ''
})
return cssResArr.join('\n')
}Likely invalid or redundant comment.
20-49:
Improve template compilation safety and error handling
Several issues need to be addressed:
- Unsafe non-null assertion on template content
- Potential undefined result from JSX transformation
- Unhandled compilation errors
const compileBlockTemplate = (descriptor: SFCDescriptor, id: string, bindingMetadata: BindingMetadata | undefined) => {
const isJsx = testIsJsx(descriptor)
const expressionPlugins: CompilerOptions['expressionPlugins'] = []
if (isJsx) {
expressionPlugins.push('jsx')
}
+ if (!descriptor.template?.content) {
+ throw new Error(`No template content found in ${descriptor.filename}`)
+ }
+
const compileRes = compileTemplate({
id,
ast: descriptor.template?.ast,
- source: descriptor.template?.content!,
+ source: descriptor.template.content,
filename: descriptor.filename,
scoped: descriptor.styles.some((styleItem) => styleItem.scoped),
slotted: descriptor.slotted,
compilerOptions: {
bindingMetadata,
expressionPlugins
}
})
- const { errors } = compileRes
+ if (compileRes.errors?.length > 0) {
+ throw new Error(`Template compilation failed: ${compileRes.errors.map(e => e.message).join(', ')}`)
+ }
+
let { code } = compileRes
if (isJsx) {
- code = transformVueJsx(code) || ''
+ const transformed = transformVueJsx(code)
+ if (!transformed) {
+ throw new Error('JSX transformation failed')
+ }
+ code = transformed
}
return { code, errors }
}Likely invalid or redundant comment.
243-256:
Implement validation and error handling
The compile function needs to implement the TODO items for proper validation and error handling.
export const compile = (fileList: IFileList, config: IConfig) => {
+ const validateFile = (descriptor: SFCDescriptor, fileName: string) => {
+ if (!fileName.endsWith('.vue')) {
+ throw new Error(`Only .vue files are supported, received: ${fileName}`)
+ }
+
+ descriptor.styles.forEach((style, index) => {
+ if (style.lang && style.lang !== 'css') {
+ throw new Error(`Only CSS is supported in styles, found ${style.lang} in style block ${index}`)
+ }
+ })
+
+ if (descriptor.template?.lang) {
+ throw new Error(`Template lang attribute is not supported, found: ${descriptor.template.lang}`)
+ }
+ }
+
const parsedFileList = fileList.map((fileItem) => {
const { fileName, sourceCode } = fileItem
const { descriptor, errors } = parse(sourceCode, { filename: fileName })
if (errors) {
- // TODO: 抛出错误
+ throw new Error(`Parse errors in ${fileName}: ${errors.map(e => e.message).join(', ')}`)
}
- // TODO: 1. 当前仅支持 vue 文件编译，检查文件后缀，如果不是 .vue 结尾的，抛出错误
- // TODO: 2. 检查 style lang，仅支持 css
- // TODO: 3. 检查 template lang，当前不支持任何 template lang
+ validateFile(descriptor, fileName)Likely invalid or redundant comment.
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
packages/plugins/materials/src/composable/useMaterial.js (1)
Line range hint
144-161: Consider adding retry mechanism for block fetching.The
fetchBlockDetailfunction handles errors appropriately but could benefit from a retry mechanism for transient network issues.export const fetchBlockDetail = async (blockName) => { + const MAX_RETRIES = 3; + const RETRY_DELAY = 1000; + + const fetchWithRetry = async (attempt = 1) => { + try { + const block = (await getMetaApi(META_SERVICE.Http).get(`/material-center/api/block?label=${blockName}`))?.[0]; + if (!block) { + throw new Error(`区块${blockName}不存在！`); + } + return block; + } catch (error) { + if (attempt < MAX_RETRIES) { + await new Promise(resolve => setTimeout(resolve, RETRY_DELAY)); + return fetchWithRetry(attempt + 1); + } + throw error; + } + }; + const { getBlockAssetsByVersion } = useBlock() const currentVersion = componentState.componentsMap?.[blockName]?.version - const block = (await getMetaApi(META_SERVICE.Http).get(`/material-center/api/block?label=${blockName}`))?.[0] - - if (!block) { - throw new Error(`区块${blockName}不存在！`) - } + const block = await fetchWithRetry(); block.assets = getBlockAssetsByVersion(block, currentVersion) block.assets = history?.assets || block.assets return block }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
packages/canvas/DesignCanvas/src/DesignCanvas.vue(1 hunks)packages/canvas/container/src/container.js(1 hunks)packages/canvas/package.json(1 hunks)packages/canvas/render/src/RenderMain.js(4 hunks)packages/canvas/render/src/render.js(8 hunks)packages/plugins/materials/src/composable/useMaterial.js(6 hunks)packages/plugins/materials/src/composable/useResource.js(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (4)
- packages/canvas/package.json
- packages/plugins/materials/src/composable/useResource.js
- packages/canvas/container/src/container.js
- packages/canvas/render/src/RenderMain.js
🔇 Additional comments (6)
packages/canvas/DesignCanvas/src/DesignCanvas.vue (1)
189-189: LGTM: Block compiler integration looks good.
The addition of getBlockByName to the controller object properly exposes the block compilation functionality to the canvas.
packages/plugins/materials/src/composable/useMaterial.js (2)
26-26: LGTM: Proper modularization of block compiler functionality.
The import of block compilation utilities follows good separation of concerns.
308-321:
Add error handling for block compilation.
The block compilation preparation should handle potential errors during the compilation process.
if (!Array.isArray(blocks) || !blocks.length) {
return
}
- // 提前构建区块
- blocks.map((item) => getBlockCompileRes(item))
+ // 提前构建区块并处理错误
+ await Promise.all(
+ blocks.map(async (item) => {
+ try {
+ await getBlockCompileRes(item)
+ } catch (error) {
+ useNotify({
+ type: 'error',
+ title: '区块编译错误',
+ message: `区块 ${item.label} 编译失败: ${error.message}`
+ })
+ }
+ })
+ )Likely invalid or redundant comment.
packages/canvas/render/src/render.js (3)
13-14: LGTM: Proper Vue component imports.
The imports correctly set up async component loading and error handling capabilities.
Also applies to: 38-39
683-701: LGTM: Proper Suspense integration.
The integration of Suspense for block loading provides a good user experience with loading states.
307-315:
Enhance cache cleanup.
The cache cleanup should also handle blob URLs and stylesheets.
export const removeBlockCompsCacheByName = (name) => {
if (blockComponentsMap.has(name)) {
blockComponentsMap.delete(name)
}
if (blockComponentsBlobUrlMap.has(name)) {
+ // Revoke blob URL
+ const blobUrl = blockComponentsBlobUrlMap.get(name)
+ if (blobUrl) {
+ URL.revokeObjectURL(blobUrl)
+ }
blockComponentsBlobUrlMap.delete(name)
+
+ // Remove stylesheet
+ const stylesheet = document.querySelector(`#${name}`)
+ if (stylesheet) {
+ stylesheet.remove()
+ }
}
}Likely invalid or redundant comment.
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
New Features
BlockLoadErrorandBlockLoading.BlockFileName,BlockHead, andBlockMenufor enhanced UI functionality.Bug Fixes
Documentation
Chores