Пиздец

Пиздец

У меня кнопка логаут может быть завёрнута в контейнер.

У меня кнопка логаут может быть завёрнута в контейнер.

мог бы написать “ой все”

ты либо объясни свою позицию, либо не ной ?

а вот зачем пишут Container в конце компонента? я просто реально не врубаюсь ?зачем когда читаешь код знать это

Это я для понятности написал.

import wtfReducer from 'wtfReducer'

чем это лучше import wtfReducer from 'reducers/wtf'

а что вообще тестируют в реакт приложениях?

чем это лучше import wtfReducer from 'reducers/wtf'

Ничем. Но мне ништяк.

чем это лучше import wtfReducer from 'reducers/wtf'

компоненты

например чтобы на пропсы правильно реагировали?

так же как и в реляционных базах делаются связи, через поле, например с id

Ещё бы язык запросов для такого придумать, было бы супер

https://github.com/tonsky/datascript же)

Дело не в самом болерплейте, мобикс в отличии от редакса предлагает уникальные фичи при работе с состоянием - возможность создавать ссылки между объектами а если вкратце то а это позволяет удобно работать с состоянием приложения как с бизнес-сущностями. Например есть такая бизнес-логика обычного приложения менеджера задач - у юзера может быть много папок, у каждой папки может быть много проектов, у каждого проекта может быть много тасков и у каждого таска может быть много комментариев и каждый комментарий также может иметь много реплаев (получается дерево комментариев) и соотвественно каждую сущность можно создать, отредактировать или удалить. С мобиксом как мы описали бизнес-сущности и связи one-to-many или many-to-many, так мы и и храним - объект юзера хранит массив объектов-папок, внутри папки будем хранить массив объектов-проектов, внутри проекта будем хранить массив объектов-тасков а в объекте таска будем хранить массив объектов комментариев и внутри каждого объекта комментария храним также массив других комменатриев-реплаев. Создавать редактировать или удалять сущности очень просто - для создания просто создаем объект и пушим в массив, для удаления делаем сплайс из массива для редактирования просто изменяем одно свойство и вот таким одинаковым образом работаем как с папками так с проектами так и с более глубокими сущностями И самое главное эти сущности могут быть связаны между собой что упрощает логику в обработчиках. Например когда рендерим таски в компоненте проекта <div>{project.tasks.map(task=><Task task={task}/>)}</div> то получив в компоненте Task через пропсы только нужный объект состояния (в данном случае task) часто бывает нужно обратиться к свойству какой-то родительской сущности например project (чтобы например проверить тип или какой-то свойство перед редактированием). И тут конечно можем выдумывать различные костыли передавая через пропсы также объект project и другие родительские сущности (а это может повлечь за собой изменение других родительских компонентов) а можем просто при создании таска добавить свойство project и записать в него ссылку на проект и обратится к свойству просто через task.project.someprop. В итоге взяв за правило при создании любой сущности записывать в свойство объекта ссылку на родительскую сущность можно очень удобно обращаться ко всему состоянию независимо от уровня вложенности например получив через пропсы комментарий можно обратится к папке в котором находится комментарий - comment.task.project.folder.name и это не потребует изменения всех вышестоящих компонентов. А теперь попробуйте ответить на вопрос как бы вы разрабатывали такое приложение используя редакс? Сколько редюсеров бы вам понадобилось? Как работали бы со связями one-to-many? Особенно интересует момент с добавлением и обновлением вложенных сущностей и особенно с деревом реплаев к таску и также интересен момент когда нужно обратится к родительским сущностям в компоненте получив через пропсы только свой объект.

Да, я смотрел уже конечно) Но я не оч люболю кложур-вей Вот такой же бы, но на flow (я даже согласен на тайпскрипт)

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

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

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

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

Дело не в самом болерплейте, мобикс в отличии от редакса предлагает уникальные фичи при работе с состоянием - возможность создавать ссылки между объектами а если вкратце то а это позволяет удобно работать с состоянием приложения как с бизнес-сущностями. Например есть такая бизнес-логика обычного приложения менеджера задач - у юзера может быть много папок, у каждой папки может быть много проектов, у каждого проекта может быть много тасков и у каждого таска может быть много комментариев и каждый комментарий также может иметь много реплаев (получается дерево комментариев) и соотвественно каждую сущность можно создать, отредактировать или удалить. С мобиксом как мы описали бизнес-сущности и связи one-to-many или many-to-many, так мы и и храним - объект юзера хранит массив объектов-папок, внутри папки будем хранить массив объектов-проектов, внутри проекта будем хранить массив объектов-тасков а в объекте таска будем хранить массив объектов комментариев и внутри каждого объекта комментария храним также массив других комменатриев-реплаев. Создавать редактировать или удалять сущности очень просто - для создания просто создаем объект и пушим в массив, для удаления делаем сплайс из массива для редактирования просто изменяем одно свойство и вот таким одинаковым образом работаем как с папками так с проектами так и с более глубокими сущностями И самое главное эти сущности могут быть связаны между собой что упрощает логику в обработчиках. Например когда рендерим таски в компоненте проекта <div>{project.tasks.map(task=><Task task={task}/>)}</div> то получив в компоненте Task через пропсы только нужный объект состояния (в данном случае task) часто бывает нужно обратиться к свойству какой-то родительской сущности например project (чтобы например проверить тип или какой-то свойство перед редактированием). И тут конечно можем выдумывать различные костыли передавая через пропсы также объект project и другие родительские сущности (а это может повлечь за собой изменение других родительских компонентов) а можем просто при создании таска добавить свойство project и записать в него ссылку на проект и обратится к свойству просто через task.project.someprop. В итоге взяв за правило при создании любой сущности записывать в свойство объекта ссылку на родительскую сущность можно очень удобно обращаться ко всему состоянию независимо от уровня вложенности например получив через пропсы комментарий можно обратится к папке в котором находится комментарий - comment.task.project.folder.name и это не потребует изменения всех вышестоящих компонентов. А теперь попробуйте ответить на вопрос как бы вы разрабатывали такое приложение используя редакс? Сколько редюсеров бы вам понадобилось? Как работали бы со связями one-to-many? Особенно интересует момент с добавлением и обновлением вложенных сущностей и особенно с деревом реплаев к таску и также интересен момент когда нужно обратится к родительским сущностям в компоненте получив через пропсы только свой объект.

GraphQL

вообще наверно даже можно что то такое придумать

как разруливать, то что на сервере могут быть тысячи сущностей, все их выкачивать не имеет смысла? как разруливать то что приходящий набор полей с сервера может быть разным для одной и той же сущности в разных ситуациях ситуациях? (в некоторых местах нужен укороченный набор данных, формировать полный на сервере не рационально)?

слишком много если

Да хорош. Вам ещё что-то нужно?

пока всего 2, и они вполне себе реальны

Я уже давно эту идею вынашиваю)

Типа при объявлении схемы ты в свойстве описываешь связь, а при обращении к нему получаешь сущность?

Ага

ну я вот вообще нихера не понял))

Ага

Но вопросов пока больше чем ответов)) Есть подозрение, что это всё решается вообще иным образом, не отталкиваясь от моделей

Ну просто это не единственный вариант