Знаете, вы не первый, кто проводит аналогию между хабром и демократией.
Как известно, аналогия — это средство иллюстрации, а не средство доказательства.
Ни одно государство не дает полной свободы слова, есть темы, запрещенные к публичному призыву и оправданию (сепаратизм, расизм, нацизм и т.д.). Поэтому свобода слова — это количественная мера, а не качественная.
Что касается хабра — тут демократия, а не справедливость. Если кто-то захотел (и не поленился) поставить минус в карму, пусть даже не за дело, пусть даже за мнение — это его право, и жаловаться на это бессмысленно (и чревато еще большими минусами в карму).
Это не имеет ничего общего с выборами и с государством, общее — лишь свобода волеизъявления.
Что касается вашего заминусованного комментария о том, что в "СССР большинству населения жилось лучше" — я думаю, вам ставят минуса не за то, что это мнение неправильное или отличающееся (оно, к сожалению, скорее всего правильное), а за то, как мне кажется, что хорошая жизнь большинства за счет страданий меньшинства — это нечто, достойное осуждения, а не восхваления.
Насколько я понимаю, MobX оборачивает каждый объект в графе в прокси. Хорошо подходит для случаев, когда данные загружаются однажды и редко меняются (ну в принципе любой CRUD и вообще большинство вариантов использования). Для статических частей стора (типа статических гридов) достаточно сравнивать объекты по ссылкам (как в классическом редаксе).
Для часто перезаписывающихся данных (типа отображения обновляемых данных с сервера) это подходит хуже, т.к. нужно опять же проксировать всю иерархию, и это все-равно приведет к перерендеру всего поддерева UI.
Нормальная тема, с точки зрения производительности рендеринга вообще супер, но мне нравится подход редакса к организации и структурированию приложения.
Но, получается, если MobX хорошо работает с агрегатами, на его основе можно сделать эффективный стор для редакса? Селекторы сделать на основе @@computed. Без лишнего копирования и с точечными изменениями (ну а если нужно, то можно и заменять части стора большими кусками, при записи, например, ответа АПИ).
Если у нас граф объектов с глубокой вложенностью, обновление большой ветки графа должно привести к пересчету всех его зависимостей (в том числе и UI). Потенциально это может быть медленно: отписаться от старых данных, обновить данные, пересчитать зависимости.
Поддерживает ли MobX инфо о том, какие зависимости у детей той или иной ветки графа?
Цензурой это было бы, если бы вас забанила администрация. А минуса — это аналог того, что люди не хотят вас слушать, разворачиваются и уходят. Это их право.
Ангуляр (первый) использовал 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 или подобное.
Если использовать тайпскрипт, то эти описания, зачастую, — двойная работа, тк все-равно нужно описывать результат ответа АПИ. И совместить их не всегда возможно.
Забавно распространить рассуждения о классах vs структурах данных на anemic и rich domain model
А не поясните, чем именно? Я много писал на реактовских хуках, вообще не писал на вью, было бы интересно почитать.
А чем эти фичи во Вью круче, чем в Реакте? Не спец по Вью, поэтому интересно.
Можно тип объявить. Я думаю, автор написал инлайн-объявление просто для примера.
Знаете, вы не первый, кто проводит аналогию между хабром и демократией.
Как известно, аналогия — это средство иллюстрации, а не средство доказательства.
Ни одно государство не дает полной свободы слова, есть темы, запрещенные к публичному призыву и оправданию (сепаратизм, расизм, нацизм и т.д.). Поэтому свобода слова — это количественная мера, а не качественная.
Что касается хабра — тут демократия, а не справедливость. Если кто-то захотел (и не поленился) поставить минус в карму, пусть даже не за дело, пусть даже за мнение — это его право, и жаловаться на это бессмысленно (и чревато еще большими минусами в карму).
Это не имеет ничего общего с выборами и с государством, общее — лишь свобода волеизъявления.
Что касается вашего заминусованного комментария о том, что в "СССР большинству населения жилось лучше" — я думаю, вам ставят минуса не за то, что это мнение неправильное или отличающееся (оно, к сожалению, скорее всего правильное), а за то, как мне кажется, что хорошая жизнь большинства за счет страданий меньшинства — это нечто, достойное осуждения, а не восхваления.
Насколько я понимаю, MobX оборачивает каждый объект в графе в прокси. Хорошо подходит для случаев, когда данные загружаются однажды и редко меняются (ну в принципе любой CRUD и вообще большинство вариантов использования). Для статических частей стора (типа статических гридов) достаточно сравнивать объекты по ссылкам (как в классическом редаксе).
Для часто перезаписывающихся данных (типа отображения обновляемых данных с сервера) это подходит хуже, т.к. нужно опять же проксировать всю иерархию, и это все-равно приведет к перерендеру всего поддерева UI.
Нормальная тема, с точки зрения производительности рендеринга вообще супер, но мне нравится подход редакса к организации и структурированию приложения.
Но, получается, если MobX хорошо работает с агрегатами, на его основе можно сделать эффективный стор для редакса? Селекторы сделать на основе @@computed. Без лишнего копирования и с точечными изменениями (ну а если нужно, то можно и заменять части стора большими кусками, при записи, например, ответа АПИ).
Или не все так радужно будет?
На самом деле здорово. Как они, интересно, отслеживают изменения по всему дереву?
Поигрался немного с вашим примером https://codesandbox.io/s/wonderful-pond-gtcmx
Действительно, рендерит только то, что нужно.
Что будет, если полностью перезаписать значение prop1?
Find usages… по интерфейсу стейта, находим все редьюсеры, в коде смотрим, какие экшены проверяются.
И откуда вы возьмете ссылку на уже загруженный объект Customer без нормализации?
Если у нас граф объектов с глубокой вложенностью, обновление большой ветки графа должно привести к пересчету всех его зависимостей (в том числе и UI). Потенциально это может быть медленно: отписаться от старых данных, обновить данные, пересчитать зависимости.
Поддерживает ли MobX инфо о том, какие зависимости у детей той или иной ветки графа?
Цензурой это было бы, если бы вас забанила администрация. А минуса — это аналог того, что люди не хотят вас слушать, разворачиваются и уходят. Это их право.
Этому топику нужна минутка заботы от НЛО
Необходимость в денормализации по идее есть и в мобх, иначе будут высокие затраты на обновление больших поддеревьев
Ангуляр (первый) использовал dirty checking (сравнение объектов) по данным. Реакт использует dirty checking по виртуальному ДОМ. Редакс использует упрощенную систему, сравнивая объекты только по ссылке, хотя во время оптимизации часто переопределяется функция сравнения.
Redux vs MobX — это вторая инкарнация противостояния концепций dirty check (теперь — с иммутабельностью) vs dependency graph (новинка — декораторы).
До этого был AngularJS vs KnockoutJS.
Преимущества и недостатки концептуально остались те же самые:
Dependency graph:
Pros:
Cons:
Dirty checking:
Pros:
Cons:
Что выбрать? На мой взгляд, оптимально использовать dirty checking для большинства мест. Для сложного UI с редко перегружаемыми данным (типа динамических графиков), где важна оптимальность обновления UI — можно использовать MobX или подобное.
Тогда же и точечного обновления не получится?
Если использовать тайпскрипт, то эти описания, зачастую, — двойная работа, тк все-равно нужно описывать результат ответа АПИ. И совместить их не всегда возможно.