-
Notifications
You must be signed in to change notification settings - Fork 401
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
馃殌 [FEATURE]: List of Breaking Changes planned for V4 #827
Comments
We will be releasing our own dev tool in time, so I'm quite glad that we did not use |
Hi, are there any chances that |
|
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. |
@markwhitfeld @arturovt what do you think about skip VE? and older Angular versions? |
In v4 we could compile for the new Ivy lib format (being introduced in v12) which will drop support for ViewEngine. |
We should also look at flattening the |
Almost after 2 years of this post, is it still on plan or already in dev? 馃 Looks like it is on hold state. 馃槙 //cc @markwhitfeld @splincode |
Hi @irowbin. Yes, and no馃槈. |
When can we expect v4 ? |
Hi @rbrzoska |
Hi. How about implementing newly arrived signals? |
Seems like with Angular@16 we will not be able to use this library until v4 is released because of this https://github.com/angular/angular/releases/tag/16.0.0-next.0
|
@zip-fa Support for signals will be added before v4. There is no prerequisite of any breaking changes for this. 馃憤 @destus90 We will be compiling for the Ivy format in the next minor release (it does not require v4). This would have been released a while back, but is being blocked by a TypeScript bug. We are looking at ways to detect the scenarios that would cause a user to experience this bug because it is not receiving much attention from the TS team. See this comment for more details. |
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 aDeepReadOnly<>
interface (fix(store):ctx.getState
should returnDeepReadOnly<>
聽#2110)dispatch
call should bevoid
, matching its interface (fix(store):dispatch
return observable should be<void>
聽#2109 )patchState
andsetState
should both return void to match their interfaces (Harmonize return value of patchState, setState and getState聽#491) (fix(store):setState
andpatchState
should both return<void>
聽#2114)WebSocket
title casing should be consistent聽#2115)NGXS_WEBSOCKET_OPTIONS
in its public api (fix(websocket-plugin):WebSocket
title casing should be consistent聽#2115)suppressErrors
should be false) (fix(store): enable throwing errors from selectors by default聽#2111)ConfigValidator
,HostEnvironment
andisAngularInTestMode
聽#1741 (comment)ofActionCompleted
. Wheresuccess
andcancel
should befalse
) (fix(store):ofActionErrored
should returnActionCompletion
聽#2112)Actions
stream has to haveActionContext
signature except ofany
..d.ts
file exports of the library (馃殌 [FEATURE]: List of Breaking Changes planned for V4聽#827 (comment)) (build: flatten.d.ts
files聽#2131)@Select
. We would need a migration page in the recipes sections of the docs for both of these.children
property of@State
). We would need migration pages in the recipes sections of the docs for both of these.--
... 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.
The text was updated successfully, but these errors were encountered: