feat: support building customized canvas entry

[yy-wow]

English | 简体中文

PR

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our Commit Message Guidelines
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)
• Built its own designer, fully self-validated

PR Type

What kind of change does this PR introduce?

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

Background and solution

What is the current behavior?

Issue Number: N/A

What is the new behavior?

1. 工具栏-保存增加beforeSave、saveMethod、saved钩子；
2. 工具栏-预览增加beforePreview、previewMethod、afterPreview钩子；
3. 画布iframe支持配置src替换默认的srcdoc，支持自定义的画布页面构建入口；
4. 导出获取组件condition值的方法

Does this PR introduce a breaking change?

• Yes
• No

Other information

Summary by CodeRabbit

Summary by CodeRabbit

Release Notes

• New Features

  • Enhanced iframe rendering logic in the Canvas components to support conditional sources.
  • Introduced new props for better handling of canvas sources and visibility states in various components.
  • Added new methods for managing conditions and improved state management capabilities.

• Improvements

  • Asynchronous handling added to several functions, improving the flow of operations during save and preview actions.
  • Added pre-save and post-save hooks for greater flexibility in handling method execution.
  • Streamlined control flow for save operations, enhancing user experience during loading states.
  • Improved interactivity and maintainability of components through method restructuring.

• Bug Fixes

  • Resolved issues related to method execution and state management within the components.

• Configuration Changes

  • Updated project to use ECMAScript modules, enhancing module import and export syntax.
  • Added "type": "module" property in package.json for modern JavaScript standards.

[coderabbitai]

Actionable comments posted: 0

🧹 Outside diff range and nitpick comments (2)

packages/toolbars/save/src/js/index.js (2)

100-121: LGTM: Enhanced pre-save and save logic with proper error handling.

The new logic in openCommon function effectively handles pre-save and save operations with proper error handling. It also addresses the previous infinite recursion issue.

Consider using a more descriptive name for the printer variable, such as logger, to better reflect its purpose:

- const printer = console
+ const logger = console

This change would make the code slightly more self-documenting.

---

Security vulnerabilities detected in data handling.

The analysis revealed the following potential security issues:

• Potential XSS vulnerabilities:

  • packages/plugins/tree/src/Main.vue: Usage of innerHTML.
  • packages/canvas/render/src/RenderMain.js: Usage of innerHTML.
  • packages/canvas/container/src/container.js: Usage of innerHTML.

• Use of eval:

  • packages/vue-generator/src/templates/vue-template/templateFiles/src/lowcodeConfig/dataSource.js: window.eval('var fn = ' + fnContent).
  • packages/vue-generator/test/testcases/generator/expected/appdemo01/src/lowcodeConfig/dataSource.js: window.eval('var fn = ' + fnContent).

These issues may pose security risks and should be addressed promptly.

🔗 Analysis chain

Line range hint 1-174: Consider a security review for data handling.

While the changes themselves don't introduce obvious security issues, it's important to ensure that all data being saved or processed is properly sanitized and validated. Consider the following points:

1. Verify that any user input or external data is properly sanitized before being processed or saved.
2. Review the use of JSON.parse and JSON.stringify to ensure they're not vulnerable to potential JSON injection attacks.
3. Consider implementing input validation for the pageSchema and other data structures being saved or processed.

To help verify the security of data handling, you can run the following script:

This script will help identify potential security issues related to data handling in the codebase.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for potential security vulnerabilities in data handling

# Look for uses of JSON.parse without try-catch
echo "Searching for unprotected JSON.parse usage:"
rg --type js 'JSON\.parse\([^)]+\)(?!.*catch)'

# Look for potential XSS vulnerabilities
echo "Searching for potential XSS vulnerabilities:"
rg --type js 'innerHTML|outerHTML|document\.write'

# Look for eval or Function constructor usage
echo "Searching for eval or Function constructor usage:"
rg --type js 'eval\(|new Function\('

Length of output: 1482

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between fb006a5 and d775836.

