Почему?

В мессенджерах знаешь сколько данных бывает?) Откроешь дев тулс и захлебнёшься

Начинали все с такого

А в чем недостаток такого подхода?

Недостатков нет

блин ребят

Как и достоинств)

кто-нить пользовал эти штуки?

floor level))

кто-нить пользовал эти штуки?

Я

WebSQL deprecated, а idb послали нам за наши грехи, не иначе

ну позыв собственно какой если железо слабое, то тебя никакая БД на клиенте не спасет

ибо будут ограничения и по памяти и по ЦПУ

IndexedDB — это дотошная, аутентичная иммитация древней базы данных в етом вашем вебе. Включая api и скорость работы

если инфраструктура сильная т.е. с сетью проблем нет и объемы данных ghbkbxyst

то тоже это на фиг не надо

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

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

Когда данных будет под тысячу типов — вернёмся к этому разговору))

либо используй мозные каналы связи

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

Пишет нам Валерий через клиент телеграма который не зассал и рулит огромной схемой данных в одного

а то будут проблемы с консистентностью данных

и т.д.

В телеграмовском протоколе всё норм с консистентностью

Например

А в клиентах такой фантастический объем данных, что даже передать тебе сложно)

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

это другой разговор

А они не исторические, это реалтайм такой

а когда эти исторические данные могут меняться, то другой

но дело то не в этом

Тебе прилетел пакет на 200 перекресных мессаг, сопровождающих их чатов, юзеров и прочих

на фига хранить данные в виде реляционной базы данных в редаксе

учитывая что у тебя редакс иммутабелен!

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

учитывая что у тебя редакс иммутабелен!

Иммутабельность можно делать не только через кондовый спред в лоб

не знаю мне это кажется спорный вопрос

про все эти getAllIds

и прочую такую же лабуду

Ну я его как бы не защищаю

весь мир постепенно движется к nosql, к избавлению от этих всех реляций

Просто говорю что bd-like структура все равно будет

весь мир постепенно движется к nosql, к избавлению от этих всех реляций

Я сделаю вид что не видел этого)

Не хочу ругаться матом))

ага особеено с приходом graphql в мир реакта

ну думаю носкл это не значит, что нету логики

ага особеено с приходом graphql в мир реакта

зачем нам носить носки если мы купили отличную шляпу

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

но времена когда ты делаешь 10 запросов подряд к бакенду да

заканчиваются

когда ты подсасываешь все зависимости по отдельности

ты ж видел в каком виде хранит графкл данные на клиенте да ?)

Да там и api тот ещё

ты ж видел в каком виде хранит графкл данные на клиенте да ?)

вот это меня меньше всего волновает :)) как говорится

носкль))

их оптимизации это их оптимизации

nosql - nothink

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

я чую вы мечтаете об аналоге рельсового ORM в вебе еще :))

рельсовая орм это зло

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

что именно?

джанго орм

удобное

мечтаю

удобное, но зло

(нет)

ERROR: S client not available

джанго орм

джанго? :) ты писал на джанго? :))) я да

и на рельсах писал

люблю питон, но терпеть не могу джанго

люблю питон, но терпеть не могу джанго

ну это саркам был по поводу квери с "__"

Ну как бы у тебя может быть домен и без отображения

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

Я

рельсовая орм это зло

В чем проблема?

Вам не зашло

что именно?

const onClick = myprops1 => { return true; }; const element = ({ myprops1, myprops2 }) => { return <div onClick={onClick(myprops1)}>Component</div>; };

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

const onClick = myprops1 => { return true; }; const element = ({ myprops1, myprops2 }) => { return <div onClick={onClick(myprops1)}>Component</div>; };

это что за паттерн вообще?: )

ну в нем нет смысла собственно

весь мир постепенно движется к nosql, к избавлению от этих всех реляций

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

это что за паттерн вообще?: )

да эт не паттерн, это мысли)

ну вот фнукциональный компонент

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

куда их блин засунуть)

ну если ты хочешь какую то логику, то это уже не SFC

stateless functional component позразумевает, что он совсем глупенький

ну если ты хочешь какую то логику, то это уже не SFC

я думал в контейнер с редаксом выташить)

и то что ты об это знаешь всегда

да он тупой как пропка) там простые ивенты)

тебе конечно js позволяет делать вещи с этим всем

Есть библы для умных функциональных компонентов. Но зачем?

но это только запутает тебя

да проблема не выносе вверх)

они просто на грани тупых и чутка логики имеют в ивентах

ну слушай, для умных или более сложных компонент есть классы

там ничего не нужно придумывать же

меня разрывает, незнаю куда их, плюнуть через class сделать без стейта или в контейнер выташить, но контейнеры в отдельном файле, как то разрывать не хочется)

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

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

да походу надо перестать парится и взять черное\белое)