linkedSignal bug

[Ookamini95]

Which @ngneat/query-* package(s) are the source of the bug?

query

Is this a regression?

No

Description

When using linkedSignals I've encountered a strange behaviour that I did not encounter with signals and computed.

I'm using signal + effect combo from angular 18 as a patchwork solution.

Please provide a link to a minimal reproduction of the bug

https://stackblitz.com/edit/stackblitz-starters-wlqeum2o?file=src%2Fhelper.service.ts,src%2Fmain.ts,angular.json

Please provide the exception or error you saw

ERROR TypeError: can't access private field or method: object is not the right class
    AuthService auth.service.ts:32
    Angular 3
    wow auth.service.ts:50
    AuthService auth.service.ts:52
    _AuthService auth.service.ts:25
    AuthService_Factory chunk-MDOUMDX5.js:174

Please provide the environment you discovered this bug in

node 22.12.0 (Currently using 64-bit executable)

package.json
{
  "name": "dashboard",
  "version": "0.0.0",
  "scripts": {
    "ng": "ng",
    "start": "ng serve",
    "build": "ng build",
    "watch": "ng build --watch --configuration development",
    "test": "ng test"
  },
  "private": true,
  "dependencies": {
    "@angular/animations": "^19.0.0",
    "@angular/common": "^19.0.0",
    "@angular/compiler": "^19.0.0",
    "@angular/core": "^19.0.0",
    "@angular/forms": "^19.0.0",
    "@angular/platform-browser": "^19.0.0",
    "@angular/platform-browser-dynamic": "^19.0.0",
    "@angular/router": "^19.0.0",
    "@ngneat/query": "^3.1.0",
    "@tanstack/query-core": "^5.62.15",
    "primeicons": "^7.0.0",
    "rxjs": "~7.8.0",
    "tslib": "^2.3.0",
    "valibot": "^1.0.0-beta.9",
    "zone.js": "~0.15.0"
  },
  "devDependencies": {
    "@angular-devkit/build-angular": "^19.0.1",
    "@angular/cli": "^19.0.1",
    "@angular/compiler-cli": "^19.0.0",
    "@tailwindcss/aspect-ratio": "latest",
    "@tailwindcss/forms": "latest",
    "@tailwindcss/typography": "latest",
    "@types/jasmine": "~5.1.0",
    "autoprefixer": "^10.4.7",
    "daisyui": "^4.12.14",
    "jasmine-core": "~5.4.0",
    "karma": "~6.4.0",
    "karma-chrome-launcher": "~3.2.0",
    "karma-coverage": "~2.2.0",
    "karma-jasmine": "~5.1.0",
    "karma-jasmine-html-reporter": "~2.1.0",
    "ngx-tailwind": "^4.0.0",
    "postcss": "^8.4.14",
    "prettier": "3.4.2",
    "prettier-plugin-tailwindcss": "^0.6.9",
    "tailwindcss": "^3.1.6",
    "typescript": "~5.6.2"
  }
}

Anything else?

No response

Do you want to create a pull request?

No

[stackblitz[bot]]

Start a new pull request in StackBlitz Codeflow.

• stackblitz-starters-wlqeum2o (Open reproduction)

[luii]

What i think you're expiriencing here is that your (this) context in your object (test) is wrong.

Arrow functions do not have their own this . They inherit this from their surrounding scope. Arrow functions do not bind this to any specific object. If you try to reference this inside an arrow function, it just inherits from the parent scope.

Which in this case, is the objects scope.

AuthService{test: {…}}
  test: Object
    wow: ƒ wow()
      name: "wow"
      <prototype>: Function
    <prototype>: Object
  <prototype>: AuthService

So to put it simply, accessing #accessToken inside the test object is not possible, hence the error message you're given by the browser. Either try binding the context of your object or try to use another way of exposing/facading (atleast that is what i think you want to do) your properties.

[Ookamini95]

Thank you for your response, but I've managed to understand more over the span of the afternoon and managed to fix it finally.
While your thesis is really interesting, and eventually lead me to the solution, it is not completely right. I won't lie, I don't understand completely the bug, but I've managed a better working minimal reproduction of the bug (I got really angry not gonna lie)