📒 Files selected for processing (3)

• packages/toolbars/preview/src/Main.vue (3 hunks)
• packages/toolbars/save/src/Main.vue (1 hunks)
• packages/toolbars/save/src/js/index.js (3 hunks)

🚧 Files skipped from review as they are similar to previous changes (2)

• packages/toolbars/preview/src/Main.vue
• packages/toolbars/save/src/Main.vue

🧰 Additional context used

🔇 Additional comments (3)

packages/toolbars/save/src/js/index.js (3)

20-20: LGTM: New imports added for enhanced functionality.

The new imports for getOptions and meta are correctly added and will be used in the updated openCommon function.

Also applies to: 26-26

---

166-173: LGTM: Added post-save operation with proper error handling.

The new logic in the saveCommon function effectively handles post-save operations by calling the saved function if it's defined. The error handling is properly implemented, ensuring that any errors during the post-save operation are logged without breaking the execution flow.

---

Line range hint 1-174: LGTM: Overall structure and flow maintained with enhanced functionality.

The changes in this file successfully add new functionality for pre-save, save, and post-save operations while maintaining the overall structure and flow. The modifications align well with the PR objectives and the AI-generated summary, enhancing the save and open operations without introducing breaking changes.

[coderabbitai]

Actionable comments posted: 0

🧹 Outside diff range and nitpick comments (1)

packages/canvas/container/src/CanvasContainer.vue (1)

67-67: Good addition of canvasSrcDoc prop and srcAttrName computed property.

The new prop and computed property effectively support the dynamic attribute implementation in the template. This enhances the component's flexibility in handling different iframe source types.

Consider simplifying the srcAttrName computed property for better readability:

const srcAttrName = computed(() => props.canvasSrc ? 'src' : 'srcdoc')

Also applies to: 78-78

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 3cad14b and aa3fd37.

📒 Files selected for processing (1)

• packages/canvas/container/src/CanvasContainer.vue (4 hunks)

🧰 Additional context used

🔇 Additional comments (2)

packages/canvas/container/src/CanvasContainer.vue (2)

14-21: Excellent implementation of conditional rendering and dynamic attribute!

The changes effectively address the loading state and implement the dynamic attribute suggestion from the previous review. This approach provides flexibility in handling different source types (src or srcdoc) for the iframe.

---

247-248: Correct addition of new properties to the setup function's return object.

The inclusion of loading and srcAttrName in the returned object ensures that these computed properties are accessible in the template, which is consistent with the earlier modifications.

[coderabbitai]

Actionable comments posted: 1

🧹 Outside diff range and nitpick comments (1)

packages/canvas/render/src/context.js (1)

57-57: Consider the implications of exposing the entire conditions object.

While getConditions provides convenient access to all conditions, it might expose internal state that should be managed more carefully.

Consider these alternatives:

1. Return a copy of the conditions object to prevent external modifications:

   export const getConditions = () => ({ ...conditions })

2. Implement methods for bulk operations instead of exposing the entire object.
3. If direct access is necessary, document the risks and usage guidelines.

These approaches can help maintain better control over the conditions state and prevent unintended modifications.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between aa3fd37 and 0dbb401.

📒 Files selected for processing (2)

• packages/canvas/render/src/RenderMain.js (2 hunks)
• packages/canvas/render/src/context.js (1 hunks)

🧰 Additional context used

🔇 Additional comments (5)

packages/canvas/render/src/context.js (1)

54-57: Summary of changes and recommendations

The additions of getCondition and getConditions enhance the module's functionality by providing more granular access to condition states. However, there are opportunities for improvement:

1. Align getCondition with setCondition for consistency.
2. Reconsider the direct exposure of the conditions object through getConditions.

These changes will improve the overall design and maintainability of the module.

packages/canvas/render/src/RenderMain.js (4)

27-28: LGTM: New imports added correctly.

The new imports getCondition and getConditions from the context module are correctly added. These imports correspond to the new functions added to the api export object.

