Just want to start off by thanking @mweststrate for creating and supporting mobx. I had some free time try it out over break and this library really deserves all the credit it can get.
Since I'm using redux currently, I thought the redux/mobx crossover example in this repo was intriguing, so I started playing around with it in my application. It's a rather large react/redux app that has been in production for 6 months. I started converting setState to mobx by following the implementation in this article and I definitely saw major benefits in our application with minimal refactoring. I still think redux serves as a fantastic external store, but I would like to incorporate mobx wherever it makes sense.
I was testing computed props like the example one below. Amazingly the computed prop worked in this case, which appears to be serving the same purpose as reselect. My question is, since I'm still new to mobx and I'm not 100% sure of what's going on inside of both of these libraries, would this approach allow me to ditch reselect? Is the connect HOC optimized for mapping a redux state tree to a mobx observable or can it be built even better? By using the same compatible connect api, this will make it easier for us to adopt mobx into a large redux application so they can work together and get the best of both worlds.
import {connect} from 'react-redux'
import {observer} from 'mobx'
const mapStateToProps = (state) => ({
// regular props
foo: state.foo,
bar: state.bar,
// computed prop
get todos() {
switch (state.visibilityFilter) {
case 'SHOW_COMPLETED':
return state.todos.filter(todo => todo.completed)
case 'SHOW_ACTIVE':
return state.todos.filter(todo => !todo.completed)
default:
return state.todos
}
}
})
export default connect(mapStateToProps)(observer(TodoList))
Yes! @computed is basically automatic reactive reselect. That's a good way to think about it.
Whenever you run the computed function it tracks which observables you touch and only recomputes the computed when those changed.
This approach would allow you to ditch reselect for a faster and reactive alternative. Reselect is nice for selectors if you're not using something that does automatic dependency tracking - since you are I recommend you exploit its power :)
Going to archive this now, let me know if anything was left unclear.
Most helpful comment
Yes!
@computedis basically automatic reactive reselect. That's a good way to think about it.Whenever you run the computed function it tracks which observables you touch and only recomputes the computed when those changed.
This approach would allow you to ditch reselect for a faster and reactive alternative. Reselect is nice for selectors if you're not using something that does automatic dependency tracking - since you are I recommend you exploit its power :)