Тогда расскажешь, какие архитектурные проблемы с промисами?

Вложенность цепочек, многословность

Тогда расскажешь, какие архитектурные проблемы с промисами?

Промис хел который должен был решить калбек хел?

Промис хел который должен был решить калбек хел?

Это слишком сложно, надо сразу 150 к давать за такое.

на всех собеседованиях спрашивали +- то же самое

Меня на Лида собеседуют один из 10 такие вопросы серьёзно, может думают и так знаю хз

Но не джуна про архитектуру)

Вложенность цепочек, многословность

Что мешает не делать вложенных цепочек?

Без обмана самое сложное собеседование на 200к было центровка дива, цикл реакта, пуре компонент, когда редис вызывает колбеки коннекта

Меня на Лида собеседуют один из 10 такие вопросы серьёзно, может думают и так знаю хз

на лида вопросов больше по руководству командой инженеров

redis ?

Без обмана самое сложное собеседование на 200к было центровка дива, цикл реакта, пуре компонент, когда редис вызывает колбеки коннекта

И ещё как правильно юзать транзишены что бы браузер не перерисовывал много лишнего

redis ?

Редукс паднон т9

Что мешает не делать вложенных цепочек?

Апи промисов

А еще фиговая обработка ошибок и промисс алл с его все или ничего)

Апи промисов

Не знаю как у вас у меня и до async и до промисов код был красивый

Апи промисов

Можно пример, чтоб были необходимы вложенные промисы?

Всем привет! Может кто подсказать как подружить React с SEO?

Можно пример, чтоб были необходимы вложенные промисы?

Цепочка последовательных задач

Всем привет! Может кто подсказать как подружить React с SEO?

ssr, pre-render

И ещё как правильно юзать транзишены что бы браузер не перерисовывал много лишнего

Юзать определенные свойства только, которые не вызывают reflow?

Всем привет! Может кто подсказать как подружить React с SEO?

гугл умеет js

Можно пример, чтоб были необходимы вложенные промисы?

В ноде это вообще ад там все асинхронно

гугл умеет js

тестили, все еще криво, с сср лучше индексация

Юзать определенные свойства только, которые не вызывают reflow?

Не сами свойства а метода и вообще подходы, я сказал пас)))

Не сами свойства а метода и вообще подходы, я сказал пас)))

Я бы послушал про это лекцию))

Цепочка последовательных задач

На прошлой неделе писал 6 последовательных задач, всё без вложенных промисов

Я бы послушал про это лекцию))

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

На прошлой неделе писал 6 последовательных задач, всё без вложенных промисов

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

На прошлой неделе писал 6 последовательных задач, всё без вложенных промисов

Ну дак ты там заюзал какой нить паттенр типа series

ssr, pre-render

А на счет пререндера, есть советы, как его реализовать не затрагивая внешние сервисы?

А на счет пререндера, есть советы, как его реализовать не затрагивая внешние сервисы?

Его не тыкал, не подскажу.

Можно пример, чтоб были необходимы вложенные промисы?

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

А на счет пререндера, есть советы, как его реализовать не затрагивая внешние сервисы?

Возможно вам вообще подойдут просто метатеги и дескрипшион с тайтлом. Там гемора меньше.

Возможно вам вообще подойдут просто метатеги и дескрипшион с тайтлом. Там гемора меньше.

Это на крайний случай, вся проблема в том, что на странице большое кол-во контенкта из за этого, думаю, это не особо оптимальный вариант

Тут уже решайте там сами, встраивание сср в готовый проект не самое веселое занятие если впервые

Может вообще nextjs подойдет

Возможно стоит сделать генерацию статики отдельным сервисом, который будет просто делать статические файлы на основе sitemap и по правилу nginx будет отдавать статику соответственно

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

Так появляются посты у которых удаленно половина комментариев

А какие были причины того, что убрали componentWillMount и подобное? Потому что люди неправильно их использовали часто? Или сложнее причина?

Возможно стоит сделать генерацию статики отдельным сервисом, который будет просто делать статические файлы на основе sitemap и по правилу nginx будет отдавать статику соответственно

Вариант имеет место если у вас много статики а не зависит от запросов контент

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

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

Статика - все, что нужно в сео сунуть Динамика там не нужна

Я знаю, я про вилл маунт

Ну тогда уж может и подойдет вариант. Не пробовал к сожалению. У нас много контента от запросов зависит

Может вообще nextjs подойдет

я думаю, что next.js не подойдет из за того, что он вроде не умеет в /page/.* из бд Или я ошибаюсь?

Я его упомянул, тк он самое популярное готовое решение. Я с ним не работал, у нас сср встраивался в летящий на скорости проект.

А какие были причины того, что убрали componentWillMount и подобное? Потому что люди неправильно их использовали часто? Или сложнее причина?

Их не убрали просто обычно все что тебе нужно можно в конструктора сделать

я думаю, что next.js не подойдет из за того, что он вроде не умеет в /page/.* из бд Или я ошибаюсь?

был канал nextjs_ru, возможно там подскажут

Но я думаю он излишен для проекта где в основном статика для сео идет

Их не убрали просто обычно все что тебе нужно можно в конструктора сделать

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

А какие были причины того, что убрали componentWillMount и подобное? Потому что люди неправильно их использовали часто? Или сложнее причина?

Под каждым таким методом есть ссылка на статью с примерами и описанием, почему так не стоит делать

Ностальгия - это когда ты помнишь js без классов.. Эх

Да и щас можно в большинстве кейсов отходить от классов (реакта офк)

А кто нибудь может что сказать про UmiJS для реакта?

Ностальгия - это когда ты помнишь js без классов.. Эх

Все ясно, дед, угомонись)

А на счет пререндера, есть советы, как его реализовать не затрагивая внешние сервисы?

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

Да и щас можно в большинстве кейсов отходить от классов (реакта офк)

Я знаю, просто любопытно

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

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

Все ясно, дед, угомонись)

Слышь, я тебе сейчас за with буду чесать и ie5.5)))

А на счет пререндера, есть советы, как его реализовать не затрагивая внешние сервисы?

Лучше сделай SSR

Я знаю, просто любопытно

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

https://stackoverflow.com/questions/41612200/in-react-js-should-i-make-my-initial-network-request-in-componentwillmount-or-co старый тред, но все же он там отписался

Лучше сделай SSR

Говорю же, на странице может быть >5000 слов, кидать все это в мета тэги, такая себе на мой взгляд идея

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

Да и сделайте так за день точно успеете, ну а если что то не зайдет либо дофиксить либо другое дорогое решение, вот честно скажу ставить на SSR то что не для него писалось ой как нетривиально, ну это моё мнение

Говорю же, на странице может быть >5000 слов, кидать все это в мета тэги, такая себе на мой взгляд идея

Причём тут SSR?

Говорю же, на странице может быть >5000 слов, кидать все это в мета тэги, такая себе на мой взгляд идея

А зачем все эти слова в метатеги?

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

Сорян, черт попутал, а интервал между сообщениями не дал исправится) В любом случае, не хотелось бы нагружать бэк, плюсом есть куча алгоритмов, майнд карт и графиков, которые отрисовываются на JS и писать для них обработчики выглядит не очень веселым занятием Или я опять что то не понимаю?)

Сорян, черт попутал, а интервал между сообщениями не дал исправится) В любом случае, не хотелось бы нагружать бэк, плюсом есть куча алгоритмов, майнд карт и графиков, которые отрисовываются на JS и писать для них обработчики выглядит не очень веселым занятием Или я опять что то не понимаю?)

сср грубо говоря нужен, чтобы ты на ноде прокинул необходимые запросы (если надо), добавил теги/тайтл/дескрипшион или что тебе там нужно, проконтролировал статус ответа если уж надо (редирект с 301/302 например), далее ты уже через ноду отдаешь хтмл, например через renderToNodeStream работаешь с клиентом, то есть с реактом. Ну и вебпак приготовить для бандлов сср + можно отдельную сборку с другими настройками бабеля. Если надо, то делаешь через объект window свойства которые пойдут в редакс или что там у вас. В общем чаще всего все. Еще можно конечно через сср пускать нужные чанки для страницы с оптимизацией, например прелоад/префетч навешивать и тд. Можно еще конечно попробовать разбиение ответа на части, но не в данном случае.

Сорян, черт попутал, а интервал между сообщениями не дал исправится) В любом случае, не хотелось бы нагружать бэк, плюсом есть куча алгоритмов, майнд карт и графиков, которые отрисовываются на JS и писать для них обработчики выглядит не очень веселым занятием Или я опять что то не понимаю?)

Если тебе нужен html для сео его все равно на беке нужно делать

сср у тебя будет своеобразным темплейт бекендом

потому что хтмл отдает)

Вообще какая мысль была Сделать пререндер и отдать эту задачу другому серверу А уже на балансере распределять ботов на сервер с отрендженым хтмл

У вас такой большой поток юзеров?

У вас такой большой поток юзеров?

В любом случае лучше отдельную тачку, сейчас не 1999 год)))

Он предпологается в будущем +ом нас будет куча идиотов с фаззерами спамить из за тематики портала, так что надо им фастом отдавать спа и все)

ну сср позволит с ttfb чуть облегчить судьбу

Он предпологается в будущем +ом нас будет куча идиотов с фаззерами спамить из за тематики портала, так что надо им фастом отдавать спа и все)

Вы задайте себе вопрос насколько сложно в вашем случае будет поднять ssr

Он предпологается в будущем +ом нас будет куча идиотов с фаззерами спамить из за тематики портала, так что надо им фастом отдавать спа и все)

Сделайте отдельные сервера для апи/статики/сср

Сделайте отдельные сервера для апи/статики/сср

так и собираемся, апи, фронт, статика, cdn все на разных серверах

Тогда не понятно, какой бек будет нагружать сср если он будет на отдельном сервере