---

446-447: LGTM: New functions added to api export.

The getCondition and getConditions functions are correctly added to the api export object, consistent with the new imports.

---

27-28: Summary of changes: Enhanced condition management.

The changes in this file introduce new functions getCondition and getConditions for improved condition management. These additions enhance the API's capabilities without disrupting the existing structure. The changes appear to be well-integrated and consistent with the module's purpose.

However, please note that there's an unresolved question about potential changes to the setCondition function, which were mentioned in the AI summary but not visible in this diff. It's important to clarify this discrepancy to ensure all changes are properly reviewed and understood.

To get a comprehensive view of all condition-related functions, you can run:

#!/bin/bash
# Description: List all condition-related functions in the codebase

echo "Condition-related functions in the codebase:"
rg --type js "function (get|set|)Condition" packages/canvas/render/src/

Also applies to: 446-447

---

445-447: Clarification needed: setCondition function update.

The AI summary mentions an update to the setCondition function's signature, but no changes are visible in this diff. Could you please clarify if there are any changes to the setCondition function that are not shown in this diff?

To verify the setCondition function changes, you can run the following script:

[coderabbitai]

⚠️ Potential issue

Consider modifying getCondition to align with setCondition.

The current implementation of getCondition differs from the suggestion in the past review comment. While it correctly retrieves the condition state, it might not be consistent with setCondition.

Consider modifying the function to explicitly return the condition value or a default:

-export const getCondition = (id) => conditions[id] !== false
+export const getCondition = (id) => conditions[id] ?? false

This change would make getCondition more consistent with setCondition and provide a clear default value when the condition is not set.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	export const getCondition = (id) => conditions[id] !== false
	export const getCondition = (id) => conditions[id] ?? false

[rhlin]

需要单独导出createRender 避免css污染

[hexqi]

eslint报错、gpg签名问题需要处理

[hexqi]

PR标题需要修改，不应该有unibuy字眼。==> feat: ...(feature description)

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 0dbb401 and 9a15278.

📒 Files selected for processing (1)

• .eslintrc.js (1 hunks)

🧰 Additional context used

🔇 Additional comments (1)

.eslintrc.js (1)

Line range hint 2-30: LGTM: ESLint configuration is well-structured

The ESLint configuration is well-structured and follows best practices for a Vue.js project. It includes appropriate environment settings, parser options, plugins, and rules.

[coderabbitai]

💡 Codebase verification

⚠️ Potential issue

Revert to CommonJS module.exports syntax for ESLint configuration

The change from export default { ... } to module.exports = { ... } is necessary to maintain compatibility with ESLint. Since the project does not use ES modules ("type": "module" is not set in package.json), using ES6 module syntax can cause ESLint to fail in parsing the configuration file.

Please revert this change to ensure ESLint functions correctly:

