olenkill2

const saveTask = () => {
    editingEl.textContent = text.value;
    currentTitle = text.value;
    text.remove();
}

text.addEventListener("blur", saveTask);

text.addEventListener("keypress", (e) => {
    if (e.key === "Enter") {
        saveTask();
    }
});

// добавляем обработчик события "fetch"
self.addEventListener("fetch", (event) => {
  console.log("Fetch событие для", event.request.url);

  event.respondWith(
    caches
    .match(event.request)
    .then((response) => {
      //Если response найден в кэше
      if (response) {
        console.log("Найден ", event.request.url, " в кэше");
        return response;
      }

      return fetch(event.request).then((response) => {
        // Если response не найден
        if (response.status === 404) {
          return caches.open(CACHE_NAME).then((cache) => {
            return cache.match("404.html");
          });
        }

        // Кэширование и возвращение response если его еще нет в кэше
        return caches.open(CACHE_NAME).then((cache) => {
          if (!(event.request.url.indexOf('chr') === 0))
          cache.put(event.request.url, response.clone());
          return response;
        });
      });
    })
    .catch(async (error) => {
      console.log("Error, ", error);
      // Если страница офлайн или нет сети
      return caches.open(CACHE_NAME).then((cache) => {
        return cache.match("404.html");
      });
    })
  );
});

Тут нужна преамбула:

Stable он стал исключительно потому, что это событие надо было приурочить к конференции "Nuxt Nation" (в общем-то, с этого коммита они начали конференцию), потому что, во-первых, это красиво и всего раз в году, а во-вторых, это важно с точки зрения маркетинга - Эван Ю, например, получил возможность этим фактом бравировать.

По факту же, последний Release Candidate в шапке описания содержит сообщение "1 or 2 additional release candidates are expected before the final 3.0.0 version" (причём в моей памяти оно отложилось как "few more release candidates" - может, отредактировано, а может, я неправильно запомнил).
Как бы то ни было, планировалось 2 релиза до стабильной версии. Но через 2 недели случился Nuxt Nation. Осталось два релиза до стабильной версии :)

С начала декабря висит черновик MR с релизом 3.1.0, в котором было написано, что он будет готов в декабре. Сейчас там написано, что он будет готов в январе (в подтверждение того, что описания таки редактируются).
Это всё к тому, что релизный цикл ненадёжный и скорее ситуативный. Вот ишью, в котором вопрос поднимается. С учётом того, что и публичную бету отложили на полгода, и стабильный релиз на тот же срок (и ещё больше), а также потому, что на момент релиза было 400 ишью, сейчас - почти 600, я укрепляюсь во мнении, что они замахнулись на слишком многое сразу, имея команду в 3 человека. Причём приоритетность задач... Ну, я особо не сталкерил за контрибьюторами, но осталось ощущение, что в первую очередь делается то, что интересно, а не то, что у людей больше всего болит.
И тем не менее, они фанаты и многое успевают :)

---

К сути вопроса - если вы делаете что-то с нуля, то можно попробовать. Даже нужно, ибо год спустя большая часть проблем решится, а цикл разработки он примерно такой и есть. Главное - помечать костыли и подпорки :)

У меня в продакшене проектов на Nuxt 3 нет, но есть пара в активной разработке.
Вы помучаетесь с настройкой прокси для запросов (потому что встроенной функциональности ждём уже почти год) (но там можно подпереть и заработает). Там будут ещё проблемы, особенно под Windows и если вам нужны свои модули, но это запомнилось больше всего. Но ничего нерешаемого пока нет.

Если же вы хотите мигрировать существующий проект...
По моим ощущениям, у Nuxt 3 большие проблемы с определением места, где что-то пошло не так.
Вам, скорее всего, придётся мигрировать довольно маленькими кусочками и проверять, не сломалось ли чего, потому что если сломалось где-то в большом куске кода, вы почти наверняка получите ошибку в духе "500. Что-то не работает, а где - не покажу".
Короче, это будет "написание с нуля, копируя кусочки из предыдущего релиза на Nuxt 2".

Ну и плюс - экосистема. У меня почти всё своё, так что это не было сильно больно, но если активно пользуетесь сторонними модулями - смотрите поддержку и дату последнего обновления.

