увы действительность такова что иногда приходится под заказчика под конкретную фиксированную версию писать

FF44

блять)

это шиза, фф не привязан к системе и обновляется

FF44

Там нет let/const?

for(const item of ... уже не работает

Я бы не стал кидать это в стор. Я сделал бы все в рамках одного компонента контейнера

это шиза, фф не привязан к системе и обновляется

зависит от операционки

при ssr как вы боритесь с ошибками импорта svg?

при ssr как вы боритесь с ошибками импорта svg?

const Icon = () => ( <svg></svg> )

при ssr как вы боритесь с ошибками импорта svg?

а в чем проблемы-то?

Хотя бы esr версию бы взяли.

а в чем проблемы-то?

бабель-нод видимо, он только js/json импортировать умеет

бабель-нод видимо, он только js/json импортировать умеет

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

))

я юзал svg-react-loader но когда начал делать сср посыпались ошибки с свг

юзаю сср без вебпака

напрямую подключая бабель

require('url-loader'); require('file-loader'); require('css-modules-require-hook/preset'); require('@babel/register')({ ignore: [ /(node_modules)/ ], presets: ['@babel/preset-env', '@babel/preset-react'] }); require('./server.js');

оно понятное дело не взлетает с свг

с этой штукой

https://github.com/airbnb/babel-plugin-inline-react-svg

куча ошибок

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

кто что думает ? хоть кто то смог отказатся ?

Многие — это кто?

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

Если не уверен как это сделать - лучше не надо. Но стремиться стоит

Многие — это кто?

?

?

даешь доклад!)

c babel-node такая же беда (

[nodemon] starting babel-node ./server/index.js --presets @babel/preset-env,@babel/preset-react SyntaxError: Unexpected token <

?

это ж надо министорчики типа эффектора юзать. Иначе ж свалка будет

даешь доклад!)

https://youtu.be/udNHwANuicU

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

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

Если не уверен как это сделать - лучше не надо. Но стремиться стоит

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

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

консистентность

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

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

Добавить параметр к методу же проблема. Надо редюсер поправить, saga, connect и еще чего. И ради чего? Что бы сохранить состояние нового контрола?

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

а зачем тебе нужна консистентность чекбокса ? когда в стейт все просто. человек перешел по приложухи и у него все очистилось

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

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

Ну понятно все от проекта зависит

Сейчас на нативном контексте вполне хорошо жить можно

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

?

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

Че у себя юзаешь для хранения стейта?

Пропс хелл в крутом проекте меняется на контейнер хелл

Че у себя юзаешь для хранения стейта?

у меня выбора особо нет, редакс...

Пропс хелл в крутом проекте меняется на контейнер хелл

и это норм

и это норм

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

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

Состояние всяких кнопок, слайдеров, чекбоксов, селектов удобно хранить в локальном состоянии но до первой задачи от заказчика когда нужно сохранить состояние раскрытого слайдера или положения фильтров на сервере чтобы у юзера при перезагрузке ничего не сбрасывалось или он например захочет продолжить потом какую-то работу на телефоне. Или например бывает удобно сначала сохранять состояние формы локально а потом приходит задача мол давай на другой странице добавим уведомление что пользователь не сохранил форму и заодно сохранять это на сервере на случай если он зайдет с другого устройства. В результате приходится много чего менять когда изначальное хранение этого состояния в редаксе упростило бы добавление новых фич. И мне кажется есть тенденция хотелок заказчика выносить все больше состояние на сервер (типа "а давай для удобства и это сохранять на сервере и это") то в итоге хранить сразу все состояние в редаксе для сильно интерактивных приложений может сохранить много головной боли потом когда появятся новые требования доступа к этим данным из других частей ui или синхронизации этих данных с сервером

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

используйте что вам удобно, не забывая о дальнейшей поддержке, если она нужна ?‍♂️

используйте что вам удобно, не забывая о дальнейшей поддержке, если она нужна ?‍♂️

Да я то контейнеры юзаю)

Посоветуйте аналоги удобнее redux-form ?

final-form

С ридакс из коробки работает или надо вручную диспатчить?

С ридакс из коробки работает или надо вручную диспатчить?

Работает отдельно от редакс

Вообще идея в том что не нужен редакс

Ну можно тогда локал Стейт компонента использовать). Через файнлформ уже производить авторизацию, валидацию и тп

Там и так все хранится в стейте формы. По опыту профита от хранения в сторе не разу не было от редакс формы

привет! такая ситуация, есть метод который контретный объект, например products/:id я правильно деалю что пишу метод прам в контейнере, просто не вижу смысла писать экшн, мне надо просто удалть и сделать редирект назад, и не знаю что менять в сторе, или я не прав???

очень не понятно

есть такой метод api.delete(`${endpoint_object}/${id}`) я его написал прям в ObjectContainer не стал писать в редаксе и создавать для него экшн

че?

А вдруг с сервера прийдет кака

ну типа там же проверка if statuw === 200

ERROR: S client not available

а мидлверы нет никакой?

привет! такая ситуация, есть метод который контретный объект, например products/:id я правильно деалю что пишу метод прам в контейнере, просто не вижу смысла писать экшн, мне надо просто удалть и сделать редирект назад, и не знаю что менять в сторе, или я не прав???

Ну по крайней мере надо еще ошибку обработать правильно. Если это в сторе хранится, то удалить

Подскажите норм календарь, чтобы с styled-components заюзать

Подскажите норм календарь, чтобы с styled-components заюзать

Rc calendar посмотри

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

и через стейт бросать пропсы в новую страницу

Контекст ?

Как в принципе этот момент должен быть правильно реализован?

Есть таблица, в ней есть "роу", в каждом "роу" есть пропсы

В роу выводится инфа о юзере

При клике на имя открывается детальная страница юзера, в которую надо кинуть все пропсы, которые хранятся в роу

@popuguy

При клике на имя открывается детальная страница юзера, в которую надо кинуть все пропсы, которые хранятся в роу

Вообще через линк реализовывают

Таким образом?

Либо ты прокидываешь id пользователя, а в детальной инфе дёргаешь апи

Не, почитай про query params

АПИ, которая возвращала бы инфу юзера по ид, к сожалению нет

Хорошо, спасибо

Привет. Пытаюсь создать проект create-react-app front, но выходит ошибка error Couldn't find any versions for "@babel/parser" that matches "^7.1.3". и все завершается.

create-react-app -v -> 1.5.2

А фронт зачем писать?

Бабел раньше стоял?Возможно старая версия,но врятли,т.к пакет сразу качает все

Возможно у тебя где-то выше в пути есть папка node-modules в которой прописана кривая зависимость

Возможно у тебя где-то выше в пути есть папка node-modules в которой прописана кривая зависимость

да, есть. express

положи фронт не в подпапку а рядом, а еще лучше в отдельную репу

понятно, спасибо

хотя скорее всего дело не в этом, просто кто-то что-то сломал в зависимостях

Rambler meetup есть кто?

Rambler meetup есть кто?

Да

Хорошо, спасибо

Ещё над рендер пропс подумать можно

|| null, а потом два шага делаешь по вложенности, збс