ага, это получается на 20 разных книг от разных авторов будет сделано еще 20 апи запросов на каждого автора?

Будет запрос на всех авторов, которые вообще есть.

А до клиента точно данные доходят?

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

Будет запрос на всех авторов, которые вообще есть.

получишь 100 авторов и будешь перебирать массив авторов, чтоб все это склеить?

ты кому вообще работу хочешь этим упростить беку или фронту?

да

А, кажись понял. Данные в неком внешнем storage живут. Надо их либо через props вкинуть, либо setState и из state забирать. За внешним хранилищем тупо никто не следит

@observer у mobx разве не делает этого?

получишь 100 авторов и будешь перебирать массив авторов, чтоб все это склеить?

Если буду выводить список книг с авторами. То да. Если буду выводить только авторов, то выведу всех что есть, если мне авторы понадобятся ещё где то данные будут так же храниться только в одном месте, и склеить их будет просто по иду.

В текущем примере имхо проще в state компонента закинуть

@observer у mobx разве не делает этого?

В mobx я не копенгаген, но похоже по описанию проблемы, что не реагирует на изменения

В mobx я не копенгаген, но похоже по описанию проблемы, что не реагирует на изменения

Логично

Спасибо, попробую через Стэйт сделать

Удачи

один сказал что он в жизни плоские структуры не делал!

Так там пыхеры

Так там пыхеры

Похеры наверное, а не пыхеры)

ага, это получается на 20 разных книг от разных авторов будет сделано еще 20 апи запросов на каждого автора?

Прости не на то сообщение ответил. Запроса будут 2 авторов, и книг.

Если буду выводить список книг с авторами. То да. Если буду выводить только авторов, то выведу всех что есть, если мне авторы понадобятся ещё где то данные будут так же храниться только в одном месте, и склеить их будет просто по иду.

{ books: [{id: 1, author: {} }] } сейчас такое у тебя ?

Нормализацию обычно делают на фронте

А зачем это делать, если из нного числа запросов деревьев, я не получаю полный список структурированных данных? Когда можно это просто вынести в 1 урл.

А зачем это делать, если из нного числа запросов деревьев, я не получаю полный список структурированных данных? Когда можно это просто вынести в 1 урл.

бэк дает то тчо дает. Если нет способа поменять - нормализовать нужно тебе

{ books: [{id: 1, author: {} }] } сейчас такое у тебя ?

Нет у меня такое { Books { byId:{} allIds:[] } Authors { byId:{} allIds:[]} }

ну это ты нормализовал. Так и в чем проблема ? Смысл всех сообщений ?

Уверяю тебя можно сделать грамотную сьтруктуру с редаксом)

строить грамотную структуру вокруг неграмотной концепции ?

Смысл отдавать из апи не нормализованные

Смысл отдавать из апи не нормализованные

возможно не могут. Не знат. Это не их пролема

Про это и был вопрос часто ли вы с этим сталкивается, и как боритесь.

Ибо мне из апи вообще хероту присылают.

Про это и был вопрос часто ли вы с этим сталкивается, и как боритесь.

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

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

По перформансу отлично. Просто шикарно.

так дело то в том чо на каждый чих гонит. А если много данных ?

И бек больше не зависит от того кому что надо. Единообразное апи

так дело то в том чо на каждый чих гонит. А если много данных ?

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

По перформансу отлично. Просто шикарно.

Не лагает !== шикарно, держу в курсе)

так дело то в том чо на каждый чих гонит. А если много данных ?

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

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

если измениться что то сеекторы отработают

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

я про вывод. Ты же в массив авторов и книги собираешь в рендере ?

Не лагает !== шикарно, держу в курсе)

Если нормально отлаживать с реселектом, то === шикарно

Если нормально отлаживать с реселектом, то === шикарно

Как хорошо быть слепым

я про вывод. Ты же в массив авторов и книги собираешь в рендере ?

Если что то измениться в твоём случае, то ты выполнишь +1 запрос и так же перерисуешь.

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

