На самом Хабре есть уровень статьи, его можно выбрать при публикации: простой, средний или сложный. Я при оценке сложности статьи в заявке просто переиспользовал этот параметр) Надо было как-то по-другому?)
Ещё в момент наведения на зону сброса стоит проверять возможность сброса и в зависимости от этого менять её внешний вид, подключать индикацию в виде соответствующего курсора и так далее. Если всё же пользователь решит отпустить объекты над запрещённой зоной сброса, то стоит это обработать как отмену всего перетаскивания и вернуть элементы на место, но сохранить выделение, если оно было установлено до начала перетаскивания (например, если было выбрано несколько файлов).
Дополнительные обработки на событие сброса не потребуются, если пользователь был проинформирован о проблемах ещё в процессе какого-то действия, до его завершения. Если же по каким-то причинам при такой отмене сброса может произойти потеря контекста, можно уведомить пользователя о возникшей проблеме ненавязчивым всплывающим сообщением.
Я не докопался до трелло, а аргументированно указал на его недостатки. И сделал это как раз потому, что трелло является неким неформальными образцом для интерфейсов с Drag and Drop. Вот только если проанализировать его детально, можно увидеть, что некоторые решения в нём или устарели, или недостаточно продуманы.
Возможно, я не смогу привести примеров из веба, в которых днд реализован сильно лучше, чем в трелло, но поэтому я и написал статью, в которой собрал все лучшие практики и рекомендации для каждой отдельной мелочи работы с перетаскиванием, чтобы на них можно было опираться при проектировании новых интерфейсов. Рекомендации взяты не из потолка, а из серьёзных исследований, профессиональных книг по проектированию интерфейсов, гайдлайнов к визуальным экосистемам технологических гигантов типа Google и Apple, а также из личного опыта разработки и использования drag and drop.
Спасибо за вопрос! Я так понимаю, когда сортировки нет, строки можно перетаскивать в любом порядке? Здесь важно — сохраняется ли пользовательская сортировка, когда выключена сортировка по конкретному полю? Наверное, логично, что да, так как зачем вообще тогда доступен drag and drop? Если пользовательская сортировка не сохраняется после перезагрузки страницы, весь результат перетаскиваний сбросится.
Думаю, что здесь самое логичное — это запретить перетаскивание, если включена сортировка по какому-то столбцу. Но тогда при выключении этой сортировки, нужно вернуть тот порядок строк, который пользователь установил в процессе всех своих перетаскиваний. Для этого стоит иметь отдельное поле в таблице в БД с порядком строк, обновлять его при перетаскиваниях и при выключенной сортировке всегда сортировать строки по этому полю.
Мне кажется, что в этой логике и содержится ответ — любое перетаскивание приводит к изменению порядка строк, а при включенной сортировке по какому-то столбцу этот порядок не должен влиять на сортировку.
Думаю, что ответ в том, что хоть разработчики Trello и взяли Drag and Drop за основу в своих интерфейсах, они сделали это очень давно (по меркам веба) — в 2011-ом году. Интерфейс Trello несколько менялся за это время, но основные подходы остались прежними. Им бы не помешало немного обновиться, хотя, с другой стороны, есть много современных альтернатив, которые выглядят и работают лучше :)
Можно ещё дополнительно использовать генераторы фейковых json, например https://fakerjs.dev/. Там много встроенных типов, которые можно дополнительно настроить, чтобы нагенерить то, что нужно. Ну или всегда можно написать самому генерацию под ваши модели данных.
Service Worker эмулирует сетевое поведение и абстрагируется от особенностей приложения — библиотек для запросов, среды исполнения и т.д. Каждый перехваченный запрос отображается во вкладке Network как обычный запрос к бэкенду. MSW можно использовать на ноде и мокать, к примеру, SSR-приложения. С решениями, в которых подменяется fetch такой гибкости нет, и вся работа по мокингу остаётся на слое с приложением, что по сути полноценной эмуляцией серверного поведения не является.
Возможно, не обязательно добалять атрибут aria-describedby именно для связи со всем контентом, но лучше добавить его хотя бы со ссылкой на блок с дополнительным описанием окна, чтобы скриндеры считали его сразу же после открытия окна, а не при наведении курсора. Я считаю, что в случае со вспомогательными технологиями стоит давать как можно больше информации.
Как можно видеть, каждая новая открытая модалка будет рендериться на новом top layer, перекрывая остальные, вне зависимости от того, где в реальном DOM находится её элемент. А если попробовать открыть все модалки и начать закрывать их через клавишу Esc, то они будут закрываться по очереди, начиная с самой последней открытой.
Плюс язык шаблонов Astro очень простой, если вы писали на любой современной UI-либе типа React, Vue или Svelte, то вы можете практически сразу же писать шаблоны Astro. А если вам вообще не нужна динамика, то это будет просто обычный HTML-синтаксис, ничего специфического учить не нужно.
Сравниваю не я, я предоставил ссылку на сравнение, которое проводила команда Astro. Там показана разность в скорости работы с SSR-фреймворками, когда они работают именно как генераторы статических сайтов и генерируют страницы при сборке. В этом случае, прирост скорости у Astro может быть довольно существенным.
Что касается сравнения скорости и производительности с VitePress — такого я не нашёл, думаю, что здесь они оба покажут достаточно хорошие результаты. Я попробовал сформировать отчёты в PageSpeed Insights для главных страниц Astro и VitePress, замеры не претендуют на то, чтобы показать полноценное сравнение, но все равно приложу результаты:
Как видно, показатели не отличаются критическим образом, где-то больше очков у Astro, где-то у VitePress, но, конечно, стоит провести более точные замеры на одном и том же контенте страницы.
Думаю, что в сравнении с VitePress основным фактором предпочтения Astro может стать его UI-agnostic философия и архитектура островов. Если VitePress завязан на использование Vue.js, то Astro не ограничивает в выборе UI-библиотеки.
Во-первых, Jekyll требует Ruby, и все плагины для него написаны на Ruby. Astro написан на TypeScript — он воспринимается как обычная npm-зависимость, а не какая-то внешняя утилита. Во-вторых, Jekyll использует морально устаревший шаблонизатор Liquid, когда как в шаблонах Astro используется JSX-синтаксис со всей его гибкостью. В-третьих, в Jekyll будет целой эпопеей встроить виджет, написанный на любой UI-библиотеке, значит вы не сможете легко добавить какую-то мало-мальски сложную интерактивность на своих сайтах. В Astro можно использовать одновременно React, Vue, Svelte и т.д. и это будет работать очень быстро и легко настраиваться.
Что касается второго вопроса, мне кажется, что генераторы статических сайтов подойдут для тех команд, которые могут выделить ресурс на разработку собственных решений, так как хотят иметь больший контроль над своими приложениями. Тот же Astro отлично интегрируется с различными решениями для админок, но команде разработки придётся самостоятельно заниматься настройкой всех этих инструментов. Это не тот вариант, где всё работает из коробки как в WordPress, так что генераторы стоит использовать, если только вам необходим полный контроль над инструментами и качеством сайтов, которые получаются на выходе. Кстати, тот же WordPress формирует разметку по запросу, а не на этапе сборки, это влияет на скорость работы и безопасность сайта.
Ещё есть вариант, в котором маркетинг-команда работает с md-файлами, там очень простой синтаксис и тот же Astro умеет преобразовывать их в полноценные страницы, но, конечно, это не замена визуальному редактору, какие-то базовые навыки разработки при работе с этим синтаксисом необходимы.
Я считаю, что JS-реализации по умолчанию хуже полноценного нативного стандарта, потому что разработаны и поддерживаются не производителями конечных технологий — браузеров, а такими же разработчиками, как и мы с вами. Как следствие, эти реализации могут перестать поддерживаться в будущем. Кроме того, они могут использовать различные хаки и нестандартизированные приёмы для того, чтобы эмулировать поведение, которое работает в нативных реализациях. К примеру, в них может эмулироваться функциональность глобального атрибута inert, блокирующего действия над остальной страницей под модальным окном или же поведение фокуса, которое давно стандартизированно в нативной реализации. В конце концов, такие реализации могут быть слишком тяжеловесными в рамках конкретного проекта, да и в целом это лишняя внешняя зависимость. Впрочем, некоторые проблемы в нативной реализации до сих пор остаются, подробнее можно прочитать в документации к библиотеке a11y-dialog: https://a11y-dialog.netlify.app/further-reading/dialog-element. Но на той же странице разработчики библиотеки пишут, что использование нативного элемента на настоящий момент вполне резонно.
Полифил же подключать необязательно — поддержка браузерами уже достаточно широкая, чтобы покрывать основную массу клиентов: caniuse.com пишет о 95.75% поддержки стандарта. Его стоит использовать, когда вам необходима поддержка совсем неактуальных браузеров типа Internet Explorer. Но если в вашем проекте требуется поддержка таких старых браузеров, скорее всего вы и так используете для них множество различных полифилов. В общем, моё мнение, что по умолчанию полифил для элемента <dialog> подключать не нужно, так как стандарт уже вполне устоялся.
Это могут любые задачи, вплоть до использования <dialog> в UI-библиотеках для фреймворков на боевых проектах. Лично я в своих приложениях уже давно переписал все модалки на нативный элемент и радуюсь, что в стандарте учтены основные проблемы реализации, которые раньше нужно было предусматривать самому, или же пользоваться внешними решениями типа a11y-dialog, хотя мне может не требоваться вся их функциональность.
Предлагаю всем почитать книгу отца-основателя крионики «Перспективы бессмертия» Роберта Эттингера. Удивительно, что мысли, высказанные там еще в 60-ых годах до сих пор воспринимаются большинством как слишком новаторские и фантастические. Не знаю, воплощением и развитием этих и подобных идей должно заниматься все мировое сообщество, это не может быть активностью только одной группы ученых, одного института или даже одной страны. Ведь в связи с перспективами добраться до подобных технологий, рассчитанных на продление жизни человеку, возникает просто гигантский поток принципиальных вопросов, на которые всем предстоит так или иначе ответить, иначе нас ожидает самая масштабная премия Дарвина в истории. Что, в принципе, и так нас ждет, если вообще не задумываться о будущем.
На самом Хабре есть уровень статьи, его можно выбрать при публикации: простой, средний или сложный. Я при оценке сложности статьи в заявке просто переиспользовал этот параметр) Надо было как-то по-другому?)
Ещё в момент наведения на зону сброса стоит проверять возможность сброса и в зависимости от этого менять её внешний вид, подключать индикацию в виде соответствующего курсора и так далее. Если всё же пользователь решит отпустить объекты над запрещённой зоной сброса, то стоит это обработать как отмену всего перетаскивания и вернуть элементы на место, но сохранить выделение, если оно было установлено до начала перетаскивания (например, если было выбрано несколько файлов).
Дополнительные обработки на событие сброса не потребуются, если пользователь был проинформирован о проблемах ещё в процессе какого-то действия, до его завершения. Если же по каким-то причинам при такой отмене сброса может произойти потеря контекста, можно уведомить пользователя о возникшей проблеме ненавязчивым всплывающим сообщением.
Я не докопался до трелло, а аргументированно указал на его недостатки. И сделал это как раз потому, что трелло является неким неформальными образцом для интерфейсов с Drag and Drop. Вот только если проанализировать его детально, можно увидеть, что некоторые решения в нём или устарели, или недостаточно продуманы.
Возможно, я не смогу привести примеров из веба, в которых днд реализован сильно лучше, чем в трелло, но поэтому я и написал статью, в которой собрал все лучшие практики и рекомендации для каждой отдельной мелочи работы с перетаскиванием, чтобы на них можно было опираться при проектировании новых интерфейсов. Рекомендации взяты не из потолка, а из серьёзных исследований, профессиональных книг по проектированию интерфейсов, гайдлайнов к визуальным экосистемам технологических гигантов типа Google и Apple, а также из личного опыта разработки и использования drag and drop.
Спасибо за вопрос! Я так понимаю, когда сортировки нет, строки можно перетаскивать в любом порядке? Здесь важно — сохраняется ли пользовательская сортировка, когда выключена сортировка по конкретному полю? Наверное, логично, что да, так как зачем вообще тогда доступен drag and drop? Если пользовательская сортировка не сохраняется после перезагрузки страницы, весь результат перетаскиваний сбросится.
Думаю, что здесь самое логичное — это запретить перетаскивание, если включена сортировка по какому-то столбцу. Но тогда при выключении этой сортировки, нужно вернуть тот порядок строк, который пользователь установил в процессе всех своих перетаскиваний. Для этого стоит иметь отдельное поле в таблице в БД с порядком строк, обновлять его при перетаскиваниях и при выключенной сортировке всегда сортировать строки по этому полю.
Мне кажется, что в этой логике и содержится ответ — любое перетаскивание приводит к изменению порядка строк, а при включенной сортировке по какому-то столбцу этот порядок не должен влиять на сортировку.
Думаю, что ответ в том, что хоть разработчики Trello и взяли Drag and Drop за основу в своих интерфейсах, они сделали это очень давно (по меркам веба) — в 2011-ом году. Интерфейс Trello несколько менялся за это время, но основные подходы остались прежними. Им бы не помешало немного обновиться, хотя, с другой стороны, есть много современных альтернатив, которые выглядят и работают лучше :)
Можно ещё дополнительно использовать генераторы фейковых json, например https://fakerjs.dev/. Там много встроенных типов, которые можно дополнительно настроить, чтобы нагенерить то, что нужно. Ну или всегда можно написать самому генерацию под ваши модели данных.
Не совсем понял, что вы имеете в виду под "записывать ответ"?
Service Worker эмулирует сетевое поведение и абстрагируется от особенностей приложения — библиотек для запросов, среды исполнения и т.д. Каждый перехваченный запрос отображается во вкладке Network как обычный запрос к бэкенду. MSW можно использовать на ноде и мокать, к примеру, SSR-приложения. С решениями, в которых подменяется fetch такой гибкости нет, и вся работа по мокингу остаётся на слое с приложением, что по сути полноценной эмуляцией серверного поведения не является.
Возможно, не обязательно добалять атрибут
aria-describedbyименно для связи со всем контентом, но лучше добавить его хотя бы со ссылкой на блок с дополнительным описанием окна, чтобы скриндеры считали его сразу же после открытия окна, а не при наведении курсора. Я считаю, что в случае со вспомогательными технологиями стоит давать как можно больше информации.Можете попробовать в деле: https://codepen.io/alexgriss/pen/YzBgxwG
Как можно видеть, каждая новая открытая модалка будет рендериться на новом top layer, перекрывая остальные, вне зависимости от того, где в реальном DOM находится её элемент. А если попробовать открыть все модалки и начать закрывать их через клавишу Esc, то они будут закрываться по очереди, начиная с самой последней открытой.
Astro тоже поддерживает markdown и даже mdx-синтаксис, в который можно встраивать JSX-выражения: https://docs.astro.build/en/guides/markdown-content/.
Плюс язык шаблонов Astro очень простой, если вы писали на любой современной UI-либе типа React, Vue или Svelte, то вы можете практически сразу же писать шаблоны Astro. А если вам вообще не нужна динамика, то это будет просто обычный HTML-синтаксис, ничего специфического учить не нужно.
Сравниваю не я, я предоставил ссылку на сравнение, которое проводила команда Astro. Там показана разность в скорости работы с SSR-фреймворками, когда они работают именно как генераторы статических сайтов и генерируют страницы при сборке. В этом случае, прирост скорости у Astro может быть довольно существенным.
Что касается сравнения скорости и производительности с VitePress — такого я не нашёл, думаю, что здесь они оба покажут достаточно хорошие результаты. Я попробовал сформировать отчёты в PageSpeed Insights для главных страниц Astro и VitePress, замеры не претендуют на то, чтобы показать полноценное сравнение, но все равно приложу результаты:
Astro: https://pagespeed.web.dev/analysis/https-astro-build/8s5msp9qs6?form_factor=mobile
VitePress: https://pagespeed.web.dev/analysis/https-vitepress-dev/8q9i7x3xtf?form_factor=mobile
Как видно, показатели не отличаются критическим образом, где-то больше очков у Astro, где-то у VitePress, но, конечно, стоит провести более точные замеры на одном и том же контенте страницы.
Думаю, что в сравнении с VitePress основным фактором предпочтения Astro может стать его UI-agnostic философия и архитектура островов. Если VitePress завязан на использование Vue.js, то Astro не ограничивает в выборе UI-библиотеки.
Добрый день!
Во-первых, Jekyll требует Ruby, и все плагины для него написаны на Ruby. Astro написан на TypeScript — он воспринимается как обычная npm-зависимость, а не какая-то внешняя утилита. Во-вторых, Jekyll использует морально устаревший шаблонизатор Liquid, когда как в шаблонах Astro используется JSX-синтаксис со всей его гибкостью. В-третьих, в Jekyll будет целой эпопеей встроить виджет, написанный на любой UI-библиотеке, значит вы не сможете легко добавить какую-то мало-мальски сложную интерактивность на своих сайтах. В Astro можно использовать одновременно React, Vue, Svelte и т.д. и это будет работать очень быстро и легко настраиваться.
Что касается второго вопроса, мне кажется, что генераторы статических сайтов подойдут для тех команд, которые могут выделить ресурс на разработку собственных решений, так как хотят иметь больший контроль над своими приложениями. Тот же Astro отлично интегрируется с различными решениями для админок, но команде разработки придётся самостоятельно заниматься настройкой всех этих инструментов. Это не тот вариант, где всё работает из коробки как в WordPress, так что генераторы стоит использовать, если только вам необходим полный контроль над инструментами и качеством сайтов, которые получаются на выходе. Кстати, тот же WordPress формирует разметку по запросу, а не на этапе сборки, это влияет на скорость работы и безопасность сайта.
Ещё есть вариант, в котором маркетинг-команда работает с md-файлами, там очень простой синтаксис и тот же Astro умеет преобразовывать их в полноценные страницы, но, конечно, это не замена визуальному редактору, какие-то базовые навыки разработки при работе с этим синтаксисом необходимы.
А ещё нативные возможности работают быстрее, чем заменяющие их скрипты.
Я считаю, что JS-реализации по умолчанию хуже полноценного нативного стандарта, потому что разработаны и поддерживаются не производителями конечных технологий — браузеров, а такими же разработчиками, как и мы с вами. Как следствие, эти реализации могут перестать поддерживаться в будущем. Кроме того, они могут использовать различные хаки и нестандартизированные приёмы для того, чтобы эмулировать поведение, которое работает в нативных реализациях. К примеру, в них может эмулироваться функциональность глобального атрибута
inert, блокирующего действия над остальной страницей под модальным окном или же поведение фокуса, которое давно стандартизированно в нативной реализации. В конце концов, такие реализации могут быть слишком тяжеловесными в рамках конкретного проекта, да и в целом это лишняя внешняя зависимость. Впрочем, некоторые проблемы в нативной реализации до сих пор остаются, подробнее можно прочитать в документации к библиотекеa11y-dialog: https://a11y-dialog.netlify.app/further-reading/dialog-element. Но на той же странице разработчики библиотеки пишут, что использование нативного элемента на настоящий момент вполне резонно.Полифил же подключать необязательно — поддержка браузерами уже достаточно широкая, чтобы покрывать основную массу клиентов: caniuse.com пишет о 95.75% поддержки стандарта. Его стоит использовать, когда вам необходима поддержка совсем неактуальных браузеров типа Internet Explorer. Но если в вашем проекте требуется поддержка таких старых браузеров, скорее всего вы и так используете для них множество различных полифилов. В общем, моё мнение, что по умолчанию полифил для элемента
<dialog>подключать не нужно, так как стандарт уже вполне устоялся.Это могут любые задачи, вплоть до использования
<dialog>в UI-библиотеках для фреймворков на боевых проектах. Лично я в своих приложениях уже давно переписал все модалки на нативный элемент и радуюсь, что в стандарте учтены основные проблемы реализации, которые раньше нужно было предусматривать самому, или же пользоваться внешними решениями типа a11y-dialog, хотя мне может не требоваться вся их функциональность.