Having recently found out about ember-redux, I’m wondering if it is to be used in conjunction with Ember Data, or instead of it?
I’ve been the sole developer on an internal Ember application (using v1.13), but I still feel like an Ember junior dev compared to many, so I’m not sure whether I should seriously consider Redux for a new project I’m on, or if there’s a lot that one has to know or manually hook up that would make it hard for someone like me to transition to it from Ember Data.
Any help/advice/information related to this, or questions I should ask myself to be able to make an informed choice and not regret it in a month is greatly appreciated!
I’m learning React-redux on a project. And I also wonder a similar question.
Redux works well with React because of its component’s stateful design. Under what design of Ember will make Redux compatible with it? Shouldn’t ember-data suffice?
To answer the original question here, while Ember Data and Ember Redux aren’t mutually exclusive (just as using Ember Data and regular Ajax calls for JSON payloads aren’t mutually exclusive), it may get more complicated if you run both in your app.
Ember Redux (from what I’ve seen) gives you quite a bit of control at quite granular levels over how your data updates and when. If you know you need that (or strongly suspect you do), then go ahead and use it. Ember’s designed to allow working with a wide variety of data management systems. But Ember Redux is on the cutting/bleeding edge of Ember’s data handling approach, which means if you don’t know if you need it it may be wiser to stick with the tried and true defaults.
If your main interest in Ember Redux is due to anxiety about not being left behind (or getting out of date), then I would suggest reading Safety of the herd | EmberMap It’s a clear articulation of the idea that most of the time with Ember, the defaults are “good enough” and are well-maintained while new ideas are considered and incorporated into the Ember defaults.
That doesn’t mean that there aren’t warts and flaws to what exist in Ember (there are!), but that often those issues are better understood within the Ember community than the cutting edge addons. Over time cutting edge ideas get incorporated into the defaults in Ember so that we can all use them.
Put another way: what is your risk tolerance/comfort level with cutting edge? and is that cutting edge stuff needed in the app you are working on? If it is, awesome and go for it. If not, choose boring tech … Dan McKinley :: Choose Boring Technology
Just wanted to clarify quickly that ember redux was created in Jan 2016 and has the same shared view on stability that you find throughout the wider ember community. I’ve worked hard to ensure the project is defect free all the while adding new features to push the project forward (just last week we landed support for es2015 class syntax in fact).
If you have any questions about redux or want a specific example of something ping me here or jump into the slack community channel #e-redux
and is that cutting edge stuff needed in the app you are working on? If it is, awesome and go for it. If not, choose boring tech … 