Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

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),
    });