@Injectable({ providedIn: 'root' })
export class SomeService {
  // ERROR
  test = {
    wow: () => console.log(this.#data()),
  };
  res = this.test.wow();

  #data = signal({
    data: [0, 1, 2],
  });


  // NO ERROR
  // test = {
  //  wow: () => console.log(this.data()),
  // };
  // res = this.test.wow();
}

which is due to the fact that the functions are actually executed in a context where those fields do not exist. This means that when using this library + computed values (linked, computed...) the order in which things are defined matters a lot.
I've managed a working example of what I had in mind (semi-complex example handling auth):

Moving computed signals around ngquery stuff and changing the order will trigger the error!

@Injectable({ providedIn: 'root' })
export class AuthService {
  #query = injectQuery();
  #client = injectQueryClient();
  #http = inject(HttpClient);
  #router = inject(Router);

  #credentials = signal<AuthPayload | undefined>(undefined);
  #authorization = this.#query({
    queryKey: ['auth'] as const,
    queryFn: () =>
      this.#http.post<AuthResponse>(ApiRoutes.auth.login().path, {
        ...this.#credentials()
      }),
      enabled: () =>
        Boolean(this.#credentials()) &&
      Object.keys(this.#credentials()!).length > 0
    }).result;
    
    #refreshToken = linkedSignal<string | undefined>(
      () => this.#authorization().data?.refresh_token
    );
    #refresh = this.#query({
      queryKey: ['refresh'] as const,
      queryFn: () =>
        this.#http.post<RefreshResponse>(ApiRoutes.auth.refresh().path, {
          refresh_token: this.#refreshToken()
        }),
      enabled: () => Boolean(this.#refreshToken()),
    }).result;

  #loggedEffect = effect(() => {
    const logged = this.logged();
    if (logged) this.#router.navigate(['dashboard']);
  });
  #setLocalStorageTokenEffect = effect(() => {
    const refresh = this.#refreshToken();
    if (refresh) localStorage.setItem(STORE_AUTH_KEY_REFRESH, refresh);
  });

  readonly logged = computed(() => Boolean(this.#accessToken()));
  readonly token = computed(() => this.#accessToken());
  readonly loading = computed(
    () => this.#authorization().isLoading || this.#refresh().isLoading
  );
  #accessToken = linkedSignal<string | undefined>(
    () =>
      this.#refresh().data?.access_token ||
      this.#authorization().data?.access_token
  );

  authorize(auth: AuthPayload) {
    this.#credentials.set(auth);
    this.#client.resetQueries({
      queryKey: ['auth'] as const
    });
  }
  retrieveLocal() {
    const refresh = localStorage.getItem(STORE_AUTH_KEY_REFRESH);
    console.log('tryng to refresh local ', refresh);
    // TODO should check if expired by decoding it, and then if valid set it
    if (refresh) {
      this.#refreshToken.set(refresh);
      this.#client.invalidateQueries({
        queryKey: ['refresh'] as const
      });
    }
    return Boolean(refresh);
  }
  logoff() {
    this.#resetTokenData();
    this.#client.invalidateQueries({
      queryKey: ['auth'] as const
    });
    this.#client.invalidateQueries({
      queryKey: ['refresh'] as const
    });
  }
  #resetTokenData() {
    this.#credentials.set(undefined);
    this.#accessToken.set(undefined);
    this.#refreshToken.set(undefined);
    localStorage.setItem(STORE_AUTH_KEY_REFRESH, '');
  }
}

Edit: I've realised that this is actually angular related and maybe I should post an issue there. But I do think that this makes the library effectively order dependent. As this is presumably an unwanted side-effect maybe it is worth noting in the readme until resolved.

Angular minimal reproduction

@Injectable({ providedIn: 'root' })
export class AuthService {
  // ERROR
  test = {
     wow: () => console.log(this.#data1()),
  };

  res = this.test.wow(); // calling functions like this (very common with this library if i'm not mistaken) triggers error unless correct order
  ////
  #data = signal({
    data: [0, 1, 2],
  });
  
  // NO ERROR
  // test = {
  //   wow: () => console.log(this.#data()),
  // };
  // res = this.test.wow();
}