Skip to content
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 21 additions & 1 deletion src/lib/sveltekit-search-params.ts
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@
/* eslint-disable @typescript-eslint/no-explicit-any */
import { browser, building } from '$app/environment';
import { goto } from '$app/navigation';
import { page as page_store } from '$app/stores';
import { navigating, page as page_store } from '$app/stores';
import type { Page } from '@sveltejs/kit';
import {
derived,
Expand Down Expand Up @@ -326,8 +326,28 @@ export function queryParam<T = string>(
const override = writable<T | null>(null);
let firstTime = true;
let currentValue: T | null;

let isNavigating = false;
if (browser) {
navigating.subscribe((nav) => {
isNavigating = nav?.type === 'goto';
});
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tip

Codebase Verification

The investigation into the usage of navigating.subscribe within src/lib/sveltekit-search-params.ts reveals that there is indeed an explicit unsubscription mechanism in place within the _set function, which addresses the concern about potential memory leaks by ensuring proper cleanup. This demonstrates a level of care in managing subscriptions to the navigating store. However, the initial concern regarding the potential performance impact of multiple subscriptions, especially in applications with frequent navigation updates, remains valid. It's recommended to continue monitoring and optimizing subscription management to the navigating store to mitigate any potential performance issues.

Analysis chain

The implementation of subscribing to the navigating store to set isNavigating based on the navigation type is a clever way to handle the issue of rapid successive navigation commands. However, there are a couple of points to consider:

  • Performance: Subscribing to the navigating store every time the queryParam function is called could potentially lead to performance issues, especially in applications with frequent navigation updates. It might be more efficient to manage the subscription at a higher level or use a shared state to track navigation status.
  • Unsubscription: It's good practice to unsubscribe from Svelte stores when the subscription is no longer needed to prevent memory leaks. In this case, the subscription created on line 332 does not seem to be explicitly unsubscribed from. While Svelte might handle this automatically in some scenarios, explicitly managing subscriptions is generally safer.

Consider optimizing the subscription management to the navigating store to improve performance and ensure proper cleanup.


Scripts Executed

The following scripts were executed for the analysis:


Script:

#!/bin/bash
# Verify if there's a shared navigation status management implemented elsewhere in the codebase
rg "navigating.subscribe" --type ts

Length of output: 194



Script:

#!/bin/bash
# Extract more details about the second occurrence of navigating.subscribe and its surrounding code
rg -C 5 "const unsubscribe = navigating.subscribe" --type ts

Length of output: 785


function _set(value: T | null, changeImmediately?: boolean) {
if (!browser) return;

// Wait for previous navigation to be finished before updating again
if (isNavigating) {
const unsubscribe = navigating.subscribe((nav) => {
if (nav?.type !== 'goto') {
_set(value, changeImmediately);
unsubscribe();
}
});
return;
}

firstTime = false;
const hash = window.location.hash;
const toBatch = (query: URLSearchParams) => {
Expand Down