Недавно вышел FSD 2.1, который гласит о том, что если в проекте код из entity нигде не нужен, то его можно (скорее "следует" лучше подходит) переместить в features, если из features больше нигде не нужен - в widgets, ну и если и не в widgets, то в pages. Также в FSD 2.1 есть предложения о декомпозиции не только по бизнес-смыслу, но и по инфраструктуре.
Если рассматривать "pages-first" подход, то Вы можете разрабатывать фичи приложения не с точки зрения того, как лучше разделить это на слои, слайсы и сегменты, а как проще собрать целую страницу или модуль, и выносить уже общий код.
Что касается переименования слоёв и желания распространения это на методологию - всегда можно предложить это к обсуждению, например на том же гитхабе.
Как идея весьма неплохо, особенно поразбираться с инструментами для обработки изображений.
В статье не увидел ни одного аналога, с которым можно было бы сравнить. А сравнить есть с чем, например со Squoosh, или другими существующими решениями.
Попробовал посжимать изображения с Вашим сервисом и со Squoosh, и опытным путём получилось, что качество при сжатии равно примерно 70%. Для примера брал изображения с Unsplash (очень похожий медведь, фото ночного города, фото острова).
Если сравнивать функционал, то у Вас можно выбрать только факт того, нужен ли WebP, в то время как в сравниваемом мной сервисе можно:
изменить размер;
уменьшить цветовую палитру;
выбрать итоговый формат;
настроить параметры сжатия;
сравнить оба изображения.
Плюсом ко всему, Squoosh можно установить как PWA и пользоваться им в офлайн-режиме.
Минусы также имеются - невозможность обработки больше одного изображения за раз; тяжелые изображения могут и не сжаться - всё происходит на устройстве пользователя, что для меня является более существенным, т.к. всё это исполняется в браузере.
Что касается Вашего проекта, то возможно стоит задуматься об аналогах sharp, дать возможность пользователю настройки параметров сжатия, поправить UX (например: контрастность цветов в D&D-области; сама D&D область не на весь экран; в центральной области поведение отличается в зависимости от того, выбраны ли файлы).
С версии Хрома 130 появится фича - Keyboard focusable scrollers. С версии Хрома 127 фича находится в экспериментальной стадии и можно попробовать включив соответствующий флаг (keyboard-focusable-scrollers). Это всё к тому, что для определенных случаев поведение изменится, и его надо будет либо обходить, либо использовать.
Это также повлияет на Ваш пример, если в подобной реализации внутри карточек появится блок со скроллом.
Недавно вышел FSD 2.1, который гласит о том, что если в проекте код из entity нигде не нужен, то его можно (скорее "следует" лучше подходит) переместить в features, если из features больше нигде не нужен - в widgets, ну и если и не в widgets, то в pages. Также в FSD 2.1 есть предложения о декомпозиции не только по бизнес-смыслу, но и по инфраструктуре.
Если рассматривать "pages-first" подход, то Вы можете разрабатывать фичи приложения не с точки зрения того, как лучше разделить это на слои, слайсы и сегменты, а как проще собрать целую страницу или модуль, и выносить уже общий код.
Что касается переименования слоёв и желания распространения это на методологию - всегда можно предложить это к обсуждению, например на том же гитхабе.
Подскажите, какая версия TypeScript'а рассматривается в книге?
Как идея весьма неплохо, особенно поразбираться с инструментами для обработки изображений.
В статье не увидел ни одного аналога, с которым можно было бы сравнить. А сравнить есть с чем, например со Squoosh, или другими существующими решениями.
Попробовал посжимать изображения с Вашим сервисом и со Squoosh, и опытным путём получилось, что качество при сжатии равно примерно 70%. Для примера брал изображения с Unsplash (очень похожий медведь, фото ночного города, фото острова).
Если сравнивать функционал, то у Вас можно выбрать только факт того, нужен ли WebP, в то время как в сравниваемом мной сервисе можно:
изменить размер;
уменьшить цветовую палитру;
выбрать итоговый формат;
настроить параметры сжатия;
сравнить оба изображения.
Плюсом ко всему, Squoosh можно установить как PWA и пользоваться им в офлайн-режиме.
Минусы также имеются - невозможность обработки больше одного изображения за раз; тяжелые изображения могут и не сжаться - всё происходит на устройстве пользователя, что для меня является более существенным, т.к. всё это исполняется в браузере.
Что касается Вашего проекта, то возможно стоит задуматься об аналогах sharp, дать возможность пользователю настройки параметров сжатия, поправить UX (например: контрастность цветов в D&D-области; сама D&D область не на весь экран; в центральной области поведение отличается в зависимости от того, выбраны ли файлы).
С версии Хрома 130 появится фича - Keyboard focusable scrollers. С версии Хрома 127 фича находится в экспериментальной стадии и можно попробовать включив соответствующий флаг (keyboard-focusable-scrollers). Это всё к тому, что для определенных случаев поведение изменится, и его надо будет либо обходить, либо использовать.
Это также повлияет на Ваш пример, если в подобной реализации внутри карточек появится блок со скроллом.
Можете посмотреть на Type Branding/Flavoring.
Ожидать ли итоги года Хабр Q&A? Вроде с 2019 тишина?