А вот интересно: в критических системах, да и в тех же самолётах, есть требование о дублировании модулей, причём желательно, чтобы они были полностью независимы. Почему же в компьютерных системах всегда стремятся реализовать гомогенную среду: одинаковое железо, одинаковые ОС, одинаковое системное и прикладное ПО? Или считается, что критический отказ одинаковых систем маловероятен и потому «дешевле», чем поддержка гетерогенной среды?
Если же оставлять канвасы как есть, то лучше не делать произвольные атрибуты, а передавать специально для того задуманными data-атрибутами (data-image, data-color).
Только при таком обучении игре на музыкальных инструментах от костюма потребуется потрясающая точность, поскольку минимальные изменения в положениях рук и пальцев могут сильно влиять на звук. А ещё этот костюм сам по себе не должен мешать игре.
Нет :) Почему-то ни в Chrome, ни в Firefox нормально проект не заработал. Ну то есть вроде как сервер запустился, но дальше был просто белый экран без каких-либо ошибок в консоли.
В apply атрибуты применяются, очевидно, по правилам тейлвинда, а в атрибутах HTML — по спецификациям HTML и CSS.
можно было бы сгенерить цепочки
Тейлвинд сам не анализирует ни используемые классы, ни тем более списки. Более того, в общем случае сгенерировать такие цепочки невозможно. Здесь нам «повезло», что есть разные классы, по которым можно различить эти элементы и построить специфичные селекторы.
В обоих случаях применился height: 5rem, потому что .h-20 описан ниже, чем .h-10, что вам тут неоднократно говорили. Tailwind чудес не делает, он тупо генерирует набор классов как это сделал бы, например, цикл @for в SASS, а затем сторонняя тулза PurgeCSS вычищает неиспользуемые классы. А браузер уже применяет атрибуты в соответствии с порядком появления их в CSS-файлах.
В случае атомарных фреймворков типа tailwind в конструкции class="w-big w-small" будет применен именно последний. Ибо переопределение свойств и есть часть CSS
Тейлвинд же не компилирует шаблоны. Максимум purgecss уберёт неиспользуемые классы. И действительно свойства нижележащего в css класса затирают предыдущие, несмотря на порядок их перечисления в атрибуте `class`.
Мне кажется, что при выводе логики поведения NPC на максимум, получится, что когда герой начнёт расти в скиллах, местный правитель может очень быстро заподозрить, что герой может и его свергнуть. Он быстренько соберёт армию, против которой невозможно будет выиграть даже ненулевому герою.
Даже если такая возможность для нейтралов будет лимитирована, например, моральными установками, то либо такую же операцию проделает антагонист игры, либо он начнёт всячески прятаться от героя, либо вообще капитулирует без боя. Можно, например, представить, что в шахматах одна из пешек после каждого взятия повышает уровень и может стать даже сильнее ферзя. Соперник просто признает поражение задолго до объявления мата.
Если нет нужных бумаг, то заявление ни в одной нормальной стране не примут. Но, насколько я знаю статистику от эйчаров нашей компании, с 2024 года ситуация с ВНЖ значительно улучшилась. До этого действительно было проблематично получить одобрение.
Можете привести практически пример? Потому что сейчас это ни о чём. В браузере API работы с историей есть из коробки, роутеры работают поверх него. И да, если он в приложении не нужен, роутер можно не подключать.
Под Vue в целом достаточно проектов, а стартапы на нём делать быстрее, чем на Реакте.
Может быть 80% проблем HTMX и решает, но 20% задач сделают больно. И хорошо, если не более 80% времени они потребуют.
Разумных доводов от Thoughtworks, что SPA — это плохая практика, я не увидел. Browser history management решается обычным фронтендным роутером уже почти 10 лет; веб-аналитика тупо работает как есть — ей достаточно урла в браузере; там где нужны SEO (а это далеко не все админки) и TTFB — используются Next / Nuxt / whatever.
Выбор SPA был обусловлен разделением ответственности и задач: бекендеры делают бекенд на своих инструментах, фронтендеры делают веб-фронтенд на своих инструментах. Если нужно мобильное приложение, то это всего лишь ещё один фронтенд, который будет использовать тот же API. Плюс разделение ответственности позволяет гибче переписывать фронтенд и бекенд при необходимости вплоть до смены технологий.
Передача параметров в компоненты в шаблонах не отслеживается.
Почему ворующий? Он не парсил сайт Yelp, а честно подключился к их API. В приложении логотип Yelp был постоянно виден в главном окне.
Так вот почему последний месяц-два он стал ещё больше тормозить? )
А вот интересно: в критических системах, да и в тех же самолётах, есть требование о дублировании модулей, причём желательно, чтобы они были полностью независимы. Почему же в компьютерных системах всегда стремятся реализовать гомогенную среду: одинаковое железо, одинаковые ОС, одинаковое системное и прикладное ПО? Или считается, что критический отказ одинаковых систем маловероятен и потому «дешевле», чем поддержка гетерогенной среды?
Разве аутентификация и авторизация в целом не зависят от UI-слоя, который предоставляют React или Vue?
Лучше тогда всё это завернуть в custom element. Будет как-то так:
Если же оставлять канвасы как есть, то лучше не делать произвольные атрибуты, а передавать специально для того задуманными data-атрибутами (data-image, data-color).
Только при таком обучении игре на музыкальных инструментах от костюма потребуется потрясающая точность, поскольку минимальные изменения в положениях рук и пальцев могут сильно влиять на звук. А ещё этот костюм сам по себе не должен мешать игре.
Нет :) Почему-то ни в Chrome, ни в Firefox нормально проект не заработал. Ну то есть вроде как сервер запустился, но дальше был просто белый экран без каких-либо ошибок в консоли.
В apply атрибуты применяются, очевидно, по правилам тейлвинда, а в атрибутах HTML — по спецификациям HTML и CSS.
Тейлвинд сам не анализирует ни используемые классы, ни тем более списки. Более того, в общем случае сгенерировать такие цепочки невозможно. Здесь нам «повезло», что есть разные классы, по которым можно различить эти элементы и построить специфичные селекторы.
В таком случае ваша схема не сработает:
Это потому, что в селекторах никакого различия в порядке классов нет, и такие селекторы будут означать одно и то же:
https://play.tailwindcss.com/UCW6C4kRRj
https://jsbin.com/wenocivozo/edit?html,css,output
https://play.tailwindcss.com/rc8Bihs9Lx
В обоих случаях применился
height: 5rem, потому что.h-20описан ниже, чем.h-10, что вам тут неоднократно говорили. Tailwind чудес не делает, он тупо генерирует набор классов как это сделал бы, например, цикл@forв SASS, а затем сторонняя тулза PurgeCSS вычищает неиспользуемые классы. А браузер уже применяет атрибуты в соответствии с порядком появления их в CSS-файлах.Отлично, этого раньше не хватало. Жаль, что по режимам и собственно чекам много нюансов. И во Vue такого очень не хватает.
Это, кажется, относится именно к шаблонам.
Кто?
В одном элементе я пропишу `class="w-big w-small"`, в другом `class="w-small w-big"`. Что мне tailwind в этом случае сгенерирует?
Тейлвинд же не компилирует шаблоны. Максимум purgecss уберёт неиспользуемые классы. И действительно свойства нижележащего в css класса затирают предыдущие, несмотря на порядок их перечисления в атрибуте `class`.
Мне кажется, что при выводе логики поведения NPC на максимум, получится, что когда герой начнёт расти в скиллах, местный правитель может очень быстро заподозрить, что герой может и его свергнуть. Он быстренько соберёт армию, против которой невозможно будет выиграть даже ненулевому герою.
Даже если такая возможность для нейтралов будет лимитирована, например, моральными установками, то либо такую же операцию проделает антагонист игры, либо он начнёт всячески прятаться от героя, либо вообще капитулирует без боя. Можно, например, представить, что в шахматах одна из пешек после каждого взятия повышает уровень и может стать даже сильнее ферзя. Соперник просто признает поражение задолго до объявления мата.
Если нет нужных бумаг, то заявление ни в одной нормальной стране не примут. Но, насколько я знаю статистику от эйчаров нашей компании, с 2024 года ситуация с ВНЖ значительно улучшилась. До этого действительно было проблематично получить одобрение.
С 2024 года законы доработали, и процент одобрения мог значительно измениться в лучшую сторону.
Можете привести практически пример? Потому что сейчас это ни о чём. В браузере API работы с историей есть из коробки, роутеры работают поверх него. И да, если он в приложении не нужен, роутер можно не подключать.
Под Vue в целом достаточно проектов, а стартапы на нём делать быстрее, чем на Реакте.
Может быть 80% проблем HTMX и решает, но 20% задач сделают больно. И хорошо, если не более 80% времени они потребуют.
Разумных доводов от Thoughtworks, что SPA — это плохая практика, я не увидел. Browser history management решается обычным фронтендным роутером уже почти 10 лет; веб-аналитика тупо работает как есть — ей достаточно урла в браузере; там где нужны SEO (а это далеко не все админки) и TTFB — используются Next / Nuxt / whatever.
Выбор SPA был обусловлен разделением ответственности и задач: бекендеры делают бекенд на своих инструментах, фронтендеры делают веб-фронтенд на своих инструментах. Если нужно мобильное приложение, то это всего лишь ещё один фронтенд, который будет использовать тот же API. Плюс разделение ответственности позволяет гибче переписывать фронтенд и бекенд при необходимости вплоть до смены технологий.