-export default {
+module.exports = {

🔗 Analysis chain

Revert to CommonJS module.exports syntax for ESLint configuration

The change from module.exports = { ... } to export default { ... } may cause issues with ESLint parsing the configuration file. ESLint typically expects CommonJS format for its configuration files.

Please revert this change to ensure compatibility with ESLint:

-export default {
+module.exports = {

To confirm if this change affects other parts of the project, run the following script:

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for any imports of the ESLint config and verify the project's module system

# Test 1: Search for imports of .eslintrc.js
echo "Searching for imports of .eslintrc.js:"
rg --type js --type ts "require.*eslintrc" || echo "No CommonJS imports found"
rg --type js --type ts "import.*eslintrc" || echo "No ES6 imports found"

# Test 2: Check if the project uses ES modules
echo "Checking for 'type': 'module' in package.json:"
jq '.type' package.json || echo "No 'type' field found in package.json"

# Test 3: Check for babel configuration
echo "Checking for Babel configuration:"
fd -e js -e json -e yaml -e yml --exec grep -l "babel" {} \; || echo "No Babel configuration found"

Length of output: 1644

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 9a15278 and e821a25.

📒 Files selected for processing (2)

• lint-staged.config.js (1 hunks)
• package.json (1 hunks)

✅ Files skipped from review due to trivial changes (1)

• lint-staged.config.js

🧰 Additional context used

[coderabbitai]

💡 Codebase verification

Issues Identified with ES Modules Adoption

The migration to ECMAScript modules introduces several compatibility concerns:

1. CommonJS Usage in Codebase:

   • Files with require() calls:
     • scripts/copyToVscode.js
     • scripts/buildComponentSchemas.js
     • scripts/setup.js
     • mockServer/gulpfile.js
     • mockServer/build/dev-server.js
     • mockServer/src/services/app.js
     • mockServer/src/services/schema2code.js
     • packages/vue-generator/src/utils/vue-sfc-validator.js
     • packages/vue-generator/src/generator/page.js
     • packages/vue-generator/test/utils/logger/index.js
     • packages/vue-generator/test/testcases/full/index.js
     • packages/engine-cli/bin/cli.js
     • packages/settings/design/src/convertToSchema.js

2. CommonJS module.exports Usage:

   • mockServer/pm2.js
   • mockServer/src/config/config.js
   • mockServer/src/routes/error-routes.js
   • mockServer/src/middleware/ErrorRoutesCatch.js
   • Various .umd.js files in mockServer/src/assets/js/
   • ESLint configuration in mockServer/.eslintrc.js
   • Logger utilities in packages/vue-generator/test/utils/logger/index.js
   • Test configurations in packages/vue-generator/test/testcases/full/index.config.js
   • ESLint configuration in packages/canvas/.eslintrc.js

3. Local Dependencies Missing ES Module Support:

   • @opentiny/tiny-engine-cli
   • plugin
   • @opentiny/tiny-engine-mock

Recommended Actions:

• Refactor CommonJS to ES Modules:

  • Replace require() with import statements.
  • Replace module.exports with export syntax.

• Update Local Dependencies:

  • Ensure all local packages specify "type": "module" in their package.json.
  • Refactor local dependencies to use ES module syntax where necessary.

• Verify Dependencies Compatibility:

  • Confirm that all third-party dependencies are compatible with ES modules or provide ES module builds.

• Adjust Build Processes:

  • Update build tools and configurations to support ES modules.

• Comprehensive Testing:

  • Perform thorough testing to identify and fix any runtime issues stemming from the migration.

🔗 Analysis chain

Significant change: Project now uses ECMAScript modules

The addition of "type": "module" to package.json is a substantial change that affects how modules are imported and exported throughout the project. This aligns the project with modern JavaScript standards but may have far-reaching effects on the codebase.

Consider the following implications and actions:

1. Compatibility: Ensure all existing code is compatible with ES modules. This may involve updating import and export statements, and removing require() calls.
2. Dependencies: Verify that all dependencies support ES modules. Some packages may need to be updated or replaced.
3. Build process: Check if the build process needs adjustments to handle ES modules correctly.
4. Documentation: Update any documentation that explains how to work with the project, especially regarding module imports and exports.

To verify the impact of this change, run the following script:

This script will help identify potential issues that need to be addressed following this change. Please review the results carefully and make necessary adjustments to ensure smooth transition to ES modules.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for potential issues with ES modules adoption

# Test 1: Search for CommonJS require() calls that need to be replaced
echo "Searching for require() calls:"
rg --type js 'require\(' -g '!node_modules'

# Test 2: Check for .js files using module.exports (which is not supported in ES modules)
echo "Searching for module.exports usage:"
rg --type js 'module\.exports' -g '!node_modules'

# Test 3: Look for package.json files of local dependencies to check their "type" field
echo "Checking local dependencies for ES module support:"
fd package.json -x jq -r 'select(.type != "module") | "Package \(.name) does not specify type: module"'

# Note: This script provides a starting point. Manual review of the results is necessary.

Length of output: 5364