NGXS follows semantic versioning. As a result we will change the major version number when breaking changes are introduced. Many developers seem to have the idea that upping the major version number is a good thing because it shows progress and is a bit of a marketing opportunity. When following a semantic versioning scheme increasing the version number means that breaking changes have happened, which is not such a positive thing.
Obviously making breaking changes for critical issues should not be avoided but when there are smaller annoyances that need to be remedied then they should be collected together and released together in a single major version update.
This is one such list:
@Selector with parameters in a state class should not receive a default first parameter of the enclosing class state@ngxs/store/plugin sub-package@ngxs/store/internals sub-packageStateContext.getState should return a DeepReadOnly<> interfacedispatch call should be void, matching its interfacepatchState and setState should both return void to match their interfaces (#491)NGXS_WEBSOCKET_OPTIONS in its public apiActions stream has to have ActionContext signature except of any.... still going to add some more to this list, saving the issue for now.
Much of this list has been sitting in my head for months. It feels good to get it out! ;-)
Please raise additional proposals for breaking changes in the comments and I will add them to this list if they are something we would like to introduce for v4.
I am thinking about _destroyable_ states:
@State<Category[]>({
name: 'categories',
defaults: []
})
export class CategoriesState implements NgxsOnDestroy {
ngxsOnDestroy() {
...
}
}
@eranshmil :
Every time I want to install the devtools plugin in a project, I write
NgxsDevtoolsPluginModule, instead ofNgxsReduxDevtoolsPluginModule.
I suggest that we create an alias right now and in version 4, deprecate the old symbol.
We will be releasing our own dev tool in time, so I'm quite glad that we did not use NgxsDevtoolsPluginModule 馃槈
Hi, are there any chances that @Dispatch can be moved from ngxs-labs into this main repo ? Personally I find dispatch is a core functionality like @Select and @Selector so I think it deserves to be in together with @Select and other decorators here.

Latest doc here: https://gist.github.com/LayZeeDK/c822cc812f75bb07b7c55d07ba2719b3
Do not invoke the handleError method on the global ErrorHandler here:
https://github.com/ngxs/store/blob/01e9c46514a7288710a1ec2e23041e162f4315d6/packages/store/src/internal/dispatcher.ts#L35-L49
P.S. needs discussion
@MatissJanis cc.
I would be great if typesafety would be improved.
That's the two things I recall now, but I general it feels like there is a lot of any inside NGXS.
Most helpful comment
Hi, are there any chances that
@Dispatchcan be moved from ngxs-labs into this main repo ? Personally I find dispatch is a core functionality like@Selectand@Selectorso I think it deserves to be in together with@Selectand other decorators here.