Интересный подход. Мне интересно еще вот что: судя под всему, проект, на основе которого вы сделали такие выводы
Всего 12 файлов для одной кнопки! В мире микросервисов это выглядело бы как правка пяти разных репозиториев, чтобы поменять цвет лейбла. И тогда я задался вопросом: «Почему фронтенд, при всей своей прогрессивности, до сих пор не усвоил уроки распределённых систем?»
Это не что иное, как просто криво написанный код, без учета того, что в будущем он может меняться, адаптироваться и быть готовым к модификации (это уже вопрос к принципам ООП, которые не были соблюдены). И тут тогда проблема не в том, что фронт не учел уроки, а что проект был изначально написан криво.
В Angular-компонентах застряли пережитки эры империй:
Жёсткая иерархия вызовов
Сервисы как ESB-монстры
События через 5 уровней — как бюрократическая почта
Понимаю, что речь про Angular, но в том же React можно было бы обойтись как Redux (как поминали выше), так и Context.
Мои слова не отменяют смысл статьи и ее подход, просто как будто аргументация проблемы выстроена слабовато.
Спасибо за статью. Да, действительно придется поменять пример, однако в статье сказано, что если явно устанавливать tab index -1, то фокусироваться не будет. В моем же примере надо поменять селектор, который делает элементы внутри карточек нефокусируемыми
Согласен, с ним много проблем, и, кажется, то, в каком виде он реализуется сейчас на многих сайтах - вариант точно не из лучших, другой момент, что у нас также есть желания бизнеса. И тут уж либо переубеждать, либо реализовывать, стараясь сделать продуманно в том числе с точки зрения веб-доступности.
Хорошее замечание, но как быть тем, кто, например, «путешествует» по сайту с помощью клавиатуры? Одно дело, когда у нас все элементы в поле зрения, но от того, что мы зададим фиксированные размеры контейнеру ленты, фокусироемость на дочерних элементах внутри не пропадет, и мы вновь упремся в ситуацию, когда будем в бесконечном скролле
Действительно, устоявшийся HTTP Cache кэширует сайты, однако есть ключевые различия:
1) Cache API, в отличие от HTTP Cache, действительно не очищается пользователем и дает ему меньшем контроля, но это также дает некоторое преимущество - мы точно уверены, что закэшированные ресурсы останутся на устройстве пользователя, а значит время жизни Cache Storage больше. Тут и плюс, и минус. В зависимости от наших задач.
2) Более высокая гибкость при нестабильных сетях или автономном режиме: работа HTTP Cache предлагает только два режиме - либо ресурс кэшируется, либо нет. С помощью же Cache Storage мы можем настраивать различные стартегии кэширования, более того, мы можем, в сочетании с SW достичь полностью автономной работы приложения.
Опять же, решение использовать Cache API - не панацея. Нужно понимать, нужен ли он точно на проекте или же проще обойтись обычным HTTP Cache.
Согласен, здесь действительно лучше было бы повесить в sw обработчик на событие fetch и уже там решать - что кэшировать, а что нет. Просто хотелось скорее показать, что такое CacheAPI и продемонстрировать принцип его работы.
Под капотом Vue, как и React, использует модель виртуального DOM (VDOM). Она создает абстракцию в виде объекта представления иерархии компонентов для их сравнивания. Однако это разные концепции.
VDOM согласует изменения для оптимизированного рендеринга и вставляет их в DOM, в то время как Shadow DOM скорее позволяет включать поддерево элементов DOM в рендеринг, но не в основное DOM. Хотя соглашусь, что концепции похожи. Так же есть слоты, компоненты и т.д.
В данном случае речь идет не о фреймворке, а о нативной реализации веб-компонентов через Shadow DOM, но, чтобы он окончательно заработал, необходимо дописать код на JavaScript. Что касается отображения в вашем случае, вот пример с рабочим кодом: codepen.io/sldo/pen/ExNMXEV. Браузер отображает текст, но необходимо дописывать JS для полноценной реализации.
Интересный подход. Мне интересно еще вот что: судя под всему, проект, на основе которого вы сделали такие выводы
Это не что иное, как просто криво написанный код, без учета того, что в будущем он может меняться, адаптироваться и быть готовым к модификации (это уже вопрос к принципам ООП, которые не были соблюдены). И тут тогда проблема не в том, что фронт не учел уроки, а что проект был изначально написан криво.
Понимаю, что речь про Angular, но в том же React можно было бы обойтись как Redux (как поминали выше), так и Context.
Мои слова не отменяют смысл статьи и ее подход, просто как будто аргументация проблемы выстроена слабовато.
Спасибо за статью. Да, действительно придется поменять пример, однако в статье сказано, что если явно устанавливать tab index -1, то фокусироваться не будет. В моем же примере надо поменять селектор, который делает элементы внутри карточек нефокусируемыми
Согласен, с ним много проблем, и, кажется, то, в каком виде он реализуется сейчас на многих сайтах - вариант точно не из лучших, другой момент, что у нас также есть желания бизнеса. И тут уж либо переубеждать, либо реализовывать, стараясь сделать продуманно в том числе с точки зрения веб-доступности.
Хорошее замечание, но как быть тем, кто, например, «путешествует» по сайту с помощью клавиатуры? Одно дело, когда у нас все элементы в поле зрения, но от того, что мы зададим фиксированные размеры контейнеру ленты, фокусироемость на дочерних элементах внутри не пропадет, и мы вновь упремся в ситуацию, когда будем в бесконечном скролле
Ниже andreymal отписал по изменениям) Я смотрел в новом Firefox, видимо, в старых версиях действительно не работает
Запустил пример локально, не через Codesandbox - все работает. Предполагаю, что есть какие-то политики, огранчивающие работу
Хм, странно, нашел информацию о 5 Мб тут и тут:
https://web.dev/articles/storage-for-the-web
https://developer.mozilla.org/en-US/docs/Web/API/Storage_API/Storage_quotas_and_eviction_criteria
Действительно, устоявшийся HTTP Cache кэширует сайты, однако есть ключевые различия:
1) Cache API, в отличие от HTTP Cache, действительно не очищается пользователем и дает ему меньшем контроля, но это также дает некоторое преимущество - мы точно уверены, что закэшированные ресурсы останутся на устройстве пользователя, а значит время жизни Cache Storage больше. Тут и плюс, и минус. В зависимости от наших задач.
2) Более высокая гибкость при нестабильных сетях или автономном режиме: работа HTTP Cache предлагает только два режиме - либо ресурс кэшируется, либо нет. С помощью же Cache Storage мы можем настраивать различные стартегии кэширования, более того, мы можем, в сочетании с SW достичь полностью автономной работы приложения.
Опять же, решение использовать Cache API - не панацея. Нужно понимать, нужен ли он точно на проекте или же проще обойтись обычным HTTP Cache.
Согласен, здесь действительно лучше было бы повесить в sw обработчик на событие fetch и уже там решать - что кэшировать, а что нет. Просто хотелось скорее показать, что такое CacheAPI и продемонстрировать принцип его работы.
VDOM согласует изменения для оптимизированного рендеринга и вставляет их в DOM, в то время как Shadow DOM скорее позволяет включать поддерево элементов DOM в рендеринг, но не в основное DOM. Хотя соглашусь, что концепции похожи. Так же есть слоты, компоненты и т.д.