fix: 修复AccessControl默认codes逻辑错误 #5210
Conversation
little-alei
requested review from
anncwb,
vince292007 and
mynetfan
as code owners
|
|
Warning There were issues while running some tools. Please review the errors and either fix the tool’s configuration or disable the tool if it’s a critical failure. 🔧 eslint
packages/effects/access/src/access-control.vueOops! Something went wrong! :( ESLint: 9.17.0 Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/node_modules/@vben/eslint-config/dist/index.mjs' imported from /eslint.config.mjs WalkthroughThe pull request introduces a modification to the Changes
Suggested labels
Suggested reviewers
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
packages/effects/access/src/access-control.vue (2)
31-31: LGTM! Consider documenting the behavior change.The change from empty array to
undefinedas the default value forcodesimproves the semantic meaning -undefinedbetter represents "no access restrictions" compared to an empty array.Consider adding a comment to document that:
- When
codesis undefined, it means no access restrictions- When
codesis an empty array, it means no access is granted
Line range hint
1-8: Consider implementing the TODO enhancements with TypeScript enums and interfaces.The TODOs outline valuable enhancements. Here's a suggested approach:
// Define validation modes enum ValidationMode { ANY = 'any', // Any code/role matches ALL = 'all' // All codes/roles must match } // Enhanced Props interface interface EnhancedProps { codes?: string[]; roles?: string[]; mode?: ValidationMode; validator?: (codes: string[], roles: string[]) => boolean; }This would provide:
- Flexible validation logic through the
modeprop- Custom validation through the
validatorprop- Clear type safety with TypeScript
Would you like me to create an issue to track this enhancement?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
packages/effects/access/src/access-control.vue(1 hunks)
🔇 Additional comments (1)
packages/effects/access/src/access-control.vue (1)
38-39: LGTM! Robust default handling.
The default empty array in the destructuring ensures that access check functions always receive an array, following the fail-safe principle - no access by default when codes are undefined.
| @@ -29,14 +28,14 @@ defineOptions({ | |||
| }); | |||
|
|
|||
| const props = withDefaults(defineProps<Props>(), { | |||
| codes: () => [], | |||
| codes: undefined, | |||
Description
Type of change
Please delete options that are not relevant.
pnpm-lock.yamlunless you introduce a new test example.Checklist
pnpm run docs:devcommand.pnpm test.feat:,fix:,perf:,docs:, orchore:.Summary by CodeRabbit
Bug Fixes
codesproperty, ensuring proper initialization and access within the component.New Features