лол

@kelin2025 пофикшено

че пофикшено

@kelin2025 пофикшено

алло

ники разные

.

а

все

теперь увидел

https://github.com/ivan-kleshnin/unredux

>React + Redux + Redux patterns + Redux Actions + Redux Thunks + Redux Sagas + ... where each comes with a tiny benefit and nobody ever talks of drawbacks. Redux fatigue is real.

лолл

>I recommend to take a look at these enlightening articles. ссылка на calmm-js

лололо

без редукса с реактом у него всё равно остаётся глобальный стейт на всю вьюху?

вижу сабжекты

вообще в чём глобальная проблема у него с редуксом?

сложно впилить его любимый RX?

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

>React + Redux + Redux patterns + Redux Actions + Redux Thunks + Redux Sagas + ... where each comes with a tiny benefit and nobody ever talks of drawbacks. Redux fatigue is real.

я согласен вообще надо назвать это говно bullshidux

window.Observable = Observable window.Subject = Subject window.ReplaySubject = ReplaySubject это так глобальные переменные расставляются? это ок практика?

ты counter-vanilla открыл?

открой с реактом

https://github.com/ivan-kleshnin/unredux/blob/master/3.todos/demo1/vendors.js

не знаю что должно значить вендорс

а

ему импорты лень делать что ли)

экшоны = сабжекты

алсо тут походу нету примеров с асинхронными запросами

вообще он предложил calmm

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

алсо тут походу нету примеров с асинхронными запросами

ну так ето стрим

там все ок должно быть

Ну стоит признать что проблема с редаксом имеет место быть, но

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

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

Бойлерплейт редакса — это в первую очередь решение, а не проблема, потому что при любых вычурных кейсах мы не впечатываемся во внутренности библиотеки, которых фактически нет, а свободно спускаемся на сколько угодно низкие уровни абстракции

То есть, это просто даёт возможность как абстрагироваться каким нибудь redux-act от большей части сути, так и спускаться вниз по необходимости

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

То есть вся вот эта напрягающая мутатень в редаксе — это намеренно введёные ритуалы, именно из-за которых получается не сходить с ума в самых тяжёлых ситуациях)

на старте запроса и в конце

когда-то давно я сделал https://github.com/xgrommx/most-reactive-flux https://github.com/xgrommx/react-rx-flux потом было еще несколько идей но они так и остались в моем jsbin

док потому что нет

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

на старте запроса и в конце

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

Последнее предложение меня больше всего пугает

Вот это реальная проходка в ад

zalgo-стейт — ну так себе удовольствие

zalgo-стейт — ну так себе удовольствие

не гуглится

zalgo-стейт — ну так себе удовольствие

zalgo-стейт?

zalgo a.k.a. maybe sync maybe async

я как-то писал про бойлерплейт С такой формулировкой 80% любого проекта - бойлерплейт Андрей Краснобаев 21:42 ну так к уменшению этого мы и стремимся бойлерплейт - реальная проблема, которая есть везде, просто в редаксе еще особенно много, потому что в жс перенесли идею с другого языка и фичи, которые бесплатно есть в исходном языке, нужно писать вручную на жс Бойлерплейт - это не всегда плохо. Писать его лень, да, но порой он нужен для того, чтобы максимально абстрагировать куски кода друг от друга ну и часто куча бойлерплейта помогает избежать еще большего бойлерплейта например, линзы)

я как-то писал про бойлерплейт С такой формулировкой 80% любого проекта - бойлерплейт Андрей Краснобаев 21:42 ну так к уменшению этого мы и стремимся бойлерплейт - реальная проблема, которая есть везде, просто в редаксе еще особенно много, потому что в жс перенесли идею с другого языка и фичи, которые бесплатно есть в исходном языке, нужно писать вручную на жс Бойлерплейт - это не всегда плохо. Писать его лень, да, но порой он нужен для того, чтобы максимально абстрагировать куски кода друг от друга ну и часто куча бойлерплейта помогает избежать еще большего бойлерплейта например, линзы)

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

а с профункторной оптикой в хаскеле тоже понадобится th?

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

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

premature optimisation

Спойлер — потом окажется что твои структуры не такие уж и одинаковые

А потом что не такие уж и функторы

какая красота

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

правильно ли считать описание функтора бойлерплейтом?

да

Профункторы курильщика

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

Ритуал

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

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

не очевидно

инстансы вроде разные могут быть

или я что-то не уловил из контекста?

если бизнес-задача - делать функторы (стартап по производству функторов), то тогда да, это не бойлерплейт)

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

чье это определение?

Единственный реальный код в бизнесе — это тот, который обслуживает приём лаве, всё остальное — бойлерплейт

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

Последнее предложение меня больше всего пугает

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

если бизнес-задача - делать функторы (стартап по производству функторов), то тогда да, это не бойлерплейт)

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

жизнь вообще не очень честная...

это приём из риторики

нормально до этого говорили

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

ну, я тоже не понял, при чем тут честность

это как если я сейчас обращусь к твоим личным качествам

в смысле где я что-то высмеивал?

ты так говоришь, будто бойлерплейт - это негативное слово

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

и когда-то Дейв все написал http://davesexton.com/blog/post/To-Use-Subject-Or-Not-To-Use-Subject.aspx

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

нет, ты не верно меня читал

процитирую себя "Бойлерплейт зачастую очень полезен тем, что помогает нам не писать еще больший бойлерплейт. Например, линзы (сюда можно и функторы)`

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

Допускаю, что у тебя подходящий для них спектр задач

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

это не ирония или не насмешка над фп, это логичный вывод

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

Кметт))

ну чтобы ты понимал - мои чувства здесь никак не задеты просто тут что-то не так. сначала бойлерплейт был тем что не несёт в себе никакой логики (код который должен быть здесь иначе не сработает) теперь бойлерплейт – код который не приносит непосредственную прибыль

Программа — это способ описания неформальной постановки задачи в формализованной форме. Так же как в письменной речи нет бойлерплейт-запятых, так же и в формальной спецификации задачи нет фп-бойлерплейта

что-то тут ещё было выше

ну чтобы ты понимал - мои чувства здесь никак не задеты просто тут что-то не так. сначала бойлерплейт был тем что не несёт в себе никакой логики (код который должен быть здесь иначе не сработает) теперь бойлерплейт – код который не приносит непосредственную прибыль

не логики, а бизнес-логики

то есть логики, решаеющей задачу непосредственно, а не косвенно

ну в xstream есть imitate