В целом, после перехода удобство разработки значительно повысилось, во многом из-за TS без костылей (ну, почти, я очень надеюсь что в обозримом будущем вот это закроется. Хотя Эван обещал это релизить в ноябре... Все факапят сроки :) ).
Сборка побыстрее примерно вдвое, hot reload весьма значительно быстрее (почти мгновенно до сих пор, хотя видна тенденция к замедлению. В любом случае 20-30x прирост по сравнение с Nuxt 2).
Клиентский перфоманс, кстати, опираясь на попугаи PageSpeed, возрастает примерно так, что там, где на Nuxt 2 было 60, тут станет 80. Я не копал пока глубоко в клиентскую оптимизацию на Nuxt 3, наверняка там можно что-то выдумать, но по первым впечатлениям вот так - побыстрее, но чуда не случилось, фреймворк всё ещё имеет существенный оверхэд по сравнению с чем-то более нативным.

Надо бы насобирать еще материал, но
1. по поводу лагов - чем меньше фильтров, теней, прозрачностей - тем айфону легче. Не умеет в ускорение.
2. скролл - это отдельная БОЛЬНАЯ тема у айфонов. Причем у разных версий IOS они разные. Проблема в том, что реализация демонстрации куска верстки длинной страницы в окне браузера просто уродская. На старых айфонах, к примеру, не работал position fixed.
3. Никогда, просто НИКОГДА не пытайся прибить скользящее меню к низу страницы. Это и на андроиде выйдет дичайшим геммороем из-за автовсплывающих или автоскрывающихся панелей инструментов. Это ад и боль
4. В качестве задачи со звездочкой - попробуй реализовать модалку поверх контента, в которой свой скролл, и попробуй заблочить скролл контента в фоне. Айфон тебя порадует своими чудесами.
5. Думаю, будет весело перебирать высоту вьюпорта и подбирать позиционирование, переключаясь то на px то на wh.
6. Имей в виду - как бы не назывался браузер на айфоне - он использует одно и то же ядро сафари, специфичное для версии ios, так что глюки переносятся.
7. Ловил проблемы (тут уже не в платформе а в реализации сафари) именно в сафари если делаем display: flex, flex-direction: reverse, отваливается gap. Без реверса - всё гуд. На других реализациях таких проблем не встречал.
8. Если ты попробуешь поиграть с параллаксом самописанным - получишь ачивку "слабоумие и отвага"

Почему нативные модули не так просто скомпилировать под любой контроллер?

Потому что нужен компилятор под нужную архитектуру и код должен быть написан так что бы он под эту архитектуру в принципе компилировался. К тому же компиляция это обычно долго. Поэтому для популярных нативных модулей авторы распространяют заранее скомпилированные файлы (тот же sharp), но только для какого-то набора популярных операционных систем и процессоров.

В нативных модулях добавлены куски из других языков или как это происходит?

Да. Обычно на C/C++, но может быть что угодно, Rust, Go, да хоть ассемблер.

И как в npm понять, какие модули ванильные, а какие нативные?

Обычно это в документации написано, но формально никак пока не попробуешь поставить.

Как выяснилось, яндекс лампочки - это ребрендированная Tuya лампочка. У Tuya есть локальный протокол и модуль для Home Assistant. Но я решил вопрос немного иначе:

1. Устанавливаем приложение Smart Life или Tuya Home (оба совместимы с яндекс лампами)
   
2. Сбрасываем настройки лампочек и добавляем их в приложении Smart Life / Tuya Home
   
3. Регистрируем приложение на платформе Tuya. Инструкция есть в этом репозитории.
   
   Пояснение

   Этот шаг нам нужно проделать, чтобы получить Local Key, который требуется для шифрования и расшифровки запросов (Local Key, как я понял, обновляется после сброса настроек). Инструкция, как быстро добавить устройства в приложение платформы Tuya так же представлено в репозитории
   
   
4. Выбираем библиотеку для работы с Tuya local api. Я выбрал вот эту библиотеку для C#. На GitHub странице этой библиотеки есть инструкция по работе с Tuya local api.
   
5. Реализуем нужный нам функционал
   

Небольшой топорный пример из моего тестового проекта:




Далее остаётся разобраться с кодами команд и можете контролировать лампы как вам угодно.

Роман Бурч shurshur
Единственный вариант как сделать чат между двумя ботами это связка Канал + Группа обсуждения
Два бота находятся там и там. Причем когда бот пишет в канал то сообщите дублируется в группу и это сообщение уже может прочесть другой бот. Это огромный костыль но все же работает

const canvas = document.createElement('canvas');
const context = canvas.getContext('2d');
const lineWidth = 60;
const radius = 200;

[canvas.width, canvas.height] = [radius * 2, radius * 2];
context.beginPath();
context.arc(radius, radius, radius - lineWidth / 2, 0, Math.PI * 2);
context.closePath();
context.lineWidth = lineWidth;
context.stroke();

