Ну и зачем fmap в std языка без HKT или хотя бы ATC?

без идей

Единственный вариант — определять какой-нибудь Symbol.fmap на нужном типе (Maybe)

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

Разумеется

короче это все попытка притащить в js то, чему тут не очень место на данном этапе

Хм. А вот что с flow: https://medium.com/@gcanti/higher-kinded-types-in-flow-275b657992b7#.hdju3vcag

хотя в данном случае можно определить на Nothing и на Just

хотя в данном случае можно определить на Nothing и на Just

Ну, я думаю всё же правильнее строить Nothing и Just как подкласс Maybe

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

Ну и зачем fmap в std языка без HKT или хотя бы ATC?

а как ATC тут поможет?

а как ATC тут поможет?

Как-то так: http://smallcultfollowing.com/babysteps/blog/2016/11/09/associated-type-constructors-part-4-unifying-atc-and-hkt/

ну это вроде читал

Ну.. вот как эмулировать можно: https://gist.github.com/14427/af90a21b917d2892eace

Но я всё равно считаю, что подход с тем, чтобы делать fmap/>>=/etc через, скажем, итератор лучше.

Ну, т.е. есть типаж Iterator<Item=T> на котором есть все эти методы. Далее типаж реализуется для нужной коллекции уже. Эффект такой же, но HKT не нужны

блин, я чет и не знал, что в расте так развита система типов

ты мне вот в предыдущий раз глаза открыл)

Ну, т.е. вот так https://doc.rust-lang.org/std/iter/trait.Iterator.html

Ну.. вот как эмулировать можно: https://gist.github.com/14427/af90a21b917d2892eace

С macros 1.1 (Rust >=1.15) можно запилить derive(HKT) и будет что-то вроде: #[derive(HKT)] enum Maybe<T> { Just(T), Nothing } Практически HKT в языке. Соб-но, потому разрабы и против сабжа, чтобы не усложнять

а как в рамде типа eqProps, только eqPaths?

хм, module.exports = _curry3(function eqProps(prop, obj1, obj2) { return equals(obj1[prop], obj2[prop]); }); ну можно по типу pathEq сделать по аналогии: module.exports = _curry3(function pathEq(_path, val, obj) { return equals(path(_path, obj), val); }); хотя оказалось что мне это не надо)

а как в рамде типа eqProps, только eqPaths?

const eqPath = pipe(path, eqBy)

о, прикольно) спасибо

тишина такая :)

на меннинге dotd отличный

https://www.manning.com/dotd

Сюда: @python_jobs, @php_jobs, @nodejs_jobs

?

протестанты в моём жс

вместо абрамоугодности используют штальцесовместимость

?

Аватарка чата гуд

ну правда чат не совсем по js )

И не совсем радужный

Функционально-реактивные подходы в JS/TS. RxJS, Cycle.js, Ramda, etc.

Это пиннед, даже.

Надо наверное или пиннед поменять, раз уже не жс, или аватарку. (или забить, проще будет)

Там же есть "etc"

Ну, etc был после точки после JS.

Так что я предположил что пот эт цетрой идут фреймворки для ФРП на жсе.

Тьфу

Фреймворки

Js - вершина айсберга

Хаха, либы.

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

охо

Привет, хотел спросить Ramda.merge на всех уровнях вложенности работает? т.е могу ли избавиться от постоянных вложенных rest операторах при исполозовании этой функции?

Или это тот же Object.assign?

Привет, хотел спросить Ramda.merge на всех уровнях вложенности работает? т.е могу ли избавиться от постоянных вложенных rest операторах при исполозовании этой функции?

проверь тут http://ramdajs.com/repl/

Merge делает только поверхностный мерж. Это полный эквивалент Object.assign({},target, source).При помощи mergeWith можно сделать рекурсивный мерж. Но обычно это не нужно и лучше просто использовать линзы( http://blog.csssr.ru/2016/07/08/lenses/ ) или какое то другое при для работы с иммутабельными структурами(immutable.js, immutable-seamless etc)

А все понял immutable.js все таки придется тянуть)

