Любопытно, что статья называется «Способы отладки JS на клиенте», а второй абзац уже начинается с «мы видим исходный JSX», вторая часть статьи называется «Отладка внутри IDE WebStorm».
Так что из первой части получаем, что отлаживаем не совсем JS, а из второй, что не совсем на клиенте.
Gemini — обеспечивает визуальную регрессию в сравнении с предыдущими итерациями. Нам важно было иметь представление, насколько верстка соответствует первоначальному дизайну. А сравнивать с макетами автоматически почти невозможно: радикально будут отличаться рендеринг шрифтов, например.
А вообще, Gemini — отличный инструмент. Реконмендовал его в этом комментарии.
Мы иногда практикуем состояния без приложенных скриншотов. Тогда можно просто посмотреть глазами, нормально ли выглядит блок. Есть и второй способ: можно не сохранять отдельное состояние, а в каком-то другом подергать ползунок и поменять ширину.
Для https://2gis.ru, например, используются свой javascript-фреймворк Slot. В нем шаблоны рендерятся с помощью handlebars.
В этом случае, сохраненный кейс блока — это объект, в котором хранятся тестовые данные, по которым блок отрендерится в нужном состоянии. Этот объект при необходимости расширен дополнительными полями, которые позволяют отрисовать блок вне его окружения, добавить изображение для сравнения и т. д.
Эти же данные мы используем в тестах, когда нам нужно прогнать интеграционный тест для одного изолированного блока.
На уровне файловой системы, такие данные хранятся вместе с блоком, и поддерживаются по мере изменения требований или дизайна.
Для других фреймворков система аналогичная. Для React, к примеру, это может быть props для компонента.
Тут есть элементы именно того тестирования, о котором вы говорите. Поскольку Мейкап — веб-приложение, его можно открывать в разных браузерах и на разных ОС. Разница в том, что можно не приводить большое и сложное приложение в определенное состояние, которое вы хотите проверить, а сразу отрендерить блок в нужном состоянии. Соответственно, задача регрессии вёрстки блока — просто прокликать все готовые, заранее сохраненные кейсы.
Кажется, что используя БЭМ, у вас получилось бы комфортнее вести сам рефакторинг. Заменять отдельные компоненты проекта без ущерба для работоспособности проекта. И так по блокам постепенно победить весь проект.
Стабильность проекта в любом случае требует трудозатрат. Экономия времени на таких вещах может легко превратить в краткосрочной перспективе разработку в ад. Нам хочется быть в любую минуту уверенными в качестве продукта.
Тем более, такой подход быстро становится привычкой, и не занимает слишком много времени.
Мне всегда нравилась метафора с машинами. Во многих предложениях если заменить «сайт» на «автомобиль», особенности разработки сразу становятся понятны всем.
— Сколько стоит автомобиль?
— Какие задачи должен выполнять автомобиль?
— Автомобили бывают разные. Для некоторых задач нужен фургон, а для некоторых гоночный болид.
Любопытно, что статья называется «Способы отладки JS на клиенте», а второй абзац уже начинается с «мы видим исходный JSX», вторая часть статьи называется «Отладка внутри IDE WebStorm».
Так что из первой части получаем, что отлаживаем не совсем JS, а из второй, что не совсем на клиенте.
Да, очень бы хотелось скриншот, демо, сравнение с конкурентами (например, Styleguidist или SourceJS).
Кажется, в комментариях слишком мало странных вариантов c очень ограниченной функциональностью, написанных с использованием JS.
А вообще, Gemini — отличный инструмент. Реконмендовал его в этом комментарии.
Мы иногда практикуем состояния без приложенных скриншотов. Тогда можно просто посмотреть глазами, нормально ли выглядит блок. Есть и второй способ: можно не сохранять отдельное состояние, а в каком-то другом подергать ползунок и поменять ширину.
В этом случае, сохраненный кейс блока — это объект, в котором хранятся тестовые данные, по которым блок отрендерится в нужном состоянии. Этот объект при необходимости расширен дополнительными полями, которые позволяют отрисовать блок вне его окружения, добавить изображение для сравнения и т. д.
Эти же данные мы используем в тестах, когда нам нужно прогнать интеграционный тест для одного изолированного блока.
На уровне файловой системы, такие данные хранятся вместе с блоком, и поддерживаются по мере изменения требований или дизайна.
Для других фреймворков система аналогичная. Для React, к примеру, это может быть props для компонента.
То есть для того, чтобы посмотреть на блок в разных браузерах нужно запустить Мейкап в разных браузерах и посмотреть блок во всех интересующих кейсах.
Для мобильных браузеров это возможно, но не так удобно, как в случае с большими экранами.
Тем более, такой подход быстро становится привычкой, и не занимает слишком много времени.
— Сколько стоит автомобиль?
— Какие задачи должен выполнять автомобиль?
— Автомобили бывают разные. Для некоторых задач нужен фургон, а для некоторых гоночный болид.
Чертовски просто.