тебе нужен гибридный тип. который будет зависить от данных на входе

.union как раз оно

Жаль что инферно не в моде, он из всех самый быстрый

Больше нравится Некрополис

тебе нужен гибридный тип. который будет зависить от данных на входе

Это dispatcher так делает?

да. ты сам решаеш какой тип определить в рантайме

я как понял там все равно надо список типов передавать?

я как понял там все равно надо список типов передавать?

походу это не то

Всем привет, подскажите пожалуйста как в реакте лучше реализовать вызов библиотеки (например у меня есть scrollbar и он много где используется)

и потом был на нескольких конференциях где ребята жаловались что помирают от кучи сервисов

Какое-то полное непонимание. Сервисов в ангуляре или сторов в мобиксе не может быть много или мало - сторов должно быть ровно столько сколько сущностей в приложении. Вот есть приложение где юзер может создавать папки, в папках проекты в проектах задачи а в задачах комментарии. Сколько нужно создать сторов или сервисов? Мой ответ - ровно 4 - User, Folder, Project, Task, Comment, и я не могу понять в чем проблема количества сторов и их некосистентности

Какое-то полное непонимание. Сервисов в ангуляре или сторов в мобиксе не может быть много или мало - сторов должно быть ровно столько сколько сущностей в приложении. Вот есть приложение где юзер может создавать папки, в папках проекты в проектах задачи а в задачах комментарии. Сколько нужно создать сторов или сервисов? Мой ответ - ровно 4 - User, Folder, Project, Task, Comment, и я не могу понять в чем проблема количества сторов и их некосистентности

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

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

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

ни разу не встречался с такой проблемой и вообще не представляю как это может быть - даже самое сложное бизнес-приложение можно разбить на сущности, в конце концов они же как-то в базе данных хранятся со связями one-to-many и many-to-many. Если правильно спроектировать сущности и связи то состояния никак не могут пересекаться и какую-то сущность можно обновить только в одном месте

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

В базах кстати есть view, но он не для фронта))

Хотя суть та же, да

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

и завязываться на нее

и выходит каша из взаимосвязей

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

Ну так fuck this guy

Ну так fuck this guy

Я примерно говорю. Кто-то сделал неправильное архитектурное решение которое вылезло только при скейлинге или при запросе следующей пачки фич.

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

я пришел к прямо противоположному выводу. Все что ты написал это как раз и относится к тому как разбить на сторы и связать состояние и если состояние разбить на сущности как я говорил все проблемы решаются. Например касательно проблемы "Часто в какой-то сущности которая никак не связанна с остальными приходится знать очень много инфы про остальные сервисы и при этом иметь собственое состояние" - то это решается обратными ссылками на родительскую сущность - при создании объекта project, task, comment записываем ссылку на родителя и тогда в любом месте приложения можем получить нужное состояние просто пройдясь по ссылке. Наример есть глубина объектов - user -> (хранит массив объектов) -> folder -> project -> board -> task -> comment - и если нам нужно где-то в компоненте комментария узнать имя папки в котором он находится то достаточно только пройтись по родительским ссылкам - comment.task.board.project.folder.name

у нас в текущем проекте такая же архитектура

проект очень большой

и выглядит это как дичь

когда ты пишешь

parent(‘Toolbar’).set(‘qwe’, ‘qer); parent(‘Toolbar’).save()

разобраться в этой каше хреново, дебажить еще хуже

все мутируется и это тяжело отследить.

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

Какое-то полное непонимание. Сервисов в ангуляре или сторов в мобиксе не может быть много или мало - сторов должно быть ровно столько сколько сущностей в приложении. Вот есть приложение где юзер может создавать папки, в папках проекты в проектах задачи а в задачах комментарии. Сколько нужно создать сторов или сервисов? Мой ответ - ровно 4 - User, Folder, Project, Task, Comment, и я не могу понять в чем проблема количества сторов и их некосистентности

Кто-нибудь уже сделайте стикер про мобикс и такое описание структуры стора ?

Про папки, проекты и комментарии

no offense, keep talking ?

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

разобраться в этой каше хреново, дебажить еще хуже

Хорошо, а как ты сделал бы в редаксе этот пример с юзером, папками, проектами, задачами и комментариями? Учитывая что в редаксе нельзя создавать ссылки между объектами нам бы пришлось стор нормализировать и записывать в свойства айдишники вместо ссылок и приходим к тому что нужно на каждый чих вытаскивать айдишник из стора. И получам целую портянку вот такого кода const store = getStore(); store.folders[store.projects[store.boards[store.tasks[comment.taskId].boardId].projectId].folderId].name вместо лаконичного и простого comment.task.board.project.folder.name

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

и взять просто по айдишке фолдера

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

и там да приходится выкручиваться под каждый кейс и думать с реселектом

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

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

и взять просто по айдишке фолдера

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

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

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

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

который мы вытянем с контекста

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

да

И вы используете context?

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

Ага, и по контексту вы из глубокого компонента ползёте вверх за нехватающими свойствами?

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

Ага, и по контексту вы из глубокого компонента ползёте вверх за нехватающими свойствами?

я беру с контекста айдишку и лезу в редукс

Ага, и по контексту вы из глубокого компонента ползёте вверх за нехватающими свойствами?

храню в контексте данные которые никогда не меняются

А почему вы не прокидываете все пропсами сверху вниз?

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

А как передать? мы можем передавать только пропсами что-то в компонент, но вот этот вариант еще хуже потому что каждый раз когда глубоко вложенному компоненту потребуется какая-то новая инфа мы должны менять рендер всех вышестоящих компонентов чтобы пробросить нужную инфу, в данном случае айдишник паки через все промежуточные, и это все ведет к разрастанию пропсов. Поэтому уж лучше компонент сам будет вытаскивать по айдишнику нужные ему объекты но все равно необходимость постоянно вытаскивать по айдишниками и код подобно const store = getStore(); store.folders[store.projects[store.boards[store.tasks[comment.taskId].boardId].projectId].folderId].name значительно уступает возможности получить нужный объект пройдясь по ссылкам используя мобикс comment.task.board.project.folder.name

А почему вы не прокидываете все пропсами сверху вниз?

это было бы правильно, но очень большая вложенность и это портит чистоту кода

А как передать? мы можем передавать только пропсами что-то в компонент, но вот этот вариант еще хуже потому что каждый раз когда глубоко вложенному компоненту потребуется какая-то новая инфа мы должны менять рендер всех вышестоящих компонентов чтобы пробросить нужную инфу, в данном случае айдишник паки через все промежуточные, и это все ведет к разрастанию пропсов. Поэтому уж лучше компонент сам будет вытаскивать по айдишнику нужные ему объекты но все равно необходимость постоянно вытаскивать по айдишниками и код подобно const store = getStore(); store.folders[store.projects[store.boards[store.tasks[comment.taskId].boardId].projectId].folderId].name значительно уступает возможности получить нужный объект пройдясь по ссылкам используя мобикс comment.task.board.project.folder.name

пропсы и контекст

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

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

эм

он и оказывается

штук 20

Рыбята, как использовать переменную из метода в рендере?

Бля, какую же херню я тогда написал

штук 20

Бладж :)

Не надо работать, когда мозг отказывает

это все хоки

и потом это еще раз компоузится

Ох...

Я кончил

на разные специфические компоненты

даже для лайтбокса есть хок

Функциональщина в Реакте?

даже для лайтбокса есть хок

которая может связать все картинки на сайте в одну колекцию

Функциональщина в Реакте?

Про фп сегодня флеймят соседнем чате))

еще плануем все хоки оборачивать в другие хоки

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

для параметров

в хок

А потом спрашивают. Почему браузер столько оперативы жрёт?

Про фп сегодня флеймят соседнем чате))

А что про неё флеймить? Сложна?

ну это в теории

Слушаешь?

Хз что это

А, я думал, что ты завтракаст слушаешь.

А как передать? мы можем передавать только пропсами что-то в компонент, но вот этот вариант еще хуже потому что каждый раз когда глубоко вложенному компоненту потребуется какая-то новая инфа мы должны менять рендер всех вышестоящих компонентов чтобы пробросить нужную инфу, в данном случае айдишник паки через все промежуточные, и это все ведет к разрастанию пропсов. Поэтому уж лучше компонент сам будет вытаскивать по айдишнику нужные ему объекты но все равно необходимость постоянно вытаскивать по айдишниками и код подобно const store = getStore(); store.folders[store.projects[store.boards[store.tasks[comment.taskId].boardId].projectId].folderId].name значительно уступает возможности получить нужный объект пройдясь по ссылкам используя мобикс comment.task.board.project.folder.name

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

ну это в теории

Так, а чем обусловлено кстати обусловлено такое количество хоков?

Так, а чем обусловлено кстати обусловлено такое количество хоков?

много компонентов и юайной логики

ее надо как-то реюзать между компонентами

без изменения кода компонентов

А как передать? мы можем передавать только пропсами что-то в компонент, но вот этот вариант еще хуже потому что каждый раз когда глубоко вложенному компоненту потребуется какая-то новая инфа мы должны менять рендер всех вышестоящих компонентов чтобы пробросить нужную инфу, в данном случае айдишник паки через все промежуточные, и это все ведет к разрастанию пропсов. Поэтому уж лучше компонент сам будет вытаскивать по айдишнику нужные ему объекты но все равно необходимость постоянно вытаскивать по айдишниками и код подобно const store = getStore(); store.folders[store.projects[store.boards[store.tasks[comment.taskId].boardId].projectId].folderId].name значительно уступает возможности получить нужный объект пройдясь по ссылкам используя мобикс comment.task.board.project.folder.name

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

тот же спейс