Все дело не в том, что геттер будет вызывать каждый раз когда изменяются его зависимости(так и должно быть), а в том, что он является computed'oм и реакции которые на него подписаны должны вызываться только тогда, когда значение этого самого compted изменяется.
Т.е. autorun подписался именно на значение less и в MobX autorun срабатывает когда именно значение less изменяется. А у вас срабатывает когда изменяется любое свойство от которого зависит этот computed.
Все дело не в том, что геттер будет вызывать каждый раз когда изменяются его зависимости(так и должно быть), а в том, что он является computed'oм и реакции которые на него подписаны должны вызываться только тогда, когда значение этого самого compted изменяется.
Аккуратно с текстами, а то целых гигантских 30kb траффика загрузите, это же огромный минус, который сводит на нет использование интернета как такового. Вот ещё бы вы килобайты не гоняли по сети да? И лишний стакан воды смотрите не выпейте, а то временно обретете плюс 300 грамм огромной массы, это тоже сводит на нет все плюсы от питья воды. Куда не посмотри, везде сплошные огромные минусы.
( можешь не отвечать, бред этот читать не намерен, тратить своё время )
Это правильно, не стоит 30kb трафика гнать через своего провайдера, это не позволительно.
Это факт, посмотри сколько весит redux, zustand, effector и прочие стейт менеджеры
Какая разница сколько весят этот "прекрасные инструменты"? Если они всё равно не пригодны для адекватного использования.
Ещё раз, посмотрите сколько весит React + React DOM, с вашей "логикой" вы вообще вошли не в ту дверь :D Во первых реакт весит намного больше чем vanila js, peact, и т.д. и т.п. Во вторых браузер это вообще монстр которой выжирает оперативную память и процессорное время на раз два. В третьих JS намного больше ресурсов потребляет в отличии от СИ. Ну и так далее по списку.
Вам нужно в мир микроконтроллеров, вот там все программы занимают сотни байт, иногда несколько килобайт, особо сложные и огромные занимают десятки килобайт. Процессор там используется по назначению и каждый тик на счету. Там есть прямой доступ к памяти, а ещё там каждый байт этой самой памяти на счету, а не вот это вот всё.
а это БОЛЬШОЙ минус, который перекрывают сплошные плюсы при работе с MobX
Так смешно конечно))) Перекрывает говорит))) Двигатель в машине кстати знаете сколько весит? Архренеть сколько, ну его нафиг, давайте выкинем. А КПП? Тоже фигня какая, весит много - ОГРОМНЫЙ минус, тоже в топку. Теперь машина весит на пару сотен кг легче, правда больше не ездит, но это не важно, главное мы избавились от ОГРОМНОГО минуса в виде пары килограмм. Вот посмотрите на велосипеды, там вообще вся система весит от силы 1-2 кг и там 24 скорости и двигатель не нужен, педали крути и вперед. Вот идиоты в машины ставят какие-то ДВС тяжелые, КПП какие-то, ещё и автоматические, так они ещё тяжелее, да ещё и кпд у них похуже будет, капец просто, во дают. Более того, они на столько упоротые что ещё какую-то жижу туда заливают, бензин кажется называется, полный бак заливают и ещё +50кг в весу, как там Задорнов то говорил всегда?)
Если для тебя разница в 30-40кб не является минусом, тем более в большом проекте, то видимо у тебя недостаточно опыта рассуждать на эту тему
Ахахха, а да?) Ну раз такие критерии, то да, более того у меня ещё в зависимостях react+react-dom которые весят как 3-4 Mobx'a, так что я вообще полный ноль.
но у него достаточно огромный минус - это размер бандла по сравнению с аналогами
Серьезно?)) Огромный минус?)) Я разочарован. Напомните ка сколько там весит react +r eact-dom?) 1kb? Ага) Этот "минус" невероятно притянут за уши, в масштабах проекта. его размер вообще ничего не значит. Тем более благодаря ему, самого по себе кода надо писать гораздо меньше, а это тоже дает экономию в размере тоже, по факту этот "минус" не актуален.
С таким же успехом можно сказать что JS это один сплошной минус, по сравнению с ассемблером или CИ, он намного тяжелее, медленнее, жрет намного больше памяти и т.д. и т.п., давайте все дружно теперь писать на ассемблере, ведь это так удобно и классно))
А эффект реагирует лишь на изменение значения его атома, но никаких других.
Поздравляю, это Pub/Sub.
const events = new EventEmitter();
// "эффект"
events.on('event1', () => console.log('fire event1'))
// "атом" для "эффекта" event1
events.emit('event1'); // event1 регагирует
// "атом" для "эффекта" event2
events.emit('event2'); // event1 НЕ регагирует
Получается "эффект" event1 реагирует на "атом" event1, и не реагирует на "атом" event2 . Прямо как вы и описали.
Но даже его к паб-сабу не притянуть, так как такой эффект в данной реализации может быть только 1.
А кто запретил подписаться на event1 только один раз?) Хочешь будет только один callback реагировать на even1, хочешь 10 callback'ов будет реагировать. Хозяин барин.
Ага, это седан. Ни в коем случае это не автомобиль, это именно седан. Автомобиль это вообще другое.
А по вашей демагогии выходит, что любое чтение и запись в переменную - это паб-саб.
Нет, не любое. Если изменение переменной приводит к реакции на это, то это Pub/Sub в базе своей. Вы можете это завернуть в 10 оберток и обозвать белкой, но от этого истинная суть не меняется, есть те, кто подписан на изменения, а есть те, кто оповещают подписчиков об изменениях. Под каким соусом всё это подано, это уже детали реализации, но сам базовый принцип тот же.
Также по умолчанию там пидписчики триггерятся синхронно, сразу по завершении действия (хотя и это можно настроить). В ряде кейсов это бывает удобно.
В 99.9% случаев автобатчинг(асинхронные реакции) предпочтительней. А для 0.1% опционально можно взводить флаг и реакция будет синхронной, я так и делаю и с MobX'ом (по умолчанию он у меня разумеется сконфигурирован на автобатчинг (асинхронные реакции)) используя это для компонента Input и Textarea, для них нужны именно синхронные реакции, иначе если курсор поставить не в конце текста, то его перебросит в конец во время ввода. У kr-observable это как раз и происходит, поэтому нужно добавлять возможность помечать свойство, чтобы на его изменение были синхронные реакции и/или взводить флаг и пока он в true, реакции на все изменения чтобы были синхронные. А так да, автобатчинг в 99.9% случаев более чем полезен и необходим.
Это называется Watch, никаких подписок между атомами тут нет.
Какая разница как это называется? Хоть белка. И при чем тут между "атомами" вообще? Если watch смотрит за изменениями, а значит пописан, а значит pub/sub.
А ни кто не говорит, что Pub/Sub в этом случае должен светиться в публичном АПИ, вся суть в другом, что итоговый принцип такой же. Есть подписчики, и есть те, кто уведомляет подписчиков.
Атом (atom/cell/signal) имеет семантику ... и дальше по тексту
Реализация наблюдателя / pub/sub с дополнениями, например в виде введения computed'ов, и спасибо если они хотя бы будут кэшируемые. Разумеется более хитрая, с проверкой на то, было ли реальное изменение или нет и т.д. и т.п.
Но глубинный принцип оповестить об изменениях наблюдателя/подписчика остается неизменным.
Дело в том, что в Solid нет понятия атомов, а @nihil-proсказал, что атомы ему не нравятся
Думаю под "атомами" он имел ввиду ряд реализаций,в том числе сигналы(ибо путаница понятий)) И там речь была про "атомы" и сигналы(так же конкретная реализация наблюдателя).
И того, в сухом остатке получается: 1) Реализация наблюдателя реализации наблюдателя рознь, и они могут быть прям как небо и земля. 2) Все сравнения в данном контексте на самом деле именно реализаций наблюдателя, даже когда люди их пытаются называть как отдельные вещи, аля атомы или сигналы, потому что по сути всё это и есть наблюдатель (mobx, redux, effector, signals и т.д. и т.п.).
то почему мы сравниваем реализацию с интерфейсом (паттерном)
Наверное потому что многие люди уже запутались, где названия реальных паттернов, а где выдуманных, которые являются реализациями) Оно и понятно, по наплодили всякой фигни, которая является один и тем же и называют по разному с умным видом)
Типо нет, это не чайный гриб, это камбуча)) Или нет, это не прыщ, это акнэ))
Нет такого понятия(в мире программирования) как атом, атомов-обсёрваблов и т.п. Это просто люди сами обозвали свои реализации атомами. В свою очередь всё это фактически реализации Observer / Publisher-Subscriber, просто они решили не говорить pub/sub а решили сказать что это атом, с таким же успехом можно было сказать это белка, и потом кто-то бы спрашивал, а чем белка отличается от наблюдателя.
Вот смотрите, есть седан, есть хэчбэк, есть внедорожник, есть "джип", и т.д. и т.п., и всё это автомобиль. Нельзя сравнивать автомобиль и седан, или автомобиль и внедорожник. Ибо это одно и то же, просто детали реализации иные. Вот сравнить седан и хэчбэк можно, т.к. тут идёт сравнение именно деталей реализации автомобиля, а не автомобиля как такового.
Касаемо MobX и kr-observable: Это просто реализация паттерна Наблюдатель (Publisher/Subscriber) с использованием возможностей языка JS (getters/setters), которые и позволяют тот самый неявный механизм подписок и уведомления об изменениях. А не какие-то особенные атомов-обсёрваблов .
Observer это реально существующий паттерн. Atom - нет.
В этом принципиальная разница)
Всё это, в том числе так называемый "атом" это реализации Observer, разной степени паршивости.
Observer в свою очередь это просто самый банальный Publisher/Subscriber.
С таким же успехом вы можете говорить, что вы пьете камбуча, но по сути вы просто пьете чайный гриб. Просто в первом случае это звучит по прикольнее, а чайный гриб звучит как то не очень.
Иными словами, вообще не стоить придавать значения этим словам и терминам. Главное понимать суть. Реактивное(это когда мы любым образом реагируем на что-то, и любым образом провоцируем те самые реакции. Не надо вкладывать в это слово что-то эдакое сложное) состояние(у него 100500 реализаций) это всегда Publisher/Subscriber по принципу работы. Subscriber в случае с реактом это компонент(а точнее его forceUpdateфункция), а Publisher это любое проявление уведомления Subscriber'a, о том, что ему надо выполнится. В случае стейт менеджмента это триггер forceUpdate функции компонента после изменения данных, которые в нем используются, например увеличения счетчика.
Но что уважаемый автор в это вкладывает, заявляя, что атомы ему не нравятся?
Ему не нравится их реализация, мне впрочем тоже. Посмотрите на код который нужно писать и всё сразу станет понятно. В этом и есть вся суть. В одном случае ты не делаешь лишних телодвижений и не нагружаешь код лишним мусором, в другом случае делаешь и нагружаешь.
"атомы" в данном контексте (я про программирование, а не про настоящие атомы) это крайне размытое понятие, и каждый трактует его и имплементирует как хочет. Поэтому тут не может быть сравнения лоб в лоб. Но вы можете посмотреть на то, какой код нужно писать используя так называемые "атомы" в различных реализациях и на код, который нужно писать используя то, что предлагает автор. Ну или можете посмотреть на MobX, по сути это тот же самый принцип, но подкапотная реализация иная.
Observable это тоже общее понятия, но его реализации могут быть принципиально разными, в одном случае это может быть MobX, в другом вот это:
С ручными подписками, отписками и испусканием событий. Вот и сравните их, и то и то как бы является Observable, но если сравнить их лоб в лоб, то это небо и земля в плане удобства использования в качестве управления состоянием.
В случае с MobX или kr-observable код остается максимально нативным, хотите увеличить счетчик? Пожалуйста this.counter++ или someState.counter++ . Хотите изменить значение флага? Пожалуйста this.opened = true или someState.opened = true .
Главное всё это можно делать из любого места и в любой момент.
Под "слишком правильным" я имел в виду попытку писать так, как говорят бородатые дяди у себя на каналах
А с чего вы взяли что эти самые дядьки говорят правильные вещи? С умным видом можно задвигать что земля плоская и т.д. и т.п. и что теперь, верить на слово каждому такому дядьке что ли? Умный человек отличается тем, что у него прежде всего критическое мышление, т.е. он не опирается на "авторитеты", а прежде всего сам думает своей головой, сам проверяет те или иные вещи. Если дядька говорит делать вот так, это хорошо, а ты понимаешь что че-то он несет какую то чушь, то с вероятностью >99% он и правда несет чушь. Даже если эту чушь будут поддерживать многие люди, не обладающие критическим мышлением разумеется. Опять же, далеко за реальными примерами ходить не надо - плоскоземельщики, антиваксеры и т.д. и т.п.
Разработчики время от времени пытаются быть максимально "трушными", тыкая отрывками из умных книг или best practices, где надо и где не надо
Как показывает практика, примерно 99.9% из этих "разработчиков" пишут в итоге жесточайший, неподдерживаемый write-only говнокод.
Счастье в простоте
Именно. Причем это настолько очевидно, что даже странно, откуда у некоторых(слава яйцам не у всех) людей берется тягота превращать простые вещи в очень сложные. Это же настолько нелепо, что порой просто смешно.
KISS и YAGNI во главе всего - единственный путь к реально хорошему коду и реально хорошей архитектуре. Где ты не будешь бороться с тем, что ты наплодил, а просто будешь решать конкретные задачи.
Да, это прям мечта, так классно и просто поддерживать, прямо загляденье. Вот мы идиоты то, мучаемся, используем scss/css, и пишем ужасные display, padding, font-size и т.п. Бррр, аж кровь из глаз течет от этих ужасных свойств. Ох, а если миксин заюзать, ууу тогда пиши пропало вообще.
.button {
height: 40px;
padding: 0 40px;
display: inline-flex;
align-items: center;
justify-content: center;
border-radius: 5px;
cursor: pointer;
transition: all .3s ease;
outline: none;
border: none;
// Набор стилей для текста из дизайн системы
@include typography('Text Regular_16', '#fff');
&[data-full-width="true"] {
display: flex;
width: 100%;
}
// На мобильных устройствах hover нам может вредить
@include respond-to-desktop-only {
&:hover {
// Цвет из дизайн системы
background-color: color('Purple_3');
}
}
&:active {
// Цвет из дизайн системы
background-color: color('Purple_2');
}
@include respond-to-mobile {
display: flex;
width: 100%;
padding: 0 20px;
// Набор стилей для текста из дизайн системы
@include typography('Text Thin_14');
}
}
Целиком делать проект нет смысла, да и сравнивать скорость нет смысла, ибо ctrl+c / ctrl-v из фигмы всегда быстрее. или fz + tab + 16px = font-size: 16px; как минимум не уступает сокращениям из tailwind.
Просто повторите аналогичный стиль для кнопки, где
Да, это верно. Этот баг нужно тоже поправить.
Быстрая проверка:
https://stackblitz.com/edit/vitejs-vite-tkqgrj?file=src%2Fmain.ts&terminal=dev
Ну вот, другое дело
Все дело не в том, что геттер будет вызывать каждый раз когда изменяются его зависимости(так и должно быть), а в том, что он является computed'oм и реакции которые на него подписаны должны вызываться только тогда, когда значение этого самого compted изменяется.
@Alexandroppolus имеет ввиду вот в чем соль:
kr-observable
https://stackblitz.com/edit/vitejs-vite-5hdb1d?file=src%2Fmain.ts&terminal=devmobxhttps://stackblitz.com/edit/vitejs-vite-djgmcs?file=src%2Fmain.ts&terminal=dev
Т.е. autorun подписался именно на значение
lessи в MobX autorun срабатывает когда именно значениеlessизменяется. А у вас срабатывает когда изменяется любое свойство от которого зависит этот computed.Все дело не в том, что геттер будет вызывать каждый раз когда изменяются его зависимости(так и должно быть), а в том, что он является computed'oм и реакции которые на него подписаны должны вызываться только тогда, когда значение этого самого compted изменяется.
Аккуратно с текстами, а то целых гигантских 30kb траффика загрузите, это же огромный минус, который сводит на нет использование интернета как такового. Вот ещё бы вы килобайты не гоняли по сети да? И лишний стакан воды смотрите не выпейте, а то временно обретете плюс 300 грамм огромной массы, это тоже сводит на нет все плюсы от питья воды. Куда не посмотри, везде сплошные огромные минусы.
Это правильно, не стоит 30kb трафика гнать через своего провайдера, это не позволительно.
Какая разница сколько весят этот "прекрасные инструменты"? Если они всё равно не пригодны для адекватного использования.
Ещё раз, посмотрите сколько весит React + React DOM, с вашей "логикой" вы вообще вошли не в ту дверь :D
Во первых реакт весит намного больше чем vanila js, peact, и т.д. и т.п. Во вторых браузер это вообще монстр которой выжирает оперативную память и процессорное время на раз два. В третьих JS намного больше ресурсов потребляет в отличии от СИ. Ну и так далее по списку.
Вам нужно в мир микроконтроллеров, вот там все программы занимают сотни байт, иногда несколько килобайт, особо сложные и огромные занимают десятки килобайт. Процессор там используется по назначению и каждый тик на счету. Там есть прямой доступ к памяти, а ещё там каждый байт этой самой памяти на счету, а не вот это вот всё.
Так смешно конечно))) Перекрывает говорит))) Двигатель в машине кстати знаете сколько весит? Архренеть сколько, ну его нафиг, давайте выкинем. А КПП? Тоже фигня какая, весит много - ОГРОМНЫЙ минус, тоже в топку. Теперь машина весит на пару сотен кг легче, правда больше не ездит, но это не важно, главное мы избавились от ОГРОМНОГО минуса в виде пары килограмм. Вот посмотрите на велосипеды, там вообще вся система весит от силы 1-2 кг и там 24 скорости и двигатель не нужен, педали крути и вперед. Вот идиоты в машины ставят какие-то ДВС тяжелые, КПП какие-то, ещё и автоматические, так они ещё тяжелее, да ещё и кпд у них похуже будет, капец просто, во дают. Более того, они на столько упоротые что ещё какую-то жижу туда заливают, бензин кажется называется, полный бак заливают и ещё +50кг в весу, как там Задорнов то говорил всегда?)
Ахахха, а да?) Ну раз такие критерии, то да, более того у меня ещё в зависимостях react+react-dom которые весят как 3-4 Mobx'a, так что я вообще полный ноль.
Серьезно?)) Огромный минус?)) Я разочарован. Напомните ка сколько там весит react +r eact-dom?) 1kb? Ага) Этот "минус" невероятно притянут за уши, в масштабах проекта. его размер вообще ничего не значит. Тем более благодаря ему, самого по себе кода надо писать гораздо меньше, а это тоже дает экономию в размере тоже, по факту этот "минус" не актуален.
С таким же успехом можно сказать что JS это один сплошной минус, по сравнению с ассемблером или CИ, он намного тяжелее, медленнее, жрет намного больше памяти и т.д. и т.п., давайте все дружно теперь писать на ассемблере, ведь это так удобно и классно))
Поздравляю, это Pub/Sub.
Получается "эффект"
event1реагирует на "атом"event1, и не реагирует на "атом"event2. Прямо как вы и описали.А кто запретил подписаться на
event1только один раз?) Хочешь будет только один callback реагировать на even1, хочешь 10 callback'ов будет реагировать. Хозяин барин.Ага, это седан. Ни в коем случае это не автомобиль, это именно седан. Автомобиль это вообще другое.
Нет, не любое. Если изменение переменной приводит к реакции на это, то это Pub/Sub в базе своей. Вы можете это завернуть в 10 оберток и обозвать белкой, но от этого истинная суть не меняется, есть те, кто подписан на изменения, а есть те, кто оповещают подписчиков об изменениях. Под каким соусом всё это подано, это уже детали реализации, но сам базовый принцип тот же.
В 99.9% случаев автобатчинг(асинхронные реакции) предпочтительней. А для 0.1% опционально можно взводить флаг и реакция будет синхронной, я так и делаю и с MobX'ом (по умолчанию он у меня разумеется сконфигурирован на автобатчинг (асинхронные реакции)) используя это для компонента Input и Textarea, для них нужны именно синхронные реакции, иначе если курсор поставить не в конце текста, то его перебросит в конец во время ввода. У
kr-observableэто как раз и происходит, поэтому нужно добавлять возможность помечать свойство, чтобы на его изменение были синхронные реакции и/или взводить флаг и пока он в true, реакции на все изменения чтобы были синхронные. А так да, автобатчинг в 99.9% случаев более чем полезен и необходим.Какая разница как это называется? Хоть белка. И при чем тут между "атомами" вообще? Если watch смотрит за изменениями, а значит пописан, а значит pub/sub.
А ни кто не говорит, что Pub/Sub в этом случае должен светиться в публичном АПИ, вся суть в другом, что итоговый принцип такой же. Есть подписчики, и есть те, кто уведомляет подписчиков.
Как говорится найди 3 отличия.
Реализация наблюдателя / pub/sub с дополнениями, например в виде введения computed'ов, и спасибо если они хотя бы будут кэшируемые. Разумеется более хитрая, с проверкой на то, было ли реальное изменение или нет и т.д. и т.п.
Но глубинный принцип оповестить об изменениях наблюдателя/подписчика остается неизменным.
Думаю под "атомами" он имел ввиду ряд реализаций,в том числе сигналы(ибо путаница понятий)) И там речь была про "атомы" и сигналы(так же конкретная реализация наблюдателя).
И того, в сухом остатке получается:
1) Реализация наблюдателя реализации наблюдателя рознь, и они могут быть прям как небо и земля.
2) Все сравнения в данном контексте на самом деле именно реализаций наблюдателя, даже когда люди их пытаются называть как отдельные вещи, аля атомы или сигналы, потому что по сути всё это и есть наблюдатель (mobx, redux, effector, signals и т.д. и т.п.).
Наверное потому что многие люди уже запутались, где названия реальных паттернов, а где выдуманных, которые являются реализациями)
Оно и понятно, по наплодили всякой фигни, которая является один и тем же и называют по разному с умным видом)
Типо нет, это не чайный гриб, это камбуча)) Или нет, это не прыщ, это акнэ))
Нет такого понятия(в мире программирования) как атом, атомов-обсёрваблов и т.п. Это просто люди сами обозвали свои реализации атомами.
В свою очередь всё это фактически реализации Observer / Publisher-Subscriber, просто они решили не говорить pub/sub а решили сказать что это атом, с таким же успехом можно было сказать это белка, и потом кто-то бы спрашивал, а чем белка отличается от наблюдателя.
Вот смотрите, есть седан, есть хэчбэк, есть внедорожник, есть "джип", и т.д. и т.п., и всё это автомобиль. Нельзя сравнивать автомобиль и седан, или автомобиль и внедорожник. Ибо это одно и то же, просто детали реализации иные. Вот сравнить седан и хэчбэк можно, т.к. тут идёт сравнение именно деталей реализации автомобиля, а не автомобиля как такового.
Касаемо MobX и kr-observable:
Это просто реализация паттерна Наблюдатель (Publisher/Subscriber) с использованием возможностей языка JS (getters/setters), которые и позволяют тот самый неявный механизм подписок и уведомления об изменениях. А не какие-то особенные
атомов-обсёрваблов.Observer это реально существующий паттерн.
Atom - нет.
В этом принципиальная разница)
Всё это, в том числе так называемый "атом" это реализации Observer, разной степени паршивости.
Observer в свою очередь это просто самый банальный Publisher/Subscriber.
С таким же успехом вы можете говорить, что вы пьете камбуча, но по сути вы просто пьете чайный гриб. Просто в первом случае это звучит по прикольнее, а чайный гриб звучит как то не очень.
Иными словами, вообще не стоить придавать значения этим словам и терминам. Главное понимать суть. Реактивное(это когда мы любым образом реагируем на что-то, и любым образом провоцируем те самые реакции. Не надо вкладывать в это слово что-то эдакое сложное) состояние(у него 100500 реализаций) это всегда Publisher/Subscriber по принципу работы. Subscriber в случае с реактом это компонент(а точнее его
forceUpdateфункция), а Publisher это любое проявление уведомления Subscriber'a, о том, что ему надо выполнится. В случае стейт менеджмента это триггерforceUpdateфункции компонента после изменения данных, которые в нем используются, например увеличения счетчика.Ему не нравится их реализация, мне впрочем тоже. Посмотрите на код который нужно писать и всё сразу станет понятно. В этом и есть вся суть. В одном случае ты не делаешь лишних телодвижений и не нагружаешь код лишним мусором, в другом случае делаешь и нагружаешь.
"атомы" в данном контексте (я про программирование, а не про настоящие атомы) это крайне размытое понятие, и каждый трактует его и имплементирует как хочет. Поэтому тут не может быть сравнения лоб в лоб. Но вы можете посмотреть на то, какой код нужно писать используя так называемые "атомы" в различных реализациях и на код, который нужно писать используя то, что предлагает автор. Ну или можете посмотреть на MobX, по сути это тот же самый принцип, но подкапотная реализация иная.
Observable это тоже общее понятия, но его реализации могут быть принципиально разными, в одном случае это может быть MobX, в другом вот это:
С ручными подписками, отписками и испусканием событий. Вот и сравните их, и то и то как бы является Observable, но если сравнить их лоб в лоб, то это небо и земля в плане удобства использования в качестве управления состоянием.
В случае с MobX или
kr-observableкод остается максимально нативным, хотите увеличить счетчик? Пожалуйстаthis.counter++илиsomeState.counter++. Хотите изменить значение флага? Пожалуйстаthis.opened = trueилиsomeState.opened = true.Главное всё это можно делать из любого места и в любой момент.
А с чего вы взяли что эти самые дядьки говорят правильные вещи? С умным видом можно задвигать что земля плоская и т.д. и т.п. и что теперь, верить на слово каждому такому дядьке что ли?
Умный человек отличается тем, что у него прежде всего критическое мышление, т.е. он не опирается на "авторитеты", а прежде всего сам думает своей головой, сам проверяет те или иные вещи. Если дядька говорит делать вот так, это хорошо, а ты понимаешь что че-то он несет какую то чушь, то с вероятностью >99% он и правда несет чушь. Даже если эту чушь будут поддерживать многие люди, не обладающие критическим мышлением разумеется.
Опять же, далеко за реальными примерами ходить не надо - плоскоземельщики, антиваксеры и т.д. и т.п.
Как показывает практика, примерно 99.9% из этих "разработчиков" пишут в итоге жесточайший, неподдерживаемый write-only говнокод.
Именно. Причем это настолько очевидно, что даже странно, откуда у некоторых(слава яйцам не у всех) людей берется тягота превращать простые вещи в очень сложные. Это же настолько нелепо, что порой просто смешно.
KISS и YAGNI во главе всего - единственный путь к реально хорошему коду и реально хорошей архитектуре. Где ты не будешь бороться с тем, что ты наплодил, а просто будешь решать конкретные задачи.
А ещё есть вакансии с упоминанием Angular2, ExtJs и прочими "замечательными" технологиями. Занимайтесь.
Да, это прям мечта, так классно и просто поддерживать, прямо загляденье. Вот мы идиоты то, мучаемся, используем scss/css, и пишем ужасные display, padding, font-size и т.п. Бррр, аж кровь из глаз течет от этих ужасных свойств. Ох, а если миксин заюзать, ууу тогда пиши пропало вообще.
Целиком делать проект нет смысла, да и сравнивать скорость нет смысла, ибо ctrl+c / ctrl-v из фигмы всегда быстрее.
или fz + tab + 16px =
font-size: 16px;как минимум не уступает сокращениям из tailwind.Просто повторите аналогичный стиль для кнопки, где
@include typography('Text Thin_14');пусть будет
@include typography('Text Regular_16', '#fff');пусть будет