# react
- u
user
05/21/2019, 9:39 AMCompletely breaks one way data flow IMO. - u
user
05/21/2019, 9:39 AMBut I guess MobX is not trying to follow that pattern. - u
user
05/21/2019, 9:40 AMTo be fair the benefit is it's a lot more performant than redux, but that's probably due to not enforcing immutable state at any point. - u
user
05/21/2019, 9:42 AMWhether or not it's two way data binding, it reminds me of it because it's allows you the flexibility to go all over the place for easy wins, and make everything impossible to follow. - u
user
05/21/2019, 9:44 AMBasically when it comes to business logic / your side effect model, when you need data from two separate "states". - u
user
05/21/2019, 9:44 AMAs you would do with redux using action creators / redux thunk / saga / etc. - u
user
05/21/2019, 9:47 AMI guess my problem is that they encourage business logic in the MobX store object, or having logic in there at all period, is nonsensical to me. - u
user
05/21/2019, 9:47 AMCopy codeclass TodoList { @observable todos = [] @computed get unfinishedTodoCount() { return this.todos.filter(todo => !todo.finished).length } } - u
user
05/21/2019, 9:47 AMThat's just a basic getter in that example, but still. - u
user
05/21/2019, 9:48 AMYou have this zigzag of references, especially when you're referencing another store from one store, and have business logic inside that store. - u
user
05/21/2019, 9:52 AMWell OOP doesn't necessitate coupling logic with data, or two way data binding or inheritance or encapsulation, etc. But yes that "style" of OOP I think has architectural issues, but to each their own. - u
user
05/21/2019, 9:54 AMComposition is an OOP concept, for example. - u
user
05/21/2019, 9:54 AMI think a more accurate term would be I like stuff to be data-driven.