Можно договорится с беком какой формат передачи данных будет удобен обоим но надо не забывать что есть определенные ситуации когда неправильный формат передачи приведет к тормозам. Очень часто делают так что сервер передает даннные вложенными объектами { tasks: [ { id: 1, ... subTasks: [ {id: 1, ...}, {id: 2, ...} ] }, { id: 2, ... subTasks: [ {id: 3, ...}, {id: 4, ...} ] } ] }Хотя правильно передавать данные в плоском, нормализированном виде { tasks: { 1: {id: 1, ..., subTasks: [1, 2]}, 2: {id: 2, ..., subTasks: [3, 4]} ... }, subTasks: { 1: {...}, 2: {...}, 3: {...} 4: {...} } }потому что когда связи между сущностями будут не one-to-many а many-to-many - например нужно передать юзера со списком его друзей и друзей его друзей то попытка передать данные через вложенные объекты приведет к тому что в окажется много дублей юзеров что приведет к мегабайтному json-у, медленной передаче по сети и тормозам как по парсингу так и по обработке.

ну учитывая, что сейчас модны всякие cassandra, mongo и прочие, где то id-шек нет от слова совсем, то нет реляций поэтому от бакендеров и приходит всякое говно

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

вопрос не в мапе. Ты на каждый чих масси собираешь

вопрос не в мапе. Ты на каждый чих масси собираешь

Если изменится. В твоём же случае я просто не вижу апдейта..

Если изменится. В твоём же случае я просто не вижу апдейта..

моего случая тут нету. Это я пытался понять что у тебя

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

Есть 2 варианта. 1 у тебя уже есть иерархия. И если что то в иерархии изменилось ты об этом не узнаешь, пока не перезапросишь иерархичные данные. 2 случай плоские данные. если из какого то другова место данные изменили, ты это тут же отображаешь там где ты строишь сам эту иерархию, и во всех других местах, где данные на нее завязаны

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

Люди жалуються!

Есть 2 варианта. 1 у тебя уже есть иерархия. И если что то в иерархии изменилось ты об этом не узнаешь, пока не перезапросишь иерархичные данные. 2 случай плоские данные. если из какого то другова место данные изменили, ты это тут же отображаешь там где ты строишь сам эту иерархию, и во всех других местах, где данные на нее завязаны

у тебя в любом случае чекнится что изменилось. Даже с вложенной структурой

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

у тебя в любом случае чекнится что изменилось. Даже с вложенной структурой

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

у тебя в любом случае чекнится что изменилось. Даже с вложенной структурой

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

ну конкретно тут да

Есть 2 варианта. 1 у тебя уже есть иерархия. И если что то в иерархии изменилось ты об этом не узнаешь, пока не перезапросишь иерархичные данные. 2 случай плоские данные. если из какого то другова место данные изменили, ты это тут же отображаешь там где ты строишь сам эту иерархию, и во всех других местах, где данные на нее завязаны

первое это что за ситуация такая?

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

ахахахах

ну конкретно тут да

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

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

такая же херня

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

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

первое это что за ситуация такая?

плиз просто перечитай мои посты...

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

потому что им не интересен фронтенд. И он для тебя ничего не обязан подогнать. Он не должен думать что ты там собрался херней страдать и менять всем автора. Это твои проблемы

плиз просто перечитай мои посты...

перечитывал и не понял о чем ты :))

допустим у тебя автор в большой иерархии в 10 разных местах (редьюсерах)

потому что им не интересен фронтенд. И он для тебя ничего не обязан подогнать. Он не должен думать что ты там собрался херней страдать и менять всем автора. Это твои проблемы

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

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

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

нет. Ты не понял я вот тут долго вникая кажись понял есть массив изначально. Обнови всем автора

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

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

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

а ну так в екшене пройти по массиву и заменить. И не нужно нормализовать

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

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

ERROR: S client not available

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

а это когда такое бывает ???

а это когда такое бывает ???

из эластика например прилетает кусок готовой структуры

из кассандры

[В ответ на Игорь] Можно договорится с беком какой формат передачи данных будет удобен обоим но надо не забывать что есть определенные ситуации когда неправильный формат передачи приведет к тормозам. Очень часто делают так что сервер передает даннные вложенными объектами { tasks: [ { id: 1, ... subTasks: [ {id: 1, ...}, {id: 2, ...} ] }, { id: 2, ... subTasks: [ {id: 3, ...}, {id: 4, ...} ] } ] } Хотя правильно передавать данные в плоском, нормализированном виде { tasks: { 1: {id: 1, ..., subTasks: [1, 2]}, 2: {id: 2, ..., subTasks: [3, 4]} ... }, subTasks: { 1: {...}, 2: {...}, 3: {...} 4: {...} } } потому что когда связи между сущностями будут не one-to-many а many-to-many - например нужно передать юзера со списком его друзей и друзей его друзей то попытка передать данные через вложенные объекты приведет к тому что в окажется много дублей юзеров что приведет к мегабайтному json-у, медленной передаче по сети и тормозам как по парсингу так и по обработке.

