Defront — про фронтенд-разработку и не только
19.9K subscribers
21 photos
1.09K links
Ламповый канал про фронтенд и не только. Всё самое полезное для опытных web-разработчиков

Обсуждение постов @defrontchat

Также советую канал @webnya
Download Telegram
Фред Шот — автор библиотеки pika — опубликовал статью с рекомендациями по настройке bundler-free окружения для разработки современных web-приложений — "Building without bundling: How to do more with less".

Может возникнуть резонный вопрос: "Зачем избавляться от бандлера?". В начале статьи Фред подсчитывает количество времени, которое отнимает у разработчиков сборка проекта. Для больших проектов, которые запускаются за 42 секунды и пересобираются за 11 секунд, время ожидания может занимать более часа (для 40-часовой рабочей недели).

Если вы используете у себя в проекте модульную систему из ES2015, сборка проекта необязательна, так как все современные браузеры уже поддерживают модульность в JS. Проблема остаётся с node_modules, которые могут содержать спецификаторы, которые браузер не сможет разрезолвить, или с node-специфичным кодом, например, process.env.NODE_ENV. Для решения этих проблем Фред предлагает использовать его библиотеку pika, которая преобразует код из node_modules в esm-бандлы. По сравнению с традиционными бандлерами у такого подхода есть преимущество — это преобразование надо запустить только один раз после npm install. Для работы с JSX предлагается использовать библиотеку htm.

Описанный в статье подход — это возврат к той простоте, с которого начинался web. Очень рекомендую прочитать статью, если у вас большое приложение, которое собирается долго и вы хотите что-то с этим сделать.

#bundler #web #dx

https://blog.logrocket.com/building-without-bundling/
Михай Парпарита из Quip написал статью про то, как они отлаживают своё приложение — "How Quip Builds In-Product Debugging Tools".

Основная мысль статьи — стоит немного потрудиться и сделать инструмент, который будет помогать в отладке. Такая инвестиция времени быстро возместится в будущем.

Quip использует много подобных инструментов. Например, для визуализации взаимосвязи уровня данных и представления у них есть "Overlay Id", который для каждого компонента показывает соответствующие данные модели. Есть инструмент для отладки редактора, который в инлайн-режиме отображает отладочную информацию об отображаемых сущностях. Такой подход исключает затраты времени на открытие инструментов разработчика и потерю фокуса из редактора. Есть небольшой инструмент, который показывает в оверлее количество ререндеров компонента. Реализуется он так: в каждый компонент инжектится componentDidUpdate, который увеличивает счётчик и записывает его в data-атрибут. Значение атрибута отображается поверх компонента с помощью CSS:
.debug-react-rerender-count:after {
content: attr(data-debug-react-rerender-count);
// other styles for positioning and color
}


Мне статья понравилась. В ней есть интересные идеи, которые можно применить в своём проекте.

#dx #debug

https://quip.com/blog/how-quip-builds-inproduct-debugging-tools
Интерграция VS Code с Edge DevTools

Разработчики Edge рассказали о новой экспериментальной фиче для подключения VS Code в качестве основного редактора DevTools — "Opening source files in Visual Studio Code".

Если включить интеграцию с VS Code, то при открытии исходного кода проекта в инструментах разработчика между экземпляром редактора и DevTools установится двусторонняя связь. При редактировании файлов в VS Code изменения не только будут сохраняться на диск, но и будут автоматически пробрасываться в DevTools с автоматическим обновлением открытой страницы. И, наоборот, при редактировании стилей на вкладке Elements все изменения будут автоматически пробрасываться в редактор.

Подключить VS Code можно в экспериментальных опциях DevTools: Settings > Experiments > Open source files in Visual Studio Code.

#tool #dx #edge

https://docs.microsoft.com/en-us/microsoft-edge/devtools-guide-chromium/sources/opening-sources-in-vscode