спасибо!)

*другое апи

А все понял immutable.js все таки придется тянуть)

линзы же

Да я знаю, можно было не задавать, просто на секнуду подумал зачем они же не стали бы делать эквивалент Object.assign

все все разобрался, спасибо еще раз!

конечно с redux-observable немного не удобный есть момент один

https://redux-observable.js.org/docs/basics/Epics.html REMEMBER: Epics run alongside the normal Redux dispatch channel, after the reducers have already received them. When you map an action to another one, you are not preventing the original action from reaching the reducers; that action has already been through them!

"after the reducers have already received them" т.е. нет доступа к предыдущему состоянию, либо я чего-то не понял но это не удобно, не вижу пути кроме как передавать в пейлоаде нужное "предыдущее"

Там же есть store вторым аргументом

Хотя может это не то

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

было бы прикольно если я бы я эпику мог сказать на каком этапе ему срабатывать: до или после редьюса или придумать что-то еще)

А зачем нужен прошлый стейт?

сравнить с текущим и принять решение по сайд-эффектам – какие нужно запустить / остановить

так может не надо ничего менять по экшнам которые ты как-то преобразуешь

т.е. например: было [1, 3, 12] стало [1, 5, 3]

^ нужно остановить для 12 или, например: old: [1, 2, 5], new: [5, 3, 8, 1] stop: difference([1, 2, 5], [5, 3, 8, 1]) // 2 run: difference([5, 3, 8, 1], [1, 2, 5]) // 3, 8 run и stop это могут быть данные для команд подписок на что-либо, например поэтому тут мне нужно как-то получить old ну это так себе проблема, просто приходится это делать где-то в другом месте сейчас, иначе эпику не узнать об old

так может не надо ничего менять по экшнам которые ты как-то преобразуешь

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

https://github.com/cyclejs-community/redux-cycles видели?)

дааа подсаживают на cyclejs людей постепенно)

https://github.com/cyclejs-community/redux-cycles видели?)

Угу, сейчас вот пытаюсь впилить (нихуя не понимаю в frp на самом деле)

там вроде можно прошлый стейт получить. Хотя я не пробовал, у меня thunk везде) На cycle только ботов писал для телеграма и чет для этого он не очень зашел мне (ну мб я криво драйвер сделал)

после этого https://medium.freecodecamp.com/how-to-make-your-react-app-fully-functional-fully-reactive-and-able-to-handle-all-those-crazy-e5da8e7dac10

Какие подводные камни в выборе между xstream и rxjs?

нужно чёткое понимание hot vs cold для начала

share везде)

на xstream не хочется переходить потому что штальц люто пропагандирует его) так еще с этим unified он и так в зависимости к драйверу попадает ?

В xstream автоматический рефкаунтинг. Это часто удобно, но не позволяет воспринимать observable как "функцию", которая может возвращать несколько значений синхронно или асинхронно

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

это удобно со всякими ивент потоками типа кликов и не очень удобно со всякими of/from

а с http-запросами может быть как удобно, так и нет)

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

В xstream автоматический рефкаунтинг. Это часто удобно, но не позволяет воспринимать observable как "функцию", которая может возвращать несколько значений синхронно или асинхронно

рефкаунтинг это про hot?

это поправка к hot я бы сказал

классическое hot это ивентбас

просто что-то происходит и на это можно подписываться

при ревкаунтинге всё-таки происходит запуск и остановка продюсера (источника сигнала), но не на каждого подписчика отдельно как в cold, а сразу на всех

то есть запускается когда количество подписчиков переходит от 0 к 1 и останавливается когда от 1 к 0

соответственно если был 1, потом 0, и снова 1 это перезапуск

в случае http повторный запрос

Так в cycle подписки все равно внутри где-то)

Это только усложняет