На самом деле исследовал этот вопрос еще со времен Angular RC. Не нашел хороших wrappers для Mobx. Самый популярный, что есть (mobx-angular) увы имеет свои проблемы https://github.com/mobxjs/mobx-angular/issues/38 и это только 1 пример (проблем на самом деле больше если капнуть)
Mobx очень крут, но у меня лично так и не хватило времени написать свой wrapper :/
К сожалению, даже если ты знаешь об этом, это все равно работает :)
Как это проверить? Посмотрите на The Coyote Illusion из секции «Обманывайте», главный элемент этой иллюзии скорости Motion Blur. Это все связанно с таким интересным эффектом как Chronostasis (это я не про мангу). Есть очень много интересных научных исследований о том как человек (довольно часто) ошибается с оценкой времени.
Время для человека — величина эмоциональная.
Ну а про популярность данных методик и говорить особо не стоит. Все онлайн игры используют Latency Compensation (Optimistic Updates). Twitter один из ярких представителей вебсайтов который использует эту технику. Про скелетоны вообще молчу. И поверьте почти за каждым из таких внедрений стоят исследования, а не слепое — давайте воткнем. Поэтому и писал что прежде чем это все внедрять стоит проверить полезность на вашем конкретном сайте. Слава богу с сервисами вроде Яндекс.Толока это не так дорого и сложно.
Извучал анимацию (как правилно рисовать мультики). Так вот есть 1 интересный принцип. Чем плавнее и медленней анимация движения, тем больше кадров должно быть чтобы анимация выглядела «естественно». Соответственно, чем медленней анимация UI тем быстрее его отрисовка должна быть (больше FPS), к сожалению KDE этим не славилась (в свое время), что приводило к тому что помимо обычных проблем с производительнотью — долгая, плавная анимация делала этот UI неестественным.
Для себя сделал правило не делать долгих transiton особенно в высоконагруженных приложениях
Хорошее замечание! Но все зависит от того какое действие вы делаете на mousedown. Если переход на страницу то да — будет полных треш.
Но я говорю немного о другом. На mousedown вы можете начать скачивать ресурсы следующей страницы, предзагружать контент, в общем выполнять любую подготовительную работу и только после события click — «визуально» выполнять действие (выполнять переход, обрисовывать элементы)
PS: но с общим посылом не спорю, добавлю замечание в статью
Давайте попробуем рассмотреть контрпример. Представьте что спинер крутиться бесконечно и лишь через 10 минут открыв консоль вы видите, что ошибку не обработали. Я не буду рассказывать сколько раз я этот пример видел в реальной жизни.
Я могу быть не прав, но мне кажется вас бесит не skeleton или optimistic updates, а просто криворукие сайты написанные на коленке :)
Да, это вариант. Проблема в том что изменения могут накладываться друг на друга. К примеру я заменяю const на var а потом удаляю эту строчку (пример глупый но все-же). Так-что сортировка в данном случае подходит лишь для некоторых сценариев.
MagicString сам запомнить смешение и после выполнения каждого из операторов обновить индексы для других операторов. Вам об этом не нужно думать, если вы используете MagicString. В этом и их плюс :)
Да — MagicString тоже нужно AST. Прирост производительности они дают за счет отсутствия необходимости использовать трансформеры.
Как уже говорил мы можем поменять данные только в одном узле, но как только мы обратно конвертируем AST -> text у нас возможны 2 варианты:
1) Конвертор AST -> text использует при сериализации start, end индексы. В этом случае у нас будут лишние пробелы (как на примере из статьи)
2) Конвертор AST -> text игнорирует start, end индексы. Весь текст будет переформатирован. В результате diff для данного изменения будет длинной в сам файл, хотя мы изменили 2 строчки.
Плюс есть еще ряд других проблем связанных с повторным проходом по тому-же AST. К примеру. Что если мы сначало заменили один узел и проигнорировали сотальные а потом ищем узел который начинается на нужном индексе? Индексы же не валидные :/
Так что пока трансформации простые. Все хорошо. Но как только делаем что-то более или менее сложное — трансформаторам придется обновлять эти несчастные координаты. Без этого увы не получиться.
Помимо популяризации Angular в России у меня была еще 1 цель. Создание универсального, автоматизированного переводчика Markdown документов. Об этом следующие статьи — одна из них уже вышла :) habr.com/ru/post/502760
На самом деле исследовал этот вопрос еще со времен Angular RC. Не нашел хороших wrappers для Mobx. Самый популярный, что есть (mobx-angular) увы имеет свои проблемы https://github.com/mobxjs/mobx-angular/issues/38 и это только 1 пример (проблем на самом деле больше если капнуть)
Mobx очень крут, но у меня лично так и не хватило времени написать свой wrapper :/
Но судя по описанию всё-таки больше для backend и на клиенте (JS) им будет воспользоваться проблематично :/
Как это проверить? Посмотрите на The Coyote Illusion из секции «Обманывайте», главный элемент этой иллюзии скорости Motion Blur. Это все связанно с таким интересным эффектом как Chronostasis (это я не про мангу). Есть очень много интересных научных исследований о том как человек (довольно часто) ошибается с оценкой времени.
Время для человека — величина эмоциональная.
Ну а про популярность данных методик и говорить особо не стоит. Все онлайн игры используют Latency Compensation (Optimistic Updates). Twitter один из ярких представителей вебсайтов который использует эту технику. Про скелетоны вообще молчу. И поверьте почти за каждым из таких внедрений стоят исследования, а не слепое — давайте воткнем. Поэтому и писал что прежде чем это все внедрять стоит проверить полезность на вашем конкретном сайте. Слава богу с сервисами вроде Яндекс.Толока это не так дорого и сложно.
Для себя сделал правило не делать долгих transiton особенно в высоконагруженных приложениях
Но я говорю немного о другом. На mousedown вы можете начать скачивать ресурсы следующей страницы, предзагружать контент, в общем выполнять любую подготовительную работу и только после события click — «визуально» выполнять действие (выполнять переход, обрисовывать элементы)
PS: но с общим посылом не спорю, добавлю замечание в статью
Я могу быть не прав, но мне кажется вас бесит не skeleton или optimistic updates, а просто криворукие сайты написанные на коленке :)
«Дайте сойти человеку с баяном!» :)
Как уже говорил мы можем поменять данные только в одном узле, но как только мы обратно конвертируем AST -> text у нас возможны 2 варианты:
1) Конвертор AST -> text использует при сериализации start, end индексы. В этом случае у нас будут лишние пробелы (как на примере из статьи)
2) Конвертор AST -> text игнорирует start, end индексы. Весь текст будет переформатирован. В результате diff для данного изменения будет длинной в сам файл, хотя мы изменили 2 строчки.
Плюс есть еще ряд других проблем связанных с повторным проходом по тому-же AST. К примеру. Что если мы сначало заменили один узел и проигнорировали сотальные а потом ищем узел который начинается на нужном индексе? Индексы же не валидные :/
Так что пока трансформации простые. Все хорошо. Но как только делаем что-то более или менее сложное — трансформаторам придется обновлять эти несчастные координаты. Без этого увы не получиться.
Но надеюсь несмотря на то что тут используется JS он вам тоже пригодится. А какой язык вам «родной»?
Просто хотел сказать что WebStorm нет особой необходимости искать и ставить плагины.
PS: сам предпочитаю VSCode. Легче работать с большим кол-вом проектов (5-10 одновременно открытых проектов между которыми постоянно переключаюсь)