document.body.append(canvas);

<template>
    <v-data-table>
        <template v-for="(_, slot) of $slots" :slot="slot">
            <slot :name="slot"/>
        </template>

        <template v-for="(_, slot) of $scopedSlots" #[slot]="scope">
            <slot :name="slot" v-bind="scope"/>
        </template>
    </v-data-table>
</template>

держите

UPD. Или, с использованием вашей демки.

Никак. Браузер не тупой.

1. Адекватность и самостоятельность.
Детальнее: Умение понять суть задачи, чтобы выполнить ее. Самостоятельно решать проблемы - в это слово входит не только то, что возникла проблема - порешал. А умение решить проблемы, которые ты решить не можешь. То есть организовать решение проблемы. Заблочили аккаунт? Выяснить, вызвонить, попинать, чтобы разлочили побыстрее. Не знаешь как решить какую-то техническую проблему - достучаться до куратора. Не сидеть и ждать три дня, пока он вспомнит про твою проблему, а регулярно уточнять. Занят куратор - подойти к другому. Не успеваешь решить в срок - прийти к куратору заранее, а не за час до конца срока.
В общем, чтобы за тобой не бегали.

2. Умение ставить правильные вопросы.
Сперва загуглить, потом задать вопрос для уточнения. В идеале ставить вопросы, на которые ответ будет "да" или "нет", но это я утрирую. Не бояться спрашивать вещи, которые совсем не понимаешь, но тут не нужно ожидать что все будут разжевывать - следует задать вопрос, чтобы понять куда копать. Иногда достаточно знать пару ключевых слов, по которым можно загуглить.

3. Желание учиться.
Не бояться изучить лишнее, потому что "мне же это не пригодится". Умение гуглить по ключевым словам. Не лениться изучать как что-то работает, чтобы понимать почему это происходит. Понимание принципов работы очень сильно увеличивает интуицию.

Как вы прокачивались?

Много-много экспериментов с целью не "научиться решать типовые задачи", а скорее "поиграть с инструментами и посмотреть, что будет". Такой подход дает более полную картину происходящего. Ну и гугл/документации/статьи по мере необходимости.

На что стоит сделать упор в обучении именно верстки и малого количества js-а?

Методы зависят от наличия времени и изначального уровня обучаемых. В целом для развития понимания CSS полезно "рисовать" на нем. Грубо говоря один автопортрет или зверушка, сделанная самостоятельно от начала и до конца, даст опыта как десяток лендингов. В таких песочницах концентрация хитрых задач на верстку в разы выше, чем на обычных сайтах, и обучение идет быстрее. Ну и просто прикольные штуки получаются, можно внести элементы игры с плюшками за успехи. В последние годы эта тема стала очень популярной на CodePen в виде ежедневных разминок для ума.

Как обучали людей? У меня нет опыта в обучении людей

По поводу методологий и хороших практик - нужно объяснять, отвечая в первую очередь на вопрос "почему". Тупое давление авторитетом (я прав - вы нет, мое решение хорошее - ваше нет) ни к чему не приведет. С вопросом "как" - отправлять к документации, чтобы читали сами и заодно захватывали что-то еще по дороге. Если все разжевывать - не научатся работать самостоятельно. Полезно научить их задавать вопросы. Если видите, что совсем не получается - тогда уже можно подсказать и показать. По возможности нужно автоматизировать проверку действий стажеров, чтобы они сразу видели свои косяки, не дожидаясь, пока придет наставник. Я тут как раз на днях подборку полезностей делал, там и для этого есть инструменты.

Коммуникацию нужно наладить в обязательном порядке, чтобы все имели возможность спросить и не боялись это делать. Тут больше про психологию вопрос - нужно не только определить время и способ общения, чтобы и вам не мешали, и могли оперативно получить ответ, но и обязательно следить за своим языком, чтобы не быть "слишком токсичным" (про это все постоянно забывают). И помните - все ошибаются, ваши ошибки должны становиться поучительными примерами, не нужно их скрывать или стыдиться. Полезно в конце недели делать собрание "только для стажеров" и разбирать, что произошло интересного за неделю, чтобы они видели полную картину, учились на ошибках друг друга и распространяли опыт уже между собой - вы объяснили что-то одному, он в конце недели - остальным (а когда объясняешь - сам лучше понимаешь). Как вариант все вопросы от них к вам можно организовать в отдельном таск-трекере, чтобы ничего не терялось (как в бесконечных чатах) и можно было отсылать вновь прибывших к уже готовым ответам.