Props design introduced is a major regression to this framework

[nhhockeyplayer]

Which @ngrx/* package(s) are the source of the bug?

effects, store, data

Minimal reproduction of the bug/regression with instructions

Whoever introduced Props into NgRX was clearly a react developer
which is in fact javascript developer
which is in fact a language unfit for commercial development
unless its used appropriately for object oriented design principles
JavaScript fails on all fronts
short cuts, one liner whiz bang javascript statements
compounded into one liners with 2-3 dependent things on the one line
compounded into multiple lines of short cuts and unmanageable lines of code all interdependent
dangerous Objects with arbitrary properties plopped onto them used at will
Promises cluttering up the language flow inducing async chaos pinning entire frameworks
async/await language flow chaos (observables are the norm and standard)
this list can go on

When i saw Props introduced into NgRX I knew this was trouble, they have a react developer who only knows javascript short cut habits now managing this beautiful framework.

PROBLEM

actions design is a disaster with zero to little forethought

now google AI search has a sizable blip on how to keep your actions properties in sync with state properties

https://www.google.com/search?q=how+to+synchronize+ngrx+state+key+with+action+props+angular&sca_esv=1c9383e2ef8f1e96&source=hp&ei=TG_PZ8uCF86Cm9cP--3z4Q0&iflsig=ACkRmUkAAAAAZ899XDL2bBGV3qiNnio7IwjjmMr94VFd&oq=how+to+synchronize+ngrx+state+key+with+action+props&gs_lp=Egdnd3Mtd2l6IjNob3cgdG8gc3luY2hyb25pemUgbmdyeCBzdGF0ZSBrZXkgd2l0aCBhY3Rpb24gcHJvcHMqAggBMgUQIRigATIFECEYoAEyBRAhGKABMgUQIRifBUiEcFAAWKtacAB4AJABApgB6QGgAewxqgEHMTguMzIuMbgBA8gBAPgBAZgCMaACtTDCAhEQLhiABBixAxjRAxiDARjHAcICDhAuGIAEGLEDGIMBGIoFwgILEAAYgAQYsQMYgwHCAg4QLhiABBixAxjRAxjHAcICCxAuGIAEGNEDGMcBwgIREC4YgAQYsQMY0QMYxwEYigXCAggQABiABBixA8ICBRAuGIAEwgIFEAAYgATCAgoQABiABBhGGPsBwgILEC4YgAQYsQMY1ALCAggQLhiABBjUAsICCBAuGIAEGLEDwgILEC4YgAQYsQMYgwHCAgUQABjvBcICCBAAGIAEGKIEwgIFECEYqwLCAggQABiiBBiJBZgDAJIHBzE2LjMyLjGgB53GAg&sclient=gws-wiz

this is as bad as it gets

entire codebases whacked and impacted

chasing after that single property

this did not exist with the original NgRX release

its a severe oversight and major regression

massive amounts of time are now spent chasing properties for sizable codebases to get them in SYNC because NgRX state mgt is failing now from this lapse in integrity

Props is bad
its javascript

it needs to be removed from this beautiful framework immediately

and if the architects cannot see that then all is lost

open source doesnt have to be like this

and when javascripters get their hands on things they begin to come apart

those habits are extremely difficult to break

Expected behavior

there should be zero effort to synchronize anything especially properties on state

this design couples the state with the action and its catastrophic

Versions of NgRx, Angular, Node, affected browser(s) and operating system(s)

since version 7

Other information

re-factor
re-design
re-architect

actions

and get Props out of this framework

and reconsider the original action design that does NOT require the widespread synchronization of state properties and action properties

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

• Yes
• No

[nhhockeyplayer]

The architects introducing react constructs and javascript one liner whiz bang statements into these elite frameworks need to wake up
and put a halt to this KIND of integration immediately
several frameworks have suffered major setbacks from this spillover of commercially unfit language

• it affects IDE refactoring mechanisms (what can be said if this breaks IDE refactoring...hellooooo)
• is affects widespread code bases chasing after javascript object properties
• it affects the spread operator
• it violates semantic integrity across the board for what NgRX does (de-coupling asynchronous use-cases elegantly)

yes NgRX imposes a boiler plate
but now that boiler plate comes with chaos
do we want a boilerplate thats water tight (obvious answer is YES) it was originally
do we want a boilerplate that comes with imminent transient chaos affecting everything (obvious answer is NO)
but now we have a boilerplate that has BOTH and its unmanageable normal NgRX development is now in the breakdown lane re-working code to solve the integrity and synchronization of state properties and action properties

JavaScript has its value but requires sensitive containment

• RxJS does this beautifully( 5 stars ***** for that architect)
• Other frameworks that have no choice but to be implemented by a specialist in JavaScript, their implementation strategy is understood and required BUT and they contain the javascript scourge away from the consumer/developer
• NgRX never needed a specialist in JavaScript, and now does NOT contain the javascript scourge away from the consumer/developer

the classes versus creators effort is a case in point
accommodate the react crowd because they do not know real object oriented class taxonomy design and development but javascript short cuts and one liners

D3.js is another that successfully implemented like javascript under the hood but contained it away from the developer

REACT is not a framework to follow its as close to javascript as any other framework can get.
Spilling over its javascript constructs into the use-model for NgRX is wrong and blind sighted and its broken the actions literally from fast boiler plate use-case development.

These architectural features have already polluted elite frameworks creating endless issues and usage

The architects who oversee these architectural decisions better get a clear handle on impact needs to wake up to what they are releasing its crippling what was originally ELITE

Props was clearly a short cut and needs to be backed out

someone has to see this

normal NgRX development is now 75% ballooned effort to chasing and trying to synchronize javascript object properties

well hey the react developer is comfortable doing all of that its their wheelhouse chasing after and managing arbitrary properties plopped onto objects

sorry they can have it
and keep it
at the bottom of productivity and velocity

please wake up to this someone
and take action

and bring NgRX back to what it was

[nhhockeyplayer]

I expect some flames by the pundits who Im very sorry have not impressed me

take this construct for example

there are better water tight ways to implement something as opposed to

1. continue throwing functions at the wall
2. continuing to operate objects plopping properties onto them (its dangerous and always pans out as such)
3. its javascript

export const userActions = createActionGroup({
    source: 'User Actions',
    events: {
        error: props<{ error: any }>(),
        reset: emptyProps(),
        create: props<{ user: UserPojo }>(),
        createSuccess: props<{ user: UserPojo }>(),
        read: props<{ id: Types.ObjectId | string | number }>(),
        readSuccess: props<{ user: UserPojo }>(),
        find: props<{ payload: [] }>(),
        findSuccess: props<{ payload: UserPojo[] }>(),
        update: props<{ user: UserPojo }>(),
        updateSuccess: props<{ user: UserPojo }>(),
        delete: props<{ user: UserPojo }>(),
        deleteSuccess: props<{ user: UserPojo }>(),
        cipher: props<{ user: UserPojo }>(),
        cipherSuccess: props<{ user: UserPojo }>()
    }
});

but this construct has react written all over it
which is javascript

then one may say how to fix?

look at the original design of the Action
I actually helped qualify, validate and develop back in January 2017 when it was initially unfolding

it was released
worked with razor precision successfully
yes it came with a boiler plate but that boiler plate came with water tight success

then the react developers had to shortcut the hell out of NgRX to accomodate the react community because of their habits to javascript and lack of object oriented design which are in fact unbreakable

please refactor Props out of NgRX and secure the integrity of state properties and action properties appropriately

NgRX needs a new action construct

I recommend rolling back to the original one

this sabotage (short cuts, lets make it better, lets integrate react) is now occurring in angular now too
you will find complaints about signals no doubt
Nx is threatened similarly but have not lapsed like NgRX and Im praying they will protect Nx from this language malpractice

[nhhockeyplayer]

Javascript is the wild wild west of the tech field
highly dangerous
it continues to be amplified without oversight
it needs to be contained

react/javascript developers will choose a function or an object with plopped properties on it instead of a class
and the velocity grows from there out of control blind

the original actions construct for NgRX was class based and it was water tight even to the IDE refactoring algorithm

I have seen the one liners react and javascript can accomplish great but in the end when this KIND of mentality finds its way into elite frameworks it cancels out success

I am unable to get the success I previously have had with NgRX (released servers and apps publicly with ease and high velocity) due to this impact. The amount of time spent haggling and re-working code to accomodate is staggering.

it wont take much to repair, unless the current implementation has grown so far & deep which it always happens to

a refactor rightfully should be done by the hands of an experienced object oriented specialist