search

briebug / ngrx-auto-entity

NgRx Auto-Entity: Simplifying Reactive State
https://briebug.gitbook.io/ngrx-auto-entity/
Other
66 stars 12 forks source link

Ngrx data vs auto entity #91

Closed samratarmas closed 4 years ago

samratarmas commented 4 years ago

Hello team,

I recently discovered ngrx auto entity and have have been loving everything about it. I have two quick questions :

Looking forward to your quick response

jrista commented 4 years ago

Hi Samrat,

Thank you for your interest in NgRx Auto-Entity. We hope it's the right library for you.

Regarding your questions. First off, while we cover some of the same ground as @ngrx/data, we take a very different approach in how we solve the problem. Our approach is more comprehensive, and also more automated in many ways. One of the big features of Auto-Entity is our auto-generated facades, which bring a lot of ready-to-go functionality to your fingertips in just a few lines of code.

Another difference between Auto-Entity and @ngrx/data is we take a bit more of an "angularized" approach, with decorators for the model types that allow you to attach metadata and behavior to your entities in a very simple but familiar way. There are more differences in how the two libraries work as well, and we think some of the more nuanced differences give Auto-Entity the edge in terms of simplicity of usage while still delivering a lot of power. Notably, customizable sorting, to and from server data transformations (brand new as of 0.4.2), and a few other things take Auto-Entity beyond what @ngrx/data can do.

We are also working on adding some additional functionality to auto-entity that will bring it more in line with how NgRx 8 works, with entity action factory functions similar to createAction, support for handling auto-entity actions in side of the new NgRx 8 createReducer functions, etc.

Fundamentally, yes, we do solve the same general problem. Interestingly, our library and @ngrx/data were actually started around the same time, in 2018. Auto-Entity was very much a side project until late 2018, early 2019, and @ngrx/data also had some very big names behind it that kind of overshadowed our efforts. ;) That said, we do love our little library here, and hope that it will help at least some developers simplify their reactive lives.

Regarding using web sockets for CRUD of entities. There is no reason you could not use web sockets. That said, Auto-Entity does work a certain way, and expects that entity services fit a particular model. Either that, or you might need to handle dispatching certain actions yourself.

All of Auto-Entity functions on the simple and fairly common basis of an "initiating" action followed up by correlated "result" actions (a success or failure). There is no reason you could not dispatch one of Auto-Entity's result actions from your own custom sockets-based entity service. All that the Auto-Entity meta reducer expects is for the right data to be present within success or failure actions, and it will reduce the data and take care of the rest (like setting isLoading to false in state for a given entity).

We have also been considering various ways to allow the developer to interject their own behavior into the Auto-Entity workflow. A PatchEntities action has come up in prior discussions, and we may be able to add support so the end developer can configure how the built-in effects work to a greater degree. One possibility may be to add a third possible result action, Pending, in addition to Success/Failure, as well as mechanisms in the entity service to cause such a result. This would allow you to complete the loop that Auto-Entity expects, then deal with completing the process (succeed or fail) on your own.

Picking and choosing exactly what belongs in this library or not has become one o the things we do like to spend some time carefully considering these days. Auto-Entity aims to solve a particular problem, and not every problem is best solved by Auto-Entity. So while there are some ideas for how we might allow web sockets to be integrated, we still need to determine if supporting such a paradigm is really within the scope of Auto-Entity.

jrista commented 4 years ago

I actually do not believe that @ngrx/data has been updated to be in line with ngrx 8. To my knowledge, the architecture of @ngrx/data today is the same as it was in 2018, and has not actually been refactored in any way.

Bringing auto-entity in line with the current design of NgRx 8+ is one of our key goals, however, as we are heavy NgRx users and we like the direction NgRx as a platform is going. Again, I believe this is an advantage you would have with us, vs. @ngrx/data, as I am not sure that maintaining it is one of the long-term goals of the NgRx team. Ironically, both libraries, @ngrx/data and ngrx-auto-entity are kind of at odds with the best practices the NgRx team espouses, as they don't usually advocate for generic actions, etc.

Before you write us off, I would take a look at @ngrx/data, and make sure it is indeed in line with your goals, and also in line with how the rest of NgRx operates. It was, at one point, a separate, third-party library like ngrx-auto-entity, and was just sort of "absorbed" by NgRx in mid to late 2018, but I don't think it has ever really become a "first class" part of NgRx.

tonivj5 commented 4 years ago

I had the same "sensation" about @ngrx/data. A long time ago, I was looking for something like ngrx-auto-entity, but it didn't exist at that time and @ngrx/data seemed the tool, but it didn't cover my needs. Then, I created a kind of auto-entity to my app, covering my needs. If ngrx-auto-entity would have existed, I would be using right now... But I'm following this project very near and waiting to implement it into my application :smile:

So, follow doing this good work :+1:

mxdmedia commented 4 years ago

Back in August, I was looking heavily at ngrx-data as a means by which I could offload a lot of my boilerplate code- only needing to implement more complex things on my own (essentially no boilerplate for basic CRUD operations). The docs for ngrx-data claim that it does just that- handles your basic CRUD ops, while giving "all the flexibility of ngrx" for other stuff. However, (at least at the time) their documentation offered no examples of doing anything but basic CRUD, and questions asked on github and stackoverflow were essentially met with crickets. Even basic stuff like changing the format of your API endpoints was undocumented, and seemingly quite difficult to do.

Auto-entity seems to have been designed much more transparently. It is quite straightforward to add effects, actions, etc.. to your auto-entity handled data. And the auto-entity team has been extremely helpful here on github, either describing how to do some more complex operations, and sometimes even implementing core functionality to do said complex operations easier. I am currently using auto-entity in an active (production) project, and it has been fantastic. Cut out a ton of boilerplate, while allowing me the flexibility I need, with good documentation, and fantastic support.