The signalStore function could return two functions, one for provide and one for inject.

[MRinaldi9]

Which @ngrx/* package(s) are relevant/related to the feature request?

signals

Information

It would be convenient if the signalStore function, instead of returning the class to use for providing and injecting, returned two functions that act as injection function and provider function using the new standalone syntax. For an example of what I mean, you can check the createInjectionToken function in the ngextension library.
https://ngxtension.netlify.app/utilities/injectors/create-injection-token/

Describe any alternatives/workarounds you're currently using

No response

I would be willing to submit a PR to fix this issue

• Yes
• No

[markostanimirovic]

For an example of what I mean, you can check the createInjectionToken function in the ngextension library.
https://ngxtension.netlify.app/utilities/injectors/create-injection-token/

The idea with [provide, inject] tuple is from initial SignalStore proposal.

The injection token's limitation is that it cannot be provided via the providers array without useFactory. That's the reason why the provide.. function is necessary for tokens. On the other hand, this is not needed for services (classes).

By the way, I opened an issue for this some time ago: angular/angular#49807

It would be convenient if the signalStore function, instead of returning the class to use for providing and injecting, returned two functions that act as injection function and provider function using the new standalone syntax.

Can you provide more details on why the [provide, inject] tuple instead of a single service seems more convenient to you?

As I mentioned, we started with this approach but changed it for two main reasons:

• Simplicity: There is no need for a different signature when SignalStore is provided at the root level. With [provide, inject] approach, the provide function is not needed for root-level stores.
• Testing: Service can be easily mocked

[MRinaldi9]

Thanks for the explanation about the reasons for use Class instead of two functions. I didn't follow up of all the proposals about the signal store so i'm sorry about the opening of this issue.
For me, using a tuple of functions would help improve the developer experience because, in the case of the inject function, I would have a 'declarative' function that explicitly states what I am injecting, for example, injectUserStore(), and the same would apply to the provide function.
About the "root" problem, maybe with a "conditional" type or with a runtime Error it will be possible to inform the erroneous usage of the provide function, but this is only a proposal without know all the implementations behind.

[markostanimirovic]

Thanks for your feedback @MRinaldi9.

TBH, I don't see DX improvement in both cases. Existing inject:

const usersStore = inject(UsersStore);

vs. proposed:

const usersStore = injectUsersStore();

Existing provide:

providers: [UsersStore]

vs. proposed:

providers: [provideUsersStore()]