In a lot of applications, we face issues tracing the source of mutated data.
React/Redux apps use reducers as pure functions to fix the issue of mutating data (i.e. by not directly mutating the state object)
I wanted to understand what equivalent feature does Ember provide to handle such issues ?
Does DDAU fix this by any way? Any simple examples would really help in understanding.
Well Ember does have a redux implementation: ember-redux. So there’s that.
DDAU helps in the sense that, if properly implemented, you will typically end up with only one “owner” of each piece of state, and only the owner should be mutating that state. Ember Octane has taken this idea even further with immutable args and some other features. Jessica Jordan recently gave a great talk on the subject.
@harimath I still maintain ember-redux and we’ve got support for both Ember Components and Glimmer Components if you’re interested in giving it a look. It certainly requires more code to be explicit like this but if you value the traceability benefits you get w/ immutability as I do you might find it simpler to reason about your data flow.
I’ll link the redux dev tools for chrome because they offer both time travel but also the ability to import/export state so you can (better) collaborate between QA/Dev as shown in the video below