Как обратиться к root шаблону из компонента в NUXT?

Евгений, ну так ты везде писал this.$root.foo, теперь везде будешь писать import foo from './helpers' или типа того. Если это всё меняется в зависмости от лэйаута, то тогда везде писать inject, да. Можно ещё голбальный mixin зафигачить...

Как передать на бекенд требования к API?

Антон Бреславский,

Оно было изначально.

Если оно было - оно было. Duh.
Аналитик должен был описать требуемый функционал.

Есть агрегация сложная, сделай слой и храни в мемкеше.

Если нет хлеба - пусть кушают пирожные.

Вы же понимаете, что подобные заявления заставляют меня склоняться на сторону Agent Smith ?)

Как получить состояние промиса?

Надим Закиров, ты пилишь не велосипед, ты пилишь костыль.)
Потому что задача, которую ты хочешь решить этим способом, вестимо, правильно решается каким-то иным.)

Как передать на бекенд требования к API?

Антон Бреславский, что значит требование заказчика? Это требование было в ТЗ, но архитектура не предусмотрела? Косяк архитектора, как я и написал.
Требования не было в ТЗ? Заказчик идёт нахрен или заключает новый договор на много денег, т.к. данное изменение требует переработки архитектуры. Не вижу ничего необычного.

А качество вашей архитектуры зависит от вашего архитектора и к теме не относится. И это не архитектура завязана на REST, а возможный REST завязан на архитектуру. Что-то сделать можно, что-то нельзя. Универсальности не существует.

Будет он каждый раз дергать запрос и 1 000 000 строк или сделает слой.

Я видел такие вещи. Нет, спасибо.
Впрочем - "заказчик хавает", да. До поры. Но нормальный бэк от вас уйдёт.

Как передать на бекенд требования к API?

API это больше чем данные

^this

API это отражение архитектуры. Определённые данные в определённой архитектуре можно получать только определёнными путями.
Утрируя: для фронта это разница меж /get/uuid и /uuid/get, для бэка это полная переделка всего кода или костыль с вытягиванием половины базы на каждый запрос.

Бэк (а точнее Архитектор, но архитектор - всегда как минимум бэк) продумывает архитектуру для оптимального выполнения задачи. От этой архитектуры строится API. Если API не слишком удобно для фронта, но с ним можно жить, это нормально. Если в API не хватает чего-то и это не предусмотрено в архитектуре, но подразумевается задачей - архитектор накосячил и надо всё переделывать(или писать костыли).

Если изменения для удобства фронта вписываются в архитектуру без излишних костылей, но неудобны для бэка - вопрос для обсуждения.
Если изменения для удобства бэка вписываются в архитектуру без излишних костылей, но неудобны для фронта - вопрос для обсуждения.
  
  

Вы на беке дадите добро или внесете изменения и у вас будет контракт с фронтами.

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

Как передать на бекенд требования к API?

Антон Бреславский, у фронта есть дофига чего пилить без бэка. Пока они это напилят - бэк обычно успевает подъехать.)

А формализовать можно, только это выльется в тысячу митингов и пересогласований, пока не устаканится в действительно рабочем варианте. Потому что бэк всё равно так или иначе должен продумать архитектуру, только теперь пытаясь её уродовать, вписывая в бессмысленные требования, взятые с потолка, а не из задачи. Т.е. просто выкидывание времени в трубу и ухудшение конечного результата.

Как передать на бекенд требования к API?

Антон Бреславский, что вы упёрлись в этот дизайн? Дизайн решает задачу, фронт решает задачу, бэк решает задачу. Это всё производное от ЗАДАЧИ. И бэк делает ядро: бизнес логика, хранение, производительность и т.д. и т.п. От бэка зависит всё остальное. Да, даже дизайнеру придётся свой креатив перерисовать, если что-то сделать на бэке по той или иной причине невозможно.

Смапить предоставленный бэком API на дизайн - задача фронта. Если дизайн не расходится с поставленной задачей - API будет подходящим. Если чего-то (удобного в конкретном кейсе) не хватает - задача фронта обсудить это с бэком, я не зря включил этот пункт в ответ.

А для прототипа достаточно интерактивной фигмы.)

Как передать на бекенд требования к API?

Антон Бреславский, я фронт, мне нифига не понятно что там дизайнер нарисовал.)
За каждой кнопкой и формочкой скрывается логика. Которая должна быть расписана аналитиком без разночтений.
Это верно для чего угодно сложнее лендинга.

Бэк делает логику. Не api - логику. Api - следствие логики и архитектуры, не наоборот. Сколько раз вам ещё повторить?

Как передать на бекенд требования к API?

Антон Бреславский, про дизайнера - нет. Ни фига не понятно, что он там нарисовал и какая там логика кроется за каждой кнопкой.

Без ТЗ - результат ХЗ.

Про редактор - врядли. Я не верю, что он будет удобным. Просто не вижу вариантов. Если вдруг - то вдруг, но не тыкая руками тут ничего не скажешь.

Как заменить имена пользователей на вёрстку при рендеринге элементов массива?

Роман, https никак не решает проблему xss. Вообще разные вещи.

Да даж еслиб проблем с xss не было, что-нить типа следовательно: a<c случайно в коде, и тебе развалило страницу.)

Пользователь заблокирован, как разблокировать?

kaktak255, под рутом тебе не нужен sudo.
У всех команд что нагуглил просто убери sudo в начале.
Ток за исполнение этих команд я не ручаюсь.)

Как заменить имена пользователей на вёрстку при рендеринге элементов массива?

Роман, ток ты учитывай, что решение 0xD34F фигачит всё как html. Соответственно, если там попадутся теги, то будет грустно.

Как передать на бекенд требования к API?

Антон Бреславский,

каркас кода и DTO.

Абсолютно бессмысленный. Невозможно придумать (адекватно) архитектуру от API, а не от задачи.

Писать JSON или Swagger - получается только вопрос удобства?

Коротко: да.
Развёрнуто: если б меня лично заставили писать свагер руками я б послал тимлида нафиг. Если настаивали - уволился. Не переношу мартышкин труд. То что может быть автоматизировано - должно быть автоматизировано.
Потенциальная "потеря времени" на мелкие правки и нестыковки простых json-моков, как по мне, куда меньше, чем потеря времени на ручную работу со свагером.
Допускаю, что есть какие-то мега-сложные задачи с мега-сложны API где это было бы оправдано, но я такого не встречал.

Как передать на бекенд требования к API?

Антон Бреславский, не, абсолютно нереален.)
На клиенте из сваггера генерируется просто запросы, а на бэке вы что собрались генерировать? Методы класса? Которые потом бэк должен как-то "заполнить кодом", чтоб оно работало?)

Как передать на бекенд требования к API?

Антон Бреславский, нет никакого "реального времени". Бэк должен сначала продумать архитектуру, условно-целиком в рамках задачи, но точно без пробелов, потом начать реализацию. То что он продумал он может быстро кинуть в виде json либо потратить кучу времени запилив целый сваггер, который в итоге сам потом сгенерируется из его кода.

Т.е. ещё раз: бэк не придумывает API. Бэк придумывает архитектуру, API - это следствие архитектуры. Нельзя придумать API без готовой архитектуры.
Ну, т.е., конечно, можно, но это приведёт к адским костылям и ужасам на бэке, так что лучше не надо.)

Как сделать рекурсию в js await функции?

Сергей Соколов, не стоит того.)
Можно ещё так, ага:

let result;
while(result = !await this.download());

Даже так, судя по примеру:
while(!await this.download());
=)

Как исправить chrome dev tools?

iBird Rose, да вроде уже обещали пофиксить в следующем выпуске.

Как поменять state не из компонента?

Да, только из отдельного файла и в index и в api, чтоб не было циклических ссылок.

Проблемы с командой: npm run serve?

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

Как защитить переписку от MITM атаки?

Mike, это очень нишевая атака, но суть не в этом. Уязвимости есть во всём. Что бы вы не использовали, нет никакой разницы с TLS: уязвимости находят, их эксплуатируют, их закрывают.
- TLS - дыры ищут гораздо больше народу.
+ TLS - дыры закрывают гораздо быстрее.