feat: update version notice #4518
Conversation
|
WalkthroughThe changes introduce a new watcher in the layout component to ensure the sidebar is visible when the layout is set to Changes
Possibly related PRs
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: 5
🧹 Outside diff range and nitpick comments (6)
packages/effects/layouts/src/basic/layout.vue (1)
146-157: LGTM! Consider adding a user preference option.The new watcher effectively ensures that the sidebar is visible when the 'sidebar-mixed-nav' layout is selected, which aligns with the PR objectives and improves user experience.
Consider adding a user preference option to allow users to override this behavior if they wish to keep the sidebar hidden even in the 'sidebar-mixed-nav' layout. This could be implemented as follows:
watch( () => preferences.app.layout, async (val) => { if (val === 'sidebar-mixed-nav' && preferences.sidebar.hidden) { + if (!preferences.sidebar.allowHiddenInMixedNav) { updatePreferences({ sidebar: { hidden: false, }, }); + } } }, );This change would require adding a new preference option
allowHiddenInMixedNavto the sidebar preferences.packages/effects/layouts/src/widgets/check-updates/utils.ts (2)
47-47: Use Appropriate Logging Method Instead ofconsole.errorCurrently,
console.erroris used to log theversionTag:console.error(versionTag, 'versionTag');Using
console.errorfor non-error information can clutter the console and make it harder to spot actual errors.Use
console.logorconsole.infofor informational messages:- console.error(versionTag, 'versionTag'); + console.info(versionTag, 'versionTag');
20-20: Consider Adjusting the Default Update IntervalThe default
checkUpdatesIntervalis set to1minute:checkUpdatesInterval: 1, // minFrequent update checks may increase server load and network traffic.
Consider setting a higher default interval, such as
5or10minutes, to reduce unnecessary requests.packages/effects/layouts/src/widgets/check-updates/check-updates.vue (3)
19-19: Avoid direct use oflocationfor better SSR compatibilityAccessing
location.origindirectly can cause issues in server-side rendering (SSR) environments wherewindowandlocationmay not be defined. Consider usingimport.meta.env.BASE_URLor a similar approach to obtain the root path safely.Apply this diff to use
import.meta.env.BASE_URL:- const rootPath = `${location.origin}/`; + const rootPath = import.meta.env.BASE_URL;
35-35: Specify the correct event type for better type safetyThe event parameter
eis currently typed asany. To improve type safety and leverage TypeScript's type checking, specify the event type asMessageEvent.Apply this diff:
- worker.addEventListener('message', (e: any) => { + worker.addEventListener('message', (e: MessageEvent) => {Ensure to import
MessageEventif it's not available in the current scope.
47-47: Remove unused commented-out parameterThe parameter
/* versionTag: string*/in thehandleNoticefunction is commented out and not used within the function body. Consider removing it to clean up the code.Apply this diff:
- function handleNotice(/* versionTag: string*/) { + function handleNotice() {
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (3)
- packages/effects/layouts/src/basic/layout.vue (1 hunks)
- packages/effects/layouts/src/widgets/check-updates/check-updates.vue (3 hunks)
- packages/effects/layouts/src/widgets/check-updates/utils.ts (1 hunks)
🔇 Additional comments (2)
packages/effects/layouts/src/widgets/check-updates/check-updates.vue (2)
37-37: Clarify conditional check for non-production environmentsThe condition
import.meta.env.MODE === 'production'preventshandleNoticefrom being called in non-production environments. If the intention is to test update notifications during development, consider adjusting this check or adding a comment to explain.Is it intended to suppress update notifications in non-production modes? Verify if this aligns with the desired behavior.
85-85: Ensure immediate start behavior is consistentWhen the document becomes visible,
start(true)is called withimmediate = true. Verify that this aligns with the desired behavior of checking for updates immediately upon visibility change.Confirm that starting the worker with
immediate = trueafter regaining visibility is intended and does not cause unintended side effects.
| const data = event.data.data; | ||
| if (data.checkUpdatesInterval) | ||
| opts.checkUpdatesInterval = data.checkUpdatesInterval; | ||
| if (data.fetchUrl) opts.fetchUrl = data.fetchUrl; | ||
| if (data.immediate) { |
There was a problem hiding this comment.
Validate Incoming Data in Message Handler
The code updates opts based on event.data.data without validation:
const data = event.data.data;
if (data.checkUpdatesInterval)
opts.checkUpdatesInterval = data.checkUpdatesInterval;
if (data.fetchUrl) opts.fetchUrl = data.fetchUrl;
if (data.immediate) {
await doFetch();
}To prevent potential errors or security issues, validate the incoming data:
if (typeof data.checkUpdatesInterval === 'number' && data.checkUpdatesInterval > 0)
opts.checkUpdatesInterval = data.checkUpdatesInterval;
if (typeof data.fetchUrl === 'string') opts.fetchUrl = data.fetchUrl;
if (typeof data.immediate === 'boolean' && data.immediate) {
await doFetch();
}| const stop = () => { | ||
| clearInterval(timer); | ||
| }; | ||
| const temp: Worker = globalThis as any; |
There was a problem hiding this comment.
Type Mismatch: globalThis Should Be WorkerGlobalScope
At line 28, temp is declared as Worker, but globalThis in a worker context refers to WorkerGlobalScope, not Worker. This mismatch can lead to type inconsistencies and confusion when using worker-specific properties and methods.
Update the type of temp to WorkerGlobalScope to accurately represent the worker's global context:
- const temp: Worker = globalThis as any;
+ const temp: WorkerGlobalScope = globalThis as any;Or, for more specific typing, use DedicatedWorkerGlobalScope:
- const temp: Worker = globalThis as any;
+ const temp: DedicatedWorkerGlobalScope = globalThis as any;📝 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.
| const temp: Worker = globalThis as any; | |
| const temp: WorkerGlobalScope = globalThis as any; | |
| ``` | |
| Alternatively, using the more specific type: | |
| ```suggestion | |
| const temp: DedicatedWorkerGlobalScope = globalThis as any; |
| const stop = () => { | ||
| worker.postMessage({ type: 'stop' }); | ||
| }; |
There was a problem hiding this comment.
Terminate the worker upon unmounting to prevent resource leaks
While the stop function sends a 'stop' message to the worker, it does not terminate it. When the component unmounts, the worker remains active, potentially leading to memory leaks. Consider terminating the worker in the onUnmounted hook.
Apply this diff to terminate the worker when the component unmounts:
onUnmounted(() => {
stop();
+ worker.terminate();
document.removeEventListener('visibilitychange', handleVisibilitychange);
});Also applies to: 108-112
| watch( | ||
| () => props.checkUpdatesInterval, | ||
| () => { | ||
| opts.checkUpdatesInterval = props.checkUpdatesInterval; | ||
| }, | ||
| ); |
There was a problem hiding this comment.
Changes to checkUpdatesInterval may not affect the worker
The watch function updates opts.checkUpdatesInterval when props.checkUpdatesInterval changes. However, since the worker continues running with the initial options, the updated interval won't take effect unless the worker is notified. Consider sending an update message to the worker or restarting the worker to apply the new interval.
Apply this diff to send updated options to the worker when the interval changes:
watch(
() => props.checkUpdatesInterval,
() => {
opts.checkUpdatesInterval = props.checkUpdatesInterval;
+ worker.postMessage({ data: { ...opts }, type: 'updateOptions' });
},
);Also, ensure the worker handles the 'updateOptions' message type to update its configuration accordingly.
Committable suggestion was skipped due to low confidence.
Description
feat: check-updates.vue 检测更新提示窗 通过 worker 进行 请求 通过 message 触发 更新弹窗
Type of change
Please delete options that are not relevant.
Checklist