Как организовать взаимодействие бэкенда и фронтенда?

@Kentavr16
Стек - next/nest/mysql.
Под вложенными объектами подразумеваю ответ от сервера в формате:

// alerts
  [
    {
      id: '1',
      name: 'test1',
      isActive: false,
      alertTemplate: {
        id: '5',
        name: 'alert template',
        width: 800,
        height: 600,
        imageTop: 100,
        imageLeft: 300,
        ...
      }
    },
    {
      id: '2',
      name: 'test2',
      isActive: false,
      alertTemplate: {
        id: '7',
        name: 'alert template2',
        width: 800,
        height: 600,
        imageTop: 100,
        imageLeft: 300,
        ...
      }
    },
  ]

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

Разделение ответственности или производительность?

Ипатьев, в случае с отдельным созданием юзера и поста. Если к примеру юзер создался, но создание поста зафейлилось - тогда нужно ещё получается писать логику что бы удалить ранее созданного юзера, т.к. юзкейс по сути завалился?

Разделение ответственности или производительность?

наскролько я понимаю, `prisma.user.create ... ` под капотом делает что-то подобное:

INSERT INTO users (username, password, email) VALUES ('username', 'password', 'email');
INSERT INTO posts (user_id, title, content) VALUES (LAST_INSERT_ID(), 'title', 'content');

Разделение ответственности или производительность?

mayton2019, все равно же сохраняется необходимость дублировать notificationService.notify(...);.
как правильнее было бы поступать если условно есть 10 сценариев по которым создается пост (автоматическое создание при регистрации, создание самим пользователем и еще кучка каких-то абстрактных юзкейсов). Тогда тоже в каждом из этих сценариев дублировать вызов notificationService.notify(...)?

Разделение ответственности или производительность?

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

Синглтон или обычный объект?

В рамках жс, что класс, что обычный объект нужно брать, импортить в файл и разве что у класса потом нужно ещё создавать инстанс. Это с другими языками такая особенность, что классы можно не передавать?

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

Немного ломается решение в ситуации когда высота иконки больше высоты строки, но конкретно в моём случае (да и думаю в большинстве) это решает проблему, спасибо.

Когда создавать служебный блок в БЭМ?

Lord_Dantes, с этим моментом согласен, но всё же ключевой вопрос по итогу это .blog-hero-grid__item или .blog-hero__grid-item? т.к. __grid__item с БЭМом особо не сходится.

Как можно аккуратнее структурировать файлы в проекте (vue)?

Roman Kitaev, хоть и не мне вопрос адресован, но тут явно, components/ComponentName было приведено просто для примера. Понятное дело, что в проекте может быть уйма папок, подпапок и т.д. Но суть в том, что он создаёт для каждого компонента свою папку.

Как вынести выполнение скрипта в отдельный поток?

Ярослав Иванов, не до конца описал ситуацию, там происходят вычисления путей в svg и, к сожалению, на бэке это не реализовать, так что буду разбираться с использованием вебворкера, но в любом случае спасибо за ответ.

Сочетание БЭМ и Vue?

Aetae, благодарю за ответ. То есть как я понял, использование класса с display: none всё же иногда можно считать уместным, когда, как в примере, есть необходимость скрыть сразу определённое кол-во блоков?

Сочетание БЭМ и Vue?

Я обычно навешиваю классы на компоненты для добавления им margin-padding и иногда, дабы пробраться по селекторам вниз и изменить какие-то размеры для единичных случаев, не знаю, правильно ли такое применение, но вроде как самый удобный и простой вариант (:

А вот в такой ситуации, по идее удобнее будет просто не отображать картинки через модификатор?

Сочетание БЭМ и Vue?

Арсений Матыцин в этой ситуации, это допустимо будет?

Когда стоит применять em вместо rem?

Арсений Матыцин, благодарю за уделённое время, я писал rem = 10px, опираясь на практику когда f-size ставят 62.5% для простоты вычислений. Попробую всё же тогда всё перегнать обратно в rem'ы, верстать по аналогии к пикселям и ждать момента когда во время адаптива замечу что большую часть элементов можно пропорционально уменьшить.

Спасибо ещё раз за ответы, примеры и помощь в целом.

Когда стоит применять em вместо rem?

Арсений Матыцин, em я вроде как смог корректно применить, т.к. была ситуация где нужно было псевдоэлементом установить иконку перед текстом и там соответственно нужно было двигаться в зависимости от шрифта.

Но касаемо ремов всё ещё не до конца въехал в практическую пользу (честно говоря в проекте уже пару раз перегонял единицы измерения туда - сюда из-за как раз таки непонимания).

К примеру возьмём rem = 10px. Есть секция, у неё изначально вертикальные отступы по 100px, в ней есть h1 размером 70px и p размером 16px.

На мобильном экране это должно превратиться в отступы по 40px, h1 в 35px и p размером 14px. Как я понимаю, в этой ситуации какого-то особого выигрыша от rem мы не получаем. Т.к. если сделать rem = 5px, абзац будет корректным, но параграф и отступы всёравно нужно прописывать вручную и как понимаю прибегнуть нужно будет всё к тем же пикселям, т.к. отсчитывать от 5rem будет не особо удобно.

В такой ситуации rem не особо нужны? Или их всё равно желательно использовать, но в каких-то моментах просто перегонять в пиксели? Если значение, допустим, не должно изменяться и т.д.

// Надеюсь не запутал вас больше своего (:

Когда стоит применять em вместо rem?

Арсений Матыцин то есть, по сути, принцип вёрстки остаётся такой же как и на пикселях? К примеру, если мне нужно в каком-то отдельном блоке уменьшить отступы - я уменьшаю/увеличиваю значение, которое указано в rem. И получается преимущество предоставляемое ремами лишь одно - масштабируемость по одному параметру? Просто, как мне кажется, далеко не всегда возникает необходимость изменить размер сразу всего в определённой точке, или же мне неправильно кажется?)

Когда стоит применять em вместо rem?

Антон Литвиненко, и можно ещё небольшой момент, можно ли это утверждение считать верным и пример корректным? (в моем случае разделение на компоненты присутствует)

Когда стоит применять em вместо rem?

Антон Литвиненко, т.е. всё преимущество вёрстки в ремах сводится к возможности изменить весь макет, меняя корневое значение? Просто, как мне кажется, это далеко не всегда необходимо.

Когда стоит применять em вместо rem?

И опять же, вёрстка сделанная полностью на rem. Это подразумевает что если в каком-то конкретно случае нужно уменьшить у блока отступы и font-size, то это необходимо каждому свойству прописывать уменьшенные значения?

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

// извиняюсь за возможно весьма глупые формулировки, но просто у меня есть по отдельности понимание что делает rem, что делает em, но всё никак не состыкуется в толковое понимание где, какие единицы корректнее будет применять.

Как избавиться от длинного имени класса БЭМ?

А имеет ли право на жизнь подобный вариант? Т.е. не бить на блоки составляющие, а делать дерево с одноуровневой вложенностью? (ihorzenich.github.io/talks/bem-frontendweekend/?full#61)

<div class="text-image-table">
    <div class="text-image-table__row">
      <div class="text-image-table__text-blocks">
        <div class="text-image-table-text-block">
          <div class="text-image-table__title"> text </div>
          <div class="text-image-table__description"> text </div>
        </div>
      </div>

      <img class="text-image-table__img" :src="block.imgURL">
    </div>
  </div>