feat(store): expose StateContextFactory, StateFactory

[splincode]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/ngxs/store/blob/master/CONTRIBUTING.md#commit
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?

Issue Number: #1323

What is the new behavior?

For the plugin @ngxs-labs/data needs a more api from @ngxs/store. Because @ngxs-labs/data use deep internal manipulation with Store.

Does this PR introduce a breaking change?

[ ] Yes
[x] No

[splincode]

@markwhitfeld Please, I need this functionality in production right now. Therefore, I want to use this functionality in our projects.

Now I can’t wait, so on production I will use

{
  "@ngxs/store": "3.5.1@dev",
  "@ngxs-labs/data": "1.0.1"
}

This functionality is really necessary for the plugin.

[splincode]

One of the big problems is that ngcc generates randomly ɵm, ɵp, ɵt, ...

Therefore, the plugin does not work @ngxs-labs/data

[markwhitfeld]

@splincode As mentioned on the reported issue (#1323) I really do not want to expose the internals of NGXS for plugins. This can compromise the fundamentals of the framework and cause instability in the plugins if we change these internals at a later stage.

The only option that I would accept here is to expose these from the @ngxs/store/internals subpackage. The way I can see to achieve this would be to expose an InjectionToken that will be used for each of these from the internals subpackage. Then those InjectionTokens would be used to provide those classes to the injector within the main @ngxs/store package. In this way these classes will remain in the main package but are accessible to anyone that wants to risk referencing something from the @ngxs/store/internals subpackage. You could expose TS type definitions for these from the internals subpackage too if you like, but not the underlying classes (these should remain in the main package).
(remember that the internals subpackage can receive breaking changes without affecting the semantic versioning)

This the best that I can offer.

[splincode]

@markwhitfeld updated

[splincode]

@markwhitfeld done

[markwhitfeld]

Great!
PS. I'm not sure what the conventions are for naming tokens. I assumed that the _TOKEN suffix is the convention based on what already existed in the file.
@arturovt could you review again?

[arturovt]

I'm pre-approving that.

So after our comments you're free to merge this 😉

[splincode]

• updated
• removed link operator

[markwhitfeld]

Great!

[markwhitfeld]

Ah man, I see the failing tests for NG5.
It would be ideal to use unknown but it is a new TypeScript feature, so we will have to go with any.

[arturovt]

Sure, I’m ok with that.

[arturovt]

Guess we have to drop the support for ng5 as it's like to support mammoths 😁

[splincode]

@arturovt only in V4