Question: Breeze with ngrx

[ganySA]

Hi

Hope this isnt a silly question. Has anyone thought of or used breezejs with ngRX?

I would love to get some thoughts on this - is it even possible?

Thanks

[wardbell]

Haven't really pondered it. My impression of the ngRx movement is that it favors the immutable redux/CQRS approach to data management which is an alternative paradigm to the mutable entity paradigm in Breeze. I think you make an architectural choice between these two; not sure they play well together.

That's not a judgement, btw. More of an observation.

Maybe I'm leaping to conclusions. What were you thinking?

[ganySA]

I was looking at an example of ngrx ontop of angular quite simplistic which relies on json calls.
(https://github.com/HansS/angular2-store-example-ngrx)

All the data calls are based on json / untyped etc.

My thinking was more along the lines of using breeze for data access + strong typing however incorporate it into a ngRx pipeline - ... ngRx could effectively operate ontop of breeze - if that makes any sense.

I havent given it too much thought (i am new to redux) but given that its being pushed quite hard at the moment and because i love the simplicity of breeze it was something i thought would be interesting to at least consider.

I do get your point in that it would be quite a bit of overlap and is an change in architectural choice.

[wardbell]

In our experience, the redux pattern adds complexity w/ no compensatory value. Now I'd feel differently if you were doing DDD, distribute transactions, and had business logic around the semantics of change.

Pete Vogel's article on CQRS in latest MSDN Magazine is quite good on advantage of CQRS in THAT situation. If that's your world and you're ready to pay for the extra maintenance overhead of CQRS/Redux, then you've got a case for switching to that paradigm. Maybe Breeze doesn't make as much sense then.

The key is to understand your needs, not fall for the "its being pushed quite hard at the moment" reasoning. Breeze really IS simpler than redux in practice even though the core ideas of redux are attractively simple.

[markarnolditpro]

I'm following the ngRx / Breeze discussion with interest. I'm a webAPI / EF / Breeze guy. I sense that there has to be a better way to handle the general state across my apps. However it's a non-starter for me to consider giving up ability to easily walk entity relations and handle change mgt of my domain entities without Breeze. I wonder if it's sensible to use both: manage the domain model with Breeze, but manage the other ancillary state (currentItem, isBusy, etc) in ngRx. Thoughts?

[marcelgood]

@markarnolditpro Absolutely, we do that constantly. There are many scenarios within an app where rx is the right tool. For example watching entity changes and perform logic in response to it, binding to life entity lists, service events such as isBusy etc. come to mind. We generally wrap the EntityManager in something like a unit of work or data service and then expose the EntityManager events as Observables. This gives a starting point for many use cases where parts of the app need to react to changes in your domain model.

Here's an example of something that I'm using in my current app. I created an EntityObserver that allows me to obtain life entity lists that I can further qualify with rxjs operators and bind to the UI for various purposes.

export class UnitOfWorkObserver implements EntityObserver {
    constructor(private unitOfWork: UnitOfWork, private metadataStore: MetadataStore) { }

    getEntities<T extends Entity>(entityType: string): Observable<T[]>;
    getEntities<T extends Entity>(entityType: EntityType): Observable<T[]>;
    getEntities<T extends Entity>(entityType: any): Observable<T[]> {
        if (typeof entityType === 'string') {
            entityType = <EntityType>this.metadataStore.getEntityType(entityType);
        }

        return Observable.merge(
            Observable.defer(() => Observable.of(this.unitOfWork.getEntities<T>(entityType))),
            this.unitOfWork.entityChanged
                .filter(x => x.entity.entityType.isSubtypeOf(entityType))
                .map(() => this.unitOfWork.getEntities<T>(entityType))
        );
    }
}