4 ms·
I feel you're glossing over the strengths of Redux and how utterly ugly MobX code looks. Not to mention it's heavily decorator based, which makes things a _lot
by abritinthebay 10y ago
I feel you're glossing over the strengths of Redux and how utterly ugly MobX code looks.
Not to mention it's heavily decorator based, which makes things a _lot_ more complex and inter-dependant. No thanks.
- sergiotapia 10y agoMobx isn't ugly at all. Are you using decorators? You should. Example: import { observable } from "mobx"; export default class TodoStore { @observable todos = []; constructor(props) {} } // Elsewhere in a different file, now you just use it. import TodoStore from './stores/todos_store.js'; import { observer } from 'mobx-react'; @observer export default class Todos extends Component { constructor(props) { store = new TodoStore() } addTodo = (todo) => { store.todos.push({ id: 1, text: "Get Milk" }); } render() { return ( // Just iterate over `store.todos` ) } } As you can see you just use the variables and get stuff for free out of the box with no plumbing code except `@observable` and @observer`. What's not to love?
- abritinthebay 10y ago> What's not to love? For me? Basically all of that. Also now that code is highly dependent on the framework and tightly coupled. Observables have their place for sure, I like them as a concept actually, but for me MobX is encoding an anti-pattern I try to avoid.
- sergiotapia 10y agoBe careful you don't become an architecture astronaut though. At some point you have to stop working on plumbing and actually solve the business need. https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/ https://www.joelonsoftware.com/2001/04/21/dont-let-architect...
- abritinthebay 10y agoIndeed, a good point to be aware of generally (though I would say we as a group go too far the other direction most times). But the issue here with that is that I can solve the business needs in React+Redux trivially without running into the architectural problems I mentioned in MobX. So why on earth would I chose the inferior option?
- mikewhy 10y agoSome questions already arise from that example: - How do two separate components access the one store, singletons? - If two components observe the same store but render different attributes of it are they both updated when the store is updated? - Are you limited to modifying your store only in your component?
- timdorr 10y ago> How do two separate components access the one store, singletons? You can use <Provider> and @inject to put a store onto the component tree and pull it off whenever you need it. It's just a quick wrapper around the React context API. > If two components observe the same store but render different attributes of it are they both updated when the store is updated? Yes, this is just how Mobx works. Observations are set up implicitly. You can observe any @observable value or @computed function just by referencing it within an @observer. > Are you limited to modifying your store only in your component? Nope, this works with just plain JavaScript. The main library doesn't offer any React-specific bindings (like Redux), so it can be used with anything.
- banachtarski 10y agoSo much FUD
- abritinthebay 10y agoI swear, there are some users on HN (like yourself) that think FUD is some kind of magic pixie dust to invalidate someones statement. I thought we grew out of that in the early 2000s.