« Rev
@react_js   387
Fwd »


Bogdan
скинь код и покажи где проблема
Но суть в том, стор в контексте, методы тоже, в табах дёргаю их
Anonymous
я хз какие у тебя там проблемы могут быть )
Anonymous
я не вижу кода
Anonymous
но как я делаю: Провайдет с контекстом и вся бизнесс логика Контейнер, который инжектит стор, создает функции-обвертки для функций из функций контекста. Эти функции обвертки передаю глупым компонентам, которые при ивенте просто вызывают эту функцию из пропсов, передавая туда максимум value какое-то или index
Anonymous
Можно как-то визулизировать дерево компонент если у меня куча наследоваемых компонент, чтобы не запутаться? Что-то для иде визуалстудиокод например
Whole Enchilada
Ребят, а накиньте пожалуйста статей про "не мутить огромные сторы без необходимости и использовать локальные объекты"? Можно на английском
https://kentcdodds.com/blog/application-state-management-with-react Keep state as local as possible and use context only when prop drilling really becomes a problem.
artalar
=\
Andrei
=\
Плохая статья?
artalar
Плохая идея, по моему мнению)
Andrei
А, ну да
Andrei
Так себе
Andrei
Не дочитал про prop drilling
Whole Enchilada
какая идея?
artalar
Я предпочитаю хранить в глобальном сторе как можно больше и оставлять минимум на локальный
Whole Enchilada
и чем эта идея хороша?
Whole Enchilada
если сильно завязываться на глобальный стейт, то это делает компоненты сильно связанными и неудобными для переиспользования
Whole Enchilada
и провоцирует плохие практики прокидывания данных через инжект внизу иерархии
Anonymous
может кто из админов забанить mobe
Anonymous
не палюсь с меншном
Anonymous
спамят по поводу upwork аккаунтов
Oleg
Я предпочитаю хранить в глобальном сторе как можно больше и оставлять минимум на локальный
А как относишься к идее одной модели для элементов списка и карточки? То есть, есть список данных. И есть подробный просмотр для каждого элемента. У элемента списка 10 полей в объекте. У подробного +30 полей. Имеет ли смысл держать одну модель данных для элементов списка и карточки или же логичнее сделать 2 модели, где вторая будет расширять первую?
Oleg
Данные подгружаются из бэка
Oleg
Для листинга массив из объектов по 10 строк. В карточку - при заходе, объект из 40 строк
Teslachok
У меня одного умер гитхаб?
Teslachok
Проверьте, пожалуйста, кто из Москвы
Victor
Данные подгружаются из бэка
если из бека сразу приходят 40 полей, то куда ты их денешь, если не собираешься держать в сторе? не слать же запрос ради этого
Anonymous
чтоб при смене на карточке/на списке произашла смена на списке/в карточке и не пришлось делать велик с двусторонним обновлением
Oleg
если из бека сразу приходят 40 полей, то куда ты их денешь, если не собираешься держать в сторе? не слать же запрос ради этого
С бека в листинг приходит массив с объектами по 10 полей в каждом, ровно то, что нужно для листинга. А для карточки - 40 полей, ровно для данной карточки. Из которых 10 пересекаются с листингом
Oleg
Просто тут чел топит, что раз это один раздел, то и модель должна быть одна, невзирая на представление
Oleg
Типа отделять бизнес-логику от вью
Anonymous
Просто тут чел топит, что раз это один раздел, то и модель должна быть одна, невзирая на представление
хз что подразумевается под "модель", да данные будут лежать в одном месте
Oleg
Но с другой стороны - нахрена мне замудренный массив с кучей пустых полей в листинге
Anonymous
просто когда придет "добавочка" с сервера, то эти данные нормализуются и лягут к остальным
Oleg
просто когда придет "добавочка" с сервера, то эти данные нормализуются и лягут к остальным
Так не проще их держать отдельно в модели, где они будут заменяться на другие при переходе по карточкам?
Anonymous
Речь про мобикс, глобальный стор
если mobx то они не рекомендуют нормализовывать данные и юзать стейт как своеобразную "бд"
Anonymous
чето видел такое прям в доке
Anonymous
https://mobx.js.org/best/store.html
Anonymous
вот тут It is recommended to store your data in denormalized form. There is no need to treat your client-side application state as some kind of database
Anonymous
так что судя по всему bestPractice - хранить 2 модели
Oleg
То есть одна модель с кучей пустых строк для листинга? И расширять те объекты из массива, которые получают расширенные данные при переходе к ним?
Oleg
Вот я тоже за это
Oleg
Это ж логично, да и наглядно: конкретно получаешь данные конкретного набора, так зачем мешать все в кучу
Anonymous
Это ж логично, да и наглядно: конкретно получаешь данные конкретного набора, так зачем мешать все в кучу
если хранить в редаксе, то лучше нормализовывать, сверху накатывать reselect и делать гранулярные выборки из общей кучи
Anonymous
Почему? Ведь тоже можно сделать просто два объекта
потому что при смене на карточке, нужно поменять те же данные во всех местах, где они хрянятся, т.е все эти места нужно щемить руками (а их может быть не 2). Это стандартная проблема FLUX-like сторов
El
Приветствую. Можно так передавать в компонент приходящий от родителя параметр formData? const ProfileForm = ({ formData = {}, edit, history }) => { const [formData = formData, setFormData] = useState({...)} ... )}
Whole Enchilada
Если данные редактируются, то проще в одном месте держать, чтобы не заморачиваться синхронизацией. Если нет, то как удобней.
Whole Enchilada
Нормализация в БД нужна, чтобы единый источник истины был и не было таких случаев, что здесь одно, а там другое и хрен его знает где верно.
Pan
Как я могу поменять стиль блока в зависимости от роута?
Anonymous
Как я могу поменять стиль блока в зависимости от роута?
у тебя в компонент завернутый в <Route> приходит match, можно от него плясать
Anonymous
а более жизнерадосные способы?
а чем тот, что я тебе предложил плох? насколько абстрактно спросил - настолько абстрактный ответ
Anonymous
не нравится так, на dm window.location парсь ручками))
Anonymous
возможно готовое решение придумали уже)) зачем костылить
у реакт-роутера есть withRouter, это хок который пробрасывает все что и Route в компонент, юзай его и там по кондишну накидывай стили, можно хук написать который стили менеджит
Pan
не нравится так, на dm window.location парсь ручками))
ну окей, а вставлять <style> в нужный компонент и просто !important не вариант ?
Dmitriy
Как я могу поменять стиль блока в зависимости от роута?
а приведи пример ? стиль-роут \ стиль-роут
Anonymous
ну окей, а вставлять <style> в нужный компонент и просто !important не вариант ?
ты не описал что у тебя со стилями вообще, отдельно они, sc, или еще что-то, типа css-modules
Bogdan
immer юзал кто? там можно обьекты по ключу пушить в массив или свое делать?
Pan
ты не описал что у тебя со стилями вообще, отдельно они, sc, или еще что-то, типа css-modules
допустим надо изменить свойства <body> в нужном компоненте тег не доступен. поэтому надо как-то как есть
Pan
недоступен потому что body?
недоступен потому что в другом компоненте на ряд выше
Anonymous
недоступен потому что в другом компоненте на ряд выше
https://stackoverflow.com/questions/25474803/trying-to-use-react-dom-to-set-body-styles
Pan
https://stackoverflow.com/questions/25474803/trying-to-use-react-dom-to-set-body-styles
впрочем, то что искал это нормально будет так большое кол-во css менять?)
Dmitriy
впрочем, то что искал это нормально будет так большое кол-во css менять?)
так нужно делать если разметка за приделами реакт контейнера
Pan
подход мягко говоря дерьмовый
мягко не мягко, лучше чем предыдущие пока
Anonymous
мягко не мягко, лучше чем предыдущие пока
так а в чем проблема держать какой-то враппер внутри реакта и его стили менть?
Pan
так а в чем проблема держать какой-то враппер внутри реакта и его стили менть?
как-то громоздко мне кажеться ну я хз честно говоря вы предложите, а я поищу инфу))
Dmitriy
da
https://reacttraining.com/react-router/web/api/withRouter сделай компонент обертку и прокидывай стили к целевому компоненту. Почему не нравится подход?
Sergey
Народ, читаем ThisWeekInReact. https://t.me/this_week_in_react/261
« Rev
@react_js   387
Fwd »