Альберт Ефремов

Вопрос мутный как и весь vue 3. :)
Если в React можно однозначно сказать ДА, с Vue, увы, так не получится, потому что много народу не отказалось и отказываться от options api не будет.

Почему так? А потому, что в отличие от React - в vue options api на порядок удобнее и проще как в освоении так и в применении(особенно с классовыми компонентами), при том не имеет никаких действительно критических недостатков.
Composition api же тут решают "проблему" которая и не встретится 99% пользователей(собственно завозит сложную перекрёстную композицию кусочков компонентов), при этом привносит кучу излишней сложности и микроконтроля(а также мерзкий синтаксис).

Официальная позиция: composition api - будущее, всё остальное фигня. Большинство библиотек также ориентируется на composition api. На практике же этого будущего можно и не дождаться.:)

В общем учи всё, благо более-менее просто.

Изначально nuxtjs(и его вдохновитель nextjs) - фреймворки, которые представляют собой готовый рецепт и набор правил для построения приложений на библиотеке Vue.js или React. Хотя можно обойтись без них и строить приложения как душе угодно, но удобнее иметь набор правил в сообществе и в команде. В процессе разработки фронтенд-приложений постепенно появляется необходимость в различных оптимизациях, в том числе в скорости и SEO, поэтому активно развивается бэкэнд для фронтенда. Он используется в основном для дополнительного кеширования и рендеринга на стороне сервера.

Конечно, вы можете подключаться к базе данных для получения информации. Для этого есть специализированные плагины и практики(можно прям гуглить nuxt 3 mysql). В целом, у вас есть доступ ко всем возможностям Node.js, так что всё в ваших руках. Чаще всего используются какие-либо ORM (Object-Relational Mapping), которые облегчают доступ к БД, убирая рутину на себя и предоставляя удобный доступ к данным. Например, Prisma.

В целом, обычно в Nuxt.js и подобных фреймворках напрямую с БД не работают, так как это ломает классическую архитектуру подобных приложений с разделением логики, масштабирования и т.п. Так что даже если на бэкенде Node.js, то это отдельные независимые сервисы, которые предоставляют каким-либо образом доступ к подготовленным данным из БД (например через REST API), а уже приложение на Next.js обращается к нему и в своей бэкенд-части и через браузер.

Резюмируя: Nuxt - для отображения интерфейса/фронтенда, даже при использовании рендринга на стороне сервера, получение обновление данных через API(REST/GraphQL/... ).
Express/Nest(что угодно другое бэкэндерское) - ядро бизнес логики, обработка данных, работа с БД, постороение API и тп.
Это если кратко, а так гуглите про архитектуру приложений, информации море, тема обширная.

я так понимаю, ваш класс меняет состояние компонента. Передавать состояние компонента через пропсы нормально.
Однако я бы напрямую может и не стал так делать.
Лучше передать само состояние, и внутри компонента назначить класс

Плохо

props: {
  'class': String
}

Лучше

props: {
  disabled: Boolean
}

<div :class={disabled: disabled}>

Это уменьшает связанность системы в целом. Компонент отвечает сам за себя, и родитель не знается о том, какие классы ему нужны.

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

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, наверняка там можно что-то выдумать, но по первым впечатлениям вот так - побыстрее, но чуда не случилось, фреймворк всё ещё имеет существенный оверхэд по сравнению с чем-то более нативным.