Store: 馃殌 [FEATURE]: List of Breaking Changes planned for V4

Created on 9 Feb 2019  路  6Comments  路  Source: ngxs/store

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:

  • [ ] An @Selector with parameters in a state class should not receive a default first parameter of the enclosing class state

    • See: https://github.com/ngxs/store/issues/386#issuecomment-395780734)

    • Related: #541 #446

  • [ ] The plugin interfaces should be part of a @ngxs/store/plugin sub-package
  • [ ] Review plugin architecture, possibly include more extensibility points than just middleware
  • [ ] NGXS internals currently exposed as part of the public api should be moved to the @ngxs/store/internals sub-package
  • [ ] The StateContext.getState should return a DeepReadOnly<> interface
  • [ ] The value passed in the observable returned from a dispatch call should be void, matching its interface
  • [ ] patchState and setState should both return void to match their interfaces (#491)
  • [ ] The web socket plugin should have consistent Title casing of the word WebSocket (#825 #820)
  • [ ] The web socket plugin should not expose NGXS_WEBSOCKET_OPTIONS in its public api
  • [ ] The storage plugin should not expose tokens in its public api
  • [ ] Improve public interface type safety
  • [ ] Disable suppress errors in selector
  • [ ] Default the developmentMode setting to align with the angular dev mode.
  • [ ] The聽ofActionErrored聽pipe should return the error as well as the action.
  • [ ] The Actions stream has to have ActionContext signature except of any.

    - Please add the motivation for the additional items you add on this list as a comment below

... 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.

discussion not an issue on hold

Most helpful comment

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.

All 6 comments

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 of NgxsReduxDevtoolsPluginModule.
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.

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.

  • [ ] dispatch should not take any but there should be an interface defined for actions
  • [ ] ngxsForms could provide an (generic) interface for state, that contains also the different states of status

That's the two things I recall now, but I general it feels like there is a lot of any inside NGXS.

Was this page helpful?
0 / 5 - 0 ratings