Зачем нужно генерировать одинаковый DOM на фронте и бэке?

Копипастить что? Что я конкретно должен захотеть копипастить?

Шаблоны. Ты будешь кописатить и поддердивать их консистентность/идентичность между SSR и SPA.

Потом оказывается, что данных этих нужно очень много и начинается не-дублирование через GraphQL, чтобы сэмулировать как бы прямой доступ к БД, но как бы немножко ограниченный. В общем, адаптируем проблемы к решениям

Вот поэтому я и говорю, что ты желаешь выкинуть инструменты прослойки, думая, что все может быть проще. Нет — не может.

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

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

На самом деле в той же Европе

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

при неободимости часть генерации мы переносим на сервер и даже делаем её однократной

Зачем? Разве хоть кто-то так делает?

Делают и много кто. Если ты вообще понимаешь об чём речь.

Если левая часть (hasOAuthProviders) имеет истинное значение

Истинное значение? «моя мама варит кофе» — это истинное значение или же наглая ложь?

иначе результатом выражения будет ложное значение левой части (обычно false/null/undefined/пустая строка), которые React просто пропускает при рендеринге.

true тоже пропускается при рендеринге. Потому что гладиолус.

Есть небольшая засада — 0 тоже ложное значение в булевом контексте, но его React не пропустит, а отрендерит как есть. Мораль сей басни такова — старайтесь использовать в булевом контексте только булевы значения. Если память подводит — используйте TypeScript, он поможет.

Только если strict=true. Но я бы прежде всего советовал не использовать изначально сломанные инструменты.

это истинное значение или же наглая ложь?

Еще бы не доверять бекенду ))

Истинное значение?

Truthy value (всё, кроме false, null, undefined, 0 и "").

true тоже пропускается при рендеринге. Потому что гладиолус

Никогда не имел с этим ни малейших проблем.

не использовать изначально сломанные инструменты

Когда браузеры начнут поддерживать что-то, кроме JS — будем думать. А пока пользуемся тем, что есть.

А логика view где будет в таком представлении? Например блок с пейджером отображать или не отображать? Или по-разному карточка товара рисуется чуть иначе если есть видео с товаром или только картинки

и даже это не проблема, пишем перед проверкой предварительно:

typeof myVar === 'boolean'

и делов.

Еще раз — он пока до этого не домыслил )) Вот щас общую картину в голове построит, тогда и за нюансы сам думать начнет — чай не дурак.

Кажется речь о рукожопии.

В шаблонизаторах обычно и условные операторы бывают. Что-нить типа «если эта переменная пустая/отсутствует то текст такой, если не пустая то такой». Делать ли просто большой if-else вокруг двух вариантов карточки целиком, или же засовывать под этот if отдельные её части - на выбор верстальщика, в зависимости от того что он хочет нарисовать.

Неа ))

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

Гораздо эффективнее отдать закешированные данные о наличии остатков товаров, а не ходить в базу и узнавать, сколько их там реально осталось. Речь, конечно, о кейсах, когда за наличием товара с ID = X ломятся каждые N милли (а может и микро) - секунд. И пусть лучше в момент заказа товара клиент увидит реальный ответ бекенда «ничо не осталось, купить нельзя».

Какие тут рукожопия?

общую картину в голове построит

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

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

Ну и да — я попутал тебя с ТС.

И каким это боком к отрендеренной на клиенте странице?

Тем более, что жс тебе на клиенте всё рисует и серверу пофиг что отдавать.

И каким это боком к отрендеренной на клиенте странице?

Да прямым — чем быстрее оно отрендерится, тем лучше. А уж какими горячими кешпми это реализуется — вопрос реализации.

жс тебе на клиенте всё рисует и серверу пофиг что отдавать

Но жеесу может быть не пофиг, когда надо нарисовать горячий кеш остатков через SSR, а не JSON. Ты же, в дикой природе, только по месту узнаешь, в каком виде и каким образом бекенд что-то там отдает.

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

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

Да вообще плевать. Я говорю о том, что не важно какие прослойки логики и как они в итоге рисуют, важнее тут, что способов кеширования и отрисовки «тыща и одна тележка».