3 ms·

> When using React I usually just use MobX and everything just works. MobX is signals library. In other words, you are already using the signals way of doing t

> When using React I usually just use MobX and everything just works. MobX is signals library. In other words, you are already using the signals way of doing things if you mostly manage your state with MobX. I still use MobX as well if I think I can't use SolidJS. SolidJs if you haven't looked has MobX-like tools built in, computed, autoruns and all the same tools, it triggers "renders" when one of the signals changes. In reality it doesn't have renders, because it's not based on VDOM, but it makes it look like it does. However I like to keep my signal library separate, I would wish SolidJS had separate signals library I could use elsewhere as well. Also SolidJS is big library and framework by now, it comes with risks if Ryan Carniato were ever to loose interest. Edit, I also found that Ryan has created an example of MobX and JSX without React, it's a good way to demonstrate that React is not as important with signals libraries: https://github.com/ryansolid/mobx-jsx https://github.com/ryansolid/mobx-jsx since you know MobX that example probably makes sense.

Illniyar 4y ago
I haven't used SolidJS, so I can't comment much. But Signals have very good developer ergonomics. But from my experience other frameworks that use them come with drawbacks that I don't get with react. So MobX+React works better for me than - let's say vue. From a brief look at their website, the downsides for using SolidJs for me seem pretty big. At the very first example, if you change it slightly you can see my problems: const CountingComponent = () => { const [count, setCount] = createSignal(0); const interval = setInterval( () => setCount(count => count + 1), 1000 ); onCleanup(() => clearInterval(interval)); if (count() % 2 == 0) { return <div>Even count value is {count()}</div>; } return <div>Odd count value is {count()}</div>; }; 1. MobX let's me use objects without additional syntax (createSignal, count() instrad of just count) 2. The fact that the component does not rerender and that my code does not automatically change between even and odd text means I'll probably need to have an additional mental model for writing SolidJS components. Using React+MobX I just write as I would write any other function and it'll just work (There's magic involved, but manageable magic)
- c-hendricks 4y ago
  There was a debate very recently between SolidJS and React communities over "internalized react-isms" like difference in behaviour you've pointed out. I think it's React that are doing the weird thing and calling your whole function again when one piece of data changes, but I do like having the ability to return early.

Illniyar 4y ago

I haven't used SolidJS, so I can't comment much. But Signals have very good developer ergonomics. But from my experience other frameworks that use them come with drawbacks that I don't get with react. So MobX+React works better for me than - let's say vue. From a brief look at their website, the downsides for using SolidJs for me seem pretty big. At the very first example, if you change it slightly you can see my problems: const CountingComponent = () => { const [count, setCount] = createSignal(0); const interval = setInterval( () => setCount(count => count + 1), 1000 ); onCleanup(() => clearInterval(interval)); if (count() % 2 == 0) { return <div>Even count value is {count()}</div>; } return <div>Odd count value is {count()}</div>; }; 1. MobX let's me use objects without additional syntax (createSignal, count() instrad of just count) 2. The fact that the component does not rerender and that my code does not automatically change between even and odd text means I'll probably need to have an additional mental model for writing SolidJS components. Using React+MobX I just write as I would write any other function and it'll just work (There's magic involved, but manageable magic)

c-hendricks 4y ago
There was a debate very recently between SolidJS and React communities over "internalized react-isms" like difference in behaviour you've pointed out. I think it's React that are doing the weird thing and calling your whole function again when one piece of data changes, but I do like having the ability to return early.