Я рассмотрел тот случай, что приведён в статье. Я мог бы выложить портянку по поддержке, например, flexbox всех спецификаций. Разные браузеры поддерживают разные синтаксисы. То есть одной только расстановкой префиксов тут не обойтись. Я посмотрел код autoprefixer (https://github.com/postcss/autoprefixer-core/tree/master/lib/hacks) и не нашёл там, например, упоминания box-lines, который выполнял роль flex-wrap.
Да, клонирование правил с модификацией значений в stylus выглядит уже не так красиво, как хотелось бы. Но и в нём есть js-api позволяющее расширять его функционал, модифицируя ACT плагинами.
Попрошу без голословных обвинений. Когда вдруг потребуется отказаться от поддержки одного из устаревших браузеров я зайду в файл fallback.styl и удалю ненужные правила. Это не такая уж и частая или сложная процедура. А вот дополнительное последовательное звено в процессе сборки — это плохо. У нас и так весь css собирается 5 секунд, что мучительно долго, когда занимаешься вёрсткой.
Как бы нам, разработчикам, ни хотелось, но с точки зрения бизнеса, отказ от поддержки одних версий браузеров браузеров никак не коррелирует с появлением новых. А процент использования по данным «Can I Use» никак не коррелирует с процентом использования того же браузера на конкретном сайте.
Ну так UI использует обёртку над API (модель), которая кэширует и буферизирует запросы и инвалидирует кэш, когда данные меняются. И чтобы всё это отражалось на UI обёртка тоже должна быть реактивной.
Тогда у нас получится что на каждый чих у нас будет обновляться всё приложение, что гораздо хуже.
Конечно, выводим список на 2000 элементов с фильтрацией по какому-либо параметру — получаем одну зависимость от самого списка и 2000 зависимостей от соответствующего параметра каждого из элементов. При изменении параметра у любого из элементов список перефильтруется. Это может показаться расточительным, ведь можно просто проверить подходит изменившийся элемент под фильтр и либо добавить, либо удалить. Но когда к фильтрации добавляется сортировка, группировка, да ещё и иерархия с разворачиванием ветвей и дублированием узлов, то задача «поместить в нужное место списка» становится неоправданно сложной.
Я бы не разделял эти две категории. В любой соц сети есть навигация, чаты под каждым котиком, отображение лайков в реальном времени, куча разнообразных кнопочек: пожаловаться, удалить из ленты, восстановить, приглушить свет на всём сайте, кроме этой фоточки и тд и тп. И это всё состояния. А кэш — это лишь частный случай состояния, которое может очищаться, когда ничего зависимого от него не отображается на экране.
Он будет помечен как «не актуальный», а значит при обращении актуализирует своё значение на основе B и C. Тут есть более сложный случай: D зависит от А, А только что запланировал к обновиться, а значит D ещё не знает, что ему тоже потребуется обновление (а может и не потребуется, А-то ещё не вычислился). Поэтому, если мы тут же обратимся к D, то получим старое значение, которое вскоре возможно(!) изменится.
Нет, в момент линковки ведомый спрашивает у ведущего его глубину и сравнивает со своей.Если своя глубина не больше глубины ведущего, то устанавливается на 1 больше, чем у него. А при помещении в очередь атом ставится в очередь соответствующей своей глубине на момент помещения.
Видимо я плохо осветил этот момент. Глубина может измениться и как правило это делает, но это не важно, пока атом не помещается в очередь на обновление. А он туда не помещается, поскольку только что актуализировал своё состояние. И все атомы меньшей глубины тоже его актуализировали. Так что следующий атом в очереди может смело вычислять своё значение и быть уверенным, что атомы с меньшей глубиной не изменятся, если он конечно сам не полезет их зачем-то менять.
По моему опыту «просто получить данные» — достаточно редкий случай. Обычно надо не просто получить, но и закешировать. А если закешировали, то и вовремя инвалидировать кэш, а потом снова грузить. Так что обещания использовать нет никакого смысла, если есть возможность использовать атомы.
1. Атом — обобщение над обещаниями, так что ничто не мешает ему поддерживать их интерфейс. Для интеграции с императивным кодом это действительно удобно.
2. Атом абстрагирует от асинхронщины, позволяя в любой момент прервать вычисление не потеряв проделанной работы, а потом продолжить, когда нужные данные появятся, не начиная всё с начала.
Да, клонирование правил с модификацией значений в stylus выглядит уже не так красиво, как хотелось бы. Но и в нём есть js-api позволяющее расширять его функционал, модифицируя ACT плагинами.
Как бы нам, разработчикам, ни хотелось, но с точки зрения бизнеса, отказ от поддержки одних версий браузеров браузеров никак не коррелирует с появлением новых. А процент использования по данным «Can I Use» никак не коррелирует с процентом использования того же браузера на конкретном сайте.
my-box.styl
И незачем выбирать между пре- и постпроцессорами. Толковый препроцессор имеет куда больше возможностей.
Конечно, выводим список на 2000 элементов с фильтрацией по какому-либо параметру — получаем одну зависимость от самого списка и 2000 зависимостей от соответствующего параметра каждого из элементов. При изменении параметра у любого из элементов список перефильтруется. Это может показаться расточительным, ведь можно просто проверить подходит изменившийся элемент под фильтр и либо добавить, либо удалить. Но когда к фильтрации добавляется сортировка, группировка, да ещё и иерархия с разворачиванием ветвей и дублированием узлов, то задача «поместить в нужное место списка» становится неоправданно сложной.
2. Атом абстрагирует от асинхронщины, позволяя в любой момент прервать вычисление не потеряв проделанной работы, а потом продолжить, когда нужные данные появятся, не начиная всё с начала.