т.е. когда у бакендеров нет какого-нибудь postgres, где все по табличкам изначально раскидано

первый вариант какраз не плоские данные, и заметь там есть ИД

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

Есть же normalizr

[В ответ на Игорь] Можно договорится с беком какой формат передачи данных будет удобен обоим но надо не забывать что есть определенные ситуации когда неправильный формат передачи приведет к тормозам. Очень часто делают так что сервер передает даннные вложенными объектами { tasks: [ { id: 1, ... subTasks: [ {id: 1, ...}, {id: 2, ...} ] }, { id: 2, ... subTasks: [ {id: 3, ...}, {id: 4, ...} ] } ] } Хотя правильно передавать данные в плоском, нормализированном виде { tasks: { 1: {id: 1, ..., subTasks: [1, 2]}, 2: {id: 2, ..., subTasks: [3, 4]} ... }, subTasks: { 1: {...}, 2: {...}, 3: {...} 4: {...} } } потому что когда связи между сущностями будут не one-to-many а many-to-many - например нужно передать юзера со списком его друзей и друзей его друзей то попытка передать данные через вложенные объекты приведет к тому что в окажется много дублей юзеров что приведет к мегабайтному json-у, медленной передаче по сети и тормозам как по парсингу так и по обработке.

зачем тебе плоские данные ? Они обычно если что то меняется быстро в массиве. А у тебя просто авторов обновить

проще Map сделать

и таких становится с каждым днем все больше

зачем тебе плоские данные ? Они обычно если что то меняется быстро в массиве. А у тебя просто авторов обновить

книги это пример. Я все пилю на плоских данных, и считаю это верным путем.

Есть же normalizr

да бро есть нормалайзер тока вод иды не всегда есть (

Есть же normalizr

ну приходится выкручиваться в браузере само собой, всякие normalizr, redux-orm, denormalizr подтягивать

я вот с бакендеров требовал id-шки для записей логов

книги это пример. Я все пилю на плоских данных, и считаю это верным путем.

Это и есть верный путь т.к. изменение пропса считается гораздо быстрее

они мне сказали что в базе айдишек нет у них :)))

как хочешь так и выкручивайся

они мне сказали что в базе айдишек нет у них :)))

Пусть сгенерят

ну приходится выкручиваться в браузере само собой, всякие normalizr, redux-orm, denormalizr подтягивать

Бро каким бы эластиком оно не пользовалось денормализованная структура тоже должна быть граматной. а не authors [{name:вася} ]

ну когда "исторически так сложилось" уже поздняк метаться

Бро каким бы эластиком оно не пользовалось денормализованная структура тоже должна быть граматной. а не authors [{name:вася} ]

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

вские фулстэки понапишут говнеца, подтянут модных хипсторских штук в проект, а после них все приходят и руками разводят :))

в итоге и бакенд так себе и фронт ни о чем

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

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

Про нормализацию тема норм раскрыта у Дэна Абрамова в курсе по редаксу

я что то сказал про другие данные ? Есть список. Есть место рендера. Он не меняется. ты нормализируешь что ли ?

Про нормализацию тема норм раскрыта у Дэна Абрамова в курсе по редаксу

мне было очень сложно... Но теперь мне сложно с моим бекендером...

я что то сказал про другие данные ? Есть список. Есть место рендера. Он не меняется. ты нормализируешь что ли ?

есть мето рендера книг. хочу с авторами, хочу без авторов, хочу авторов отдельно, хочу авторов к статьям в блоге

https://egghead.io/lessons/javascript-redux-normalizing-api-responses-with-normalizr покажи бэкендеру :D

вские фулстэки понапишут говнеца, подтянут модных хипсторских штук в проект, а после них все приходят и руками разводят :))

Когда не успеваешь за трендами приходится искать оправдание

есть мето рендера книг. хочу с авторами, хочу без авторов, хочу авторов отдельно, хочу авторов к статьям в блоге

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