RFC: Move @ngrx/data package to maintenance mode in v17

[markostanimirovic]

Which @ngrx/* package(s) are relevant/related to the feature request?

data

Information

We're considering this decision because @ngrx/data has already been in 'unofficial' maintenance mode for the past few years since it has not been actively improved compared to other packages.

Important:

• This doesn't mean that @ngrx/data package will be deprecated in v17.
• New feature requests for this package won't be accepted anymore.
• Starting new projects with @ngrx/data / adding it to existing projects won't be recommended.

[wawyed]

I really just started using it a few weeks ago 🤣

[rainerhahnekamp]

It really was about time.

Working with the extension points feels like time travel to me. And with the upcoming signalStore we have the possibility to provide a modern alternative.

@wawyed how is your experience so far?

[wawyed]

It was fairly straight forward to make a CRUD UI with it since the conventions for api paths match pretty much my api endpoint. I'm not sure what you mean with extension points?

[rainerhahnekamp]

@wawyed yes, that's the point. If your application is exactly how ngrx/data is designed it is a dream come true.

Should you get off that path - just slightly -, you have a very hard time and you need to get yourself familiar with those extension points: https://ngrx.io/guide/data/extension-points

Normally, it doesn't end there and you end up quite often studying the source code, finding the right services you need to override, etc.

[davidsmith2]

I've been using NgRx Data over the last year or so for some work projects. The REST API for the current application I'm working on doesn't conform to the expectations of NgRx Data; however I implemented a client-side proxy that works around these limitations. Seems like something that could be built into NgRx Data. This and something like ngrx-entity-relationship for working with a normalized store. Thoughts?

[zaquas77]

Serrialy? And what kinds of suggestions you give to substitute it?

[rainerhahnekamp]

@zaquas77 I don't speak on behalf of NgRx, but that's always the dilemma, isn't it?

On the one side, we application developers pick a library with a well-known name in the hope that it will kept in shape. On the other side, the library authors have to make the hard decision if they want to invest in a library which is, in general (what I hear and see), seen as "sub-optimal".

I'm sure they didn't take that decision easily.

Still, take note that this RFC states that no new features will be added. @ngrx/data will still be maintained.

What are possible alternatives?

• The upcoming @ngrx/signals will come with a feature which is very similar. More info here: [Closed] RFC: NgRx SignalStore #3796 (comment)
• You can very easily generate your own generic service without @ngrx/data. The store service has a method addReducer where you can dynamically add a feature state.

[zaquas77]

First of all, thanks @rainerhahnekamp for your quick reply. It's always nice to feel listened to.

What you write is what I was hoping to read :) And now I understand why @ngrx/data seems abandoned to itself :/
I'm sorry because I invested a lot in studying in terms of time.
I take note of the path taken and I don't complain too much. I am therefore very interested in how to replicate the functionality with what you wrote.
With the @ngrx/data I already had all the api rest calls ready, will the new one have them? Or will I have to implement it myself?
I ask these questions not to have a certain answer but to understand how to proceed.

thanks again

[rainerhahnekamp]

@zaquas77 If I were you, I would wait for the first beta of the SignalStore. Only then do we see all of its functionality.

I also guess that the NgRx team will come out with an official recommendation for a potential migration.

[zaquas77]

@rainerhahnekamp I hope too! Early now :)

Thanks, and have a nice weekend!