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

Зачем лишняя прослойка с хромом?

что бы не нагружать фронт

Парни а что поставить на SSR это что дело одного дня, по-моему если есть проблемы с приложением откуда данные берет и как написано там будет сложно немного

Я даже думаю что иногда поставить на ССР почти тоже самое что с нуля делать... Поправьте меня

Парни а что поставить на SSR это что дело одного дня, по-моему если есть проблемы с приложением откуда данные берет и как написано там будет сложно немного

Re: прокоменьте это сообщение)))

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

Парни а что поставить на SSR это что дело одного дня, по-моему если есть проблемы с приложением откуда данные берет и как написано там будет сложно немного

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

Зависит от объема приложения и от опыта с таким работать.

Не особо. Если твой сср касается кусков кода браузер апи, то можно подрубить env для проверки окружения, то есть банально сср щас или нет, то выполняем N сценарий

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

Если с локал сторами, то например export const LS = { get: token => process.env.BROWSER && localStorage.getItem(token), set: (token, value) => process.env.BROWSER && localStorage.setItem(token, value), };

Вот такой вопрос, а что можно взять из локал сторейджа, что помешает сср? Ну возьмешь ты профиль юзера/личные настройки/цвет темы после сср и перестроишь страницу если нужно.

Локалстор невозможен в рамках ноды

Он просто тупо встретиться в твоем коде и будет как udnefined

Ну дак проверяй андефайнед он или не. Или доп методы добавь для сср.

Не особо. Если твой сср касается кусков кода браузер апи, то можно подрубить env для проверки окружения, то есть банально сср щас или нет, то выполняем N сценарий

То есть у тебя будет какой нибудь process.env.BROWSER и с ним уже пляшешь

Ну дак проверяй андефайнед он или не. Или доп методы добавь для сср.

Я вроде этот кейс выше уже рассказал же 🙂

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

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

Это правильный код? Я из старого массива удаляю нужны элемент и старый массив копирую и возвращаю новый массив на стейт

Это правильный код? Я из старого массива удаляю нужны элемент и старый массив копирую и возвращаю новый массив на стейт

Это правильный код? Я из старого массива удаляю нужны элемент и старый массив копирую и возвращаю новый массив на стейт

Можно проще: this.setState({todoData: this.state.todoData.filter(e => e.id !== id)})

Нет. Ты всё равно мутируешь старый массив

у него тогда массив будет с одним элементом который он удалить хочет) !== надо)

Можно проще: this.setState({todoData: this.state.todoData.filter(e => e.id !== id)})

Может скопировать сразу массив, а потом удалить элемент из нового массива и вернуть его в стейт

Можно проще: this.setState({todoData: this.state.todoData.filter(e => e.id !== id)})

Так уже лучше, но для таких целей как раз и придумали filter, юзай его

Всем привет, SSR актуальная вещь в реакте на сегодня?

нада 🙂 в других ситуациях либо page либо url и там свои отличия есть

Всем привет! Вопрос по архитектуре приложения. Есть 3 таблицы: марка автомобиля, модель автомобиля и запчасти для каждой модели. Нужно сделать поиск по марке, затем после выбора марки отображать модель, затем после выбора модели отображать запчасти для этой модели. Как лучше организовать компоненты и роутинг? 1. Все компоненты (Марки, Модели, Запчасти) расположить на одном уровне и роутером перенаправлять между компонентами, передавая ID в url. Смущает передача ID через url. 2. Расположить компоненты внутри друг друга: Запчасти внутри Модели, Модели внутри Марки. И передавать ID как параметр. Не понятно как при этом по uri /<Марка>/<Модель> сразу открывать нужную страницу с моделью авто. Что посоветуете?