It looks better.
Another example that still doesn't work:

const data = resource({
  params: () => Math.random() ? undefined : 'test',
  loader: ({ params }) => {
    console.log('> params', params); // string, should be string|undefined 
    return Promise.resolve('');
  },
});

It looks better. Another example that still doesn't work:

const data = resource({
  params: () => Math.random() ? undefined : 'test',
  loader: ({ params }) => {
    console.log('> params', params); // string, should be string|undefined 
    return Promise.resolve('');
  },
});

It looks better. Another example that still doesn't work:

const data = resource({
  params: () => Math.random() ? undefined : 'test',
  loader: ({ params }) => {
    console.log('> params', params); // string, should be string|undefined 
    return Promise.resolve('');
  },
});

let me check and test it please provide all the test cases and details thank you

Also please check the CLA check. You're authoring your commits with 2 different names.

const data = resource({
  params: () => Math.random() ? undefined : 'test',
  loader: ({ params }) => {
    console.log('> params', params); // string, should be string|undefined 
    return Promise.resolve('');
  },
});

@JeanMeche

loader should stay typed as string here, not string | undefined. When a params function is provided, Angular treats undefined as “no request” and leaves the resource idle, so the loader is not invoked for that branch. In other words, params() may return string | undefined, but loader only runs for the resolved, non-undefined case. The nullable case we’re fixing is different: it applies when the params option itself is omitted or explicitly undefined, because Angular uses an internal null sentinel there.`

Shorter version:

I don’t think this one should widen to \string | undefined. If params()returnsundefined, the resource goes idle and loaderis skipped, so insideloader the type should remain the non-undefined branch (string). The bug we’re fixing is the separate case where the paramsoption is omitted or explicitlyundefined, which currently flows a runtime null sentinel.

please comment or suggestion why do u think that it should be string |undefined?

@JeanMeche apart the this edge cases everything look fine can you please take a look

Yeah you're right, my bad for that bad example.

Something else.
The generics are somehow not ideal.

In your test you have:

    const res = resource<string, string>({
      loader: async ({params}) => {
        seenParams = params;
        return 'foo';
      },
      injector: TestBed.inject(Injector),
    });

which should arguably have a single generic (since the request is not defined).

    const res = resource<string>({
      loader: async ({params}) => {
        seenParams = params;
        return 'foo';
      },
      injector: TestBed.inject(Injector),
    });

I would also expect test that show that the typings are correct here.

I have squashed & pushed something that is simpler and more correct. PTAL and let me know what you think :)

I have squashed & pushed something that is simpler and more correct. PTAL and let me know what you think :)

yes, it looks good, tested and working fine and sorry next time i will do better and thanks you for your patience and review :)