Обновить
10
0

Full-stack web developer.

Отправить сообщение
Как понять, что диспатч какого-то редьюсера экшена изменит нужный мне "класс"?

Find usages… по интерфейсу стейта, находим все редьюсеры, в коде смотрим, какие экшены проверяются.

И откуда вы возьмете ссылку на уже загруженный объект Customer без нормализации?

Если у нас граф объектов с глубокой вложенностью, обновление большой ветки графа должно привести к пересчету всех его зависимостей (в том числе и UI). Потенциально это может быть медленно: отписаться от старых данных, обновить данные, пересчитать зависимости.


Поддерживает ли MobX инфо о том, какие зависимости у детей той или иной ветки графа?

Цензурой это было бы, если бы вас забанила администрация. А минуса — это аналог того, что люди не хотят вас слушать, разворачиваются и уходят. Это их право.

Этому топику нужна минутка заботы от НЛО

Необходимость в денормализации по идее есть и в мобх, иначе будут высокие затраты на обновление больших поддеревьев

  1. Да, отсутствуют описания классов модели. Я использую тайпскрипт, поэтому такой проблемы нет.
  2. Можно, но нужно их копировать при изменении, либо использовать иммутабельные аналоги
  3. Да, есть такое

Ангуляр (первый) использовал dirty checking (сравнение объектов) по данным. Реакт использует dirty checking по виртуальному ДОМ. Редакс использует упрощенную систему, сравнивая объекты только по ссылке, хотя во время оптимизации часто переопределяется функция сравнения.

Redux vs MobX — это вторая инкарнация противостояния концепций dirty check (теперь — с иммутабельностью) vs dependency graph (новинка — декораторы).


До этого был AngularJS vs KnockoutJS.


Преимущества и недостатки концептуально остались те же самые:


Dependency graph:
Pros:
  • точечное обновление, соответственно быстрая и оптимальная перерисовка UI

Cons:
  • нужно описывать модели
  • проблемы с сериализацией и десериализацией
  • изначальная загрузка данных в модели небесплатная, из-за необходимости построения графа зависимостей
  • ад с вычисляемыми свойствами и зависимостями зависимостей
  • сложная кухня внутри, связанная с тем, что вычисления не должны зацикливаться и не пересчитываться по несколько раз
  • невозможность использовать стандартные структуры данных (массивы, хэши и сеты, и т.п.). Возможно, сейчас ситуация и поменялась, но я не вижу, как бы это могло произойти

Dirty checking:
Pros:
  • Работает с любыми данными, работает со стандартными структурами данных
  • Можно использовать селекторы и любые преобразования данных
  • Не требует специальных действий для сериализации и десериализации
  • Проще и предсказуемее, за счет отсутствия скрытых зависимостей и сложной внутренней кухни
  • Есть возможность небольшой оптимизации при помощи сравнения по ссылкам для больших деревьев, если часть дерева не поменялась

Cons:
  • Не реактивно (требует внешнего события для обновления UI), впрочем в редаксе это не проблема, т.к. есть естественные события в виде диспатча экшенов.
  • Потенциально медленнее

Что выбрать? На мой взгляд, оптимально использовать dirty checking для большинства мест. Для сложного UI с редко перегружаемыми данным (типа динамических графиков), где важна оптимальность обновления UI — можно использовать MobX или подобное.

Тогда же и точечного обновления не получится?

Если использовать тайпскрипт, то эти описания, зачастую, — двойная работа, тк все-равно нужно описывать результат ответа АПИ. И совместить их не всегда возможно.

MobX (без дополнительных расширений), насколько я понимаю, решает одну проблему: точечное (и поэтому эффективное) обновление UI без перерендера всего дерева.


Redux решает проблему структурирования бизнес-данных приложения и управления состоянием, но в части обновления UI он работает неэффективно, полагаясь на эффективность рендера Реакта (зря) и некоторые простые оптимизации (тоже зачастую нерабочие).


Идеальным было бы (ну, по крайней мере, для меня) совмещение этих двух подходов. Возможно, именно этим и занимается mobx-state-tree.


В плане управления и структурирования состояния для меня Redux вполне норм, если обмазаться хелпер-либами (но это изнанка простоты редакса). В плане оптимизации рендеринга Редакс ужасен.


Было бы круто их совместить, но без заморочек MobX типа описания классов для всего.

Нет, ПХП-подход — это писать в файле страницы всю логику, начиная от запросов в базу.


JSX — это обычный шаблонизатор для HTML, который имеет хорошую и максимально приближенную к Javascript модель для программирования шаблонов.


И да, внутри JSX нельзя ходить в базу и делать запросы на сервер, как нельзя их делать, например, в шаблонах Ангуляра (хотя можно делать в компонентах).

Ну по идее статья написана именно для таких людей? Те, кто пробовал и redux, и mobx, обычно имеют собственное мнение.

Собственно, мой вопрос заключается в следующем: для полноценного SSR необходимо грузить стейт на сервере, рендерить страницу, а потом стейт сериализировать в страницу (в тег script обычно).


Судя по архитектуре MobX, в котором модели являются классами, моделям требуется специальный сериализатор.


Поддерживают ли модели MobX сериализацию?

Вы делали SSR на MobX?

А можете поподробнее рассказать: это граждане в личный авто должны устанавливать глонасс?

Возможно, в деревне два брадобрея, и они бреют друг друга. В условии парадокса в посте не сказано, что он в деревне один.

Писать микросервисы имеет смысл, когда:


  • Это действительно сервисы, а не попытка сделать модули, которые вызываются через HTTP
  • Есть несколько готовых микросервисов, которые можно использовать в проекте
  • Функционал приложения предполагает, что разработанные микросервисы можно будет переиспользовать в дальнейшем
  • Есть требования по поддержке предыдущих версий АПИ — запустить инстанс микросервиса, собранный из определенной ревизии проще, чем поддерживать несколько версий в исходниках (тут, конечно, остается вопрос версионирования базы, но он будет решаться и так, и так).

Обычно сливают не за "собственное мнение, отличное от большинства", а за "Собственное Мнение, Отличное От большинства, которые вообще дураки и не понимают Глубины Моей Правоты И Бездны Своего Невежества".

Информация

В рейтинге
Не участвует
Откуда
Украина
Дата рождения
Зарегистрирован
Активность