Комментарии 25
В чем его преимущества перед zustand? Пока вижу лишь многословность
В чем его преимущества перед MobX? Спойлер их нет и быть не может. Ибо:
import { observer } from "mobx-react-lite";
import { makeAutoObservable } from "mobx";
class State {
firstName = '';
counter = 1;
isFetching = false;
serverData = null;
serverError = null;
constructor() {
makeAutoObservable(this);
}
incr = () => {
this.counter++;
}
handleFirstNameChange = (e) => {
this.firstName = e.target.value;
}
fetchData = async () => {
this.isFetching = true;
try {
this.serverData = await someApiRequest();
this.serverError = null;
} catch (e) {
this.serverError = e;
} finally {
this.isFetching = false;
}
};
}
const state = new State();
const App = observer(() => {
useEffect(() => { state.fetchData() }, []);
function decr() {
state.counter--;
}
return (
<div>
<input value={state.firstName} onChange={state.handleFirstNameChange} />
<div>counter: {state.counter}</div>
<button onClick={state.incr}>incr</button>
<button onClick={decr}>decr</button>
<div>server data: {state.serverData}</div>
<div>server fetching: {state.isFetching.toString()}</div>
</div>
)
});Вот посмотреть более расширенный пример и поиграться:
https://codesandbox.io/s/adoring-banach-k8m9ss?file=/src/App.tsx
В этой статье я рассказал о Rematch — мощной библиотеке для управления состоянием приложений.
Мощной? Это шутка такая что ли?) Это типичный банальный ручной pub/sub как и redux и т.п.
Rematch предлагает простой и удобный синтаксис, который значительно уменьшает количество бойлерплейта
Серьезно? Посмотрите на MobX и вы вообще тогда будете в культурном шоке. Вот где реальное отсутствие бойлерплейта и минимально возможное кол-во кода, ну и разумеется реально удобный синтаксис(т.к. он просто нативный).
Надеюсь, что эта статья помогла вам понять преимущества и возможности Rematch и вдохновила вас использовать его в ваших проектах.
Статья - очередное подтверждение что стейт менеджмент не основанный на getters/setters это просто очередная полнейшая шляпа. И уж тем более использовать такие стейт менеджеры в своих проектах это максимально абсурдно и нелепо.
Вот так вот одна технология во всем лучше, чем другая? Нашли ту самую серебряную пулю стейтменеджмента?
Вот так вот одна технология во всем лучше, чем другая? Нашли ту самую серебряную пулю стейтменеджмента?
С удовольствуем буду использовать технологию которая будет ещё лучше, только вопрос, где она?
Тут: https://mol.hyoo.ru/#!section=docs/=yvd6t1_jkrmkc
Лучше по всем параметрам.
Как обычно: it depends.
Для размышления: в микросервисах есть множество паттернов коммуникации, от синхронных вызовов, до event sourcing. И нет одного "лучшего" способа. Так и тут, где-то будет удобнее event sourcing (redux, etc) – offline/local first приложения, где-то mobx, где-то zustand или вообще достаточно встроенного useSyncExternalStore и наколеночный стор.
Как обычно: it depends.
Конкретно во front-end приложениях, управление состоянием есть управление состоянием. И вариантов и кейсов где redux, rematch, effector, zustand и т.п. будет удобнее применять чем mobx(или самописный аналог на getters/setters) просто нет, проверено годами. Ибо ты просто тупо изменил переменную и автоматически приложение на это отргеариговало - всё, в этом и заключается вся суть и весь смысл.
Согласен про серебряную пулю, но человек хотя бы попытался привести аргументы, в отличие от вас
Так и тут, где-то будет удобнее event sourcing (redux, etc) – offline/local first приложения
А почему эту часть проигнорировали? Экшены в Redux это практически CRDT, вот и получается то что в mobx пришлось как-то костылить, в Redux "нативно" работает
Ну и в целом строгость Redux-like подходов может нравиться команде, быть идеологически правильной, а не "я тут мутировал, а там взорвалось". На redux с эффектами на rxjs можно делать очень интересные вещи.
ps. Я согласен, что в среднем по индустрии mobx вполне себе, у нас сейчас на фронте как раз он (я правда не занимаюсь написанием фронтового когда), но в pet проекте у меня redux, потому что он local first
Может CQRS? С CRDT редакс концептуально не совместим, в отличите от того же MobX.
Прям из документации одного из двух самых популярных CRDT библиотек:
Immutable state. An Automerge object is an immutable snapshot of the application state at one point in time. Whenever you make a change, or merge in a change that came from the network, you get back a new state object reflecting that change. This fact makes Automerge compatible with the functional reactive programming style of React and Redux, for example.
То есть вас не смутило, что Automerge - это отдельный огромный стейт менеджер, ни какого отношения к Redux не имеющий даже близко? Я уж молчу про его перфоманс и потребление памяти.
ни какого отношения к Redux не имеющий даже близко
Кроме того факта, что почему-то (странно, ведь отношения никакого нет) практически любой redux-лайк стор отлично кладется на него, да и реализация на rust уже достаточно быстрая https://automerge.org/blog/automerge-2/
Погуглив нашел даже такое: https://github.com/local-first-web/state
Реализация на Rust весит 800кб и падает с прекрасной ошибкой g.__wbindgen_add_to_stack_pointer is not a function. А если вы попробуете использовать его как любой redux-лайк стор, то внезапно обнаружите, что тексты вместо бесконфликтного слияния будут просто затираться последней версией.
Реализация на Rust весит 800кб
Нагло врете!) только wasm часть весит 1.6мб, еще 400кб js
Но кого это волнует, подход такой что серверная часть запущена на клиенте и можно хостить хоть 100мб бандлы
Обновился ради интереса на самую свежую версию:
"@automerge/automerge": "^2.1.1",
Все работает, webpack 5, firefox 118.0b9
если вы попробуете использовать его как любой redux-лайк стор
Зачем его использовать как стор? Упрощенно это готовая реализация редьюсера с поддержкой синхронизации в CRDT. Получаем ивент, мутируем документ внутри automerge, получаем новый immutable документ, который мапим на redux стор. В mobx так не получится, потому что мутируются сразу объекты, а нам нужно получать поток изменений. Можно конечно руками в mobx туда-сюда мапить объекты, но тогда никаких преимуществ от mobx не остается.
Причем automerge как раз таки любит когда внутри него мутируется стейт, а не просетовается полностью новый объект (как, скорее всего, пришлось бы делать с mobx).
Ну и вишенка, через те же action получаем поток ченджей с других клиентов. И мапим так же на стор.
У MobX, как минимум, огромный вес пакета.
Если ваш компонент Арр отрендерить в двух экземплярах, то будет двойная загрузка данных, а индикатор загрузки будет глючить.
Отмечу, что Rematch постоянно развивается и улучшается
Судя по их гитхабу, последний коммит был почти год назад
А чем оно отличается о RTK?
Redux без шаблонного кода это mobx
Тут наверное корректно сравниватьть с Redux Toolkit. Toolkit более популярен, а Rematch хоть и не развивается, но на мой взгляд удобнее. В Rematch есть эффекты из коробки, а в Toolkit надо подключать middleware. Также удобен плагин immer
Rematch — Redux без шаблонного кода