Ага

Надо у рамды доку как в hackage

Где все инстансы показываются

аппликатив для функции это комбинатор S - ap и K - of

@xgrommx, а ты можешь объяснить в каком случае в методах ramda можно передавать некаррированные функции в качестве аппликатива? Есть вообще какая-то логика? То, что sequence принимает массив обычных функций это фича или баг? Просто у тебя выше я видел подобное использование sequence )

compose(xs => xs.every(Boolean), sequence(always, [cond1, cond2, ...]))(obj)

вот тут

в чем баг?

все правильно

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

поэтому надо явно указать 1 аргументов of

это же внутри все равно аппликатив

например sequence(always, [f1, f2])

есть просто

В общем, везде, где ramda требует аппликатив, можно использовать функции?

конечно

ну покрайней мере в sequence/traverse

Спасибо

и не только функции

у всего у чего есть аппликативная структура

ну покрайней мере в sequence/traverse

А вот это плохо. Плохо что какие-то НЕДОКУМЕНТИРОВАННЫЕ исключения, о которых необходимо знать.

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

ну как бы тут все норм https://github.com/ramda/ramda/blob/v0.24.1/src/sequence.js

да и сигнатура это говорит (Applicative f, Traversable t) => (a -> f a) -> t (f a) -> f (t a)

Я не уточнил что я имею в виду ) Я о том, что sequence в качестве аппликатива принимает простые функции, а некоторые другие методы под аппликативами подразумевают только каррированные

например тот же ap

Значит функция как таковая в мире ramda не является аппликативом сама по себе

является

https://github.com/ramda/ramda/blob/v0.24.1/src/ap.js#L35

Почему в документации по ap сказано "Also treats curried functions as applicatives."?

зачем сказано именно curried?

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

зачем сказано именно curried?

в сигнатуре по-другому зато)

так что надо на них смотреть

Я так понимаю, что chain тоже принимает аппликативы? Судя по тому что он работает с функциями

а при чем тут аппликатив и принимает функции?

ну да если работает с chain то и монада и аппликатив и функтор

Что вообще принимает chain? Какое у него требование к аргументам?

монаду и стрелку Клейсли

Стрелка клейсли это что в терминах fantady land?

Monad m => a -> m b

ERROR: S client not available

То-есть, функция, возвращающая монаду?

ах...

Просто хочу понять ограничение chain

А сейчас я обнаружил вообще черт знает что. Странно, но этот код тоже работает ) const plusOne = x => x + 1; const plusTwo = x => x + 2; const plusThree = x => x + 3; const fn = curry(function(a, b) {}); sequence(fn, [plusOne, plusTwo, plusThree])(1) // => [2, 3, 4] При том, что функция fn ничего возвращать не должна )

Доделал реактивный стор. Своего кода почти нет, в основном использование Rx. https://github.com/Voronar/react-pure-typescript/blob/rx/src/store/TodoStore.ts Какие видите в нём подводные камни навскидку?

много бойлерплейта?)

https://github.com/xgrommx/most-reactive-flux

вот Rx через join patterns (в Rx5 его нет походу) https://github.com/xgrommx/react-rx-flux/blob/master/src/store.js

много бойлерплейта?)

Мне показалось, что меньше чем в редакс, по крайней мере без констант и диспатчей (тут получились правда next'ы) всяких. Просто взял нужный стор, подключил его и вызвал метод по обновлению данных (это в принципе и в редакс так). Но не надо редьюсеры комбинировать. Просто создал столько экземпляров стора, сколько надо, если нужно переиспользование как в моём примере с todo.

Единственное, я по производительности не тестил, что будет, если смерджить не 5 subject, а 25, если конечно такое потребуется в конкретном сторе.

Народ на этот счет костылит кто во что горазд там. Еще на тот момент, когда я смотрел, у них не было оптимизации для пересчетов дерева. Ну в смысле, если тебе нужно указать, что б дерево не пересчитывалось в случае если данные при эвенте пришли те же. Короче, аналога "Reselect", используемого в react.

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

Ээ, я думал их из-за перфоманса и убрали

Народ на этот счет костылит кто во что горазд там. Еще на тот момент, когда я смотрел, у них не было оптимизации для пересчетов дерева. Ну в смысле, если тебе нужно указать, что б дерево не пересчитывалось в случае если данные при эвенте пришли те же. Короче, аналога "Reselect", используемого в react.

так reselect же никак не привязан к тому, что стейт это стейт из редаксовского стора, ему что угодно можно скармливать ну и dropRepeats можно использовать с той же целью, да

или вот так =) https://github.com/brookemitchell/ramda-reselect#how-to

const createSelector = (...fns) => R.pipe( R.of , R.ap(fns.slice(0, -1)) , R.apply(R.memoize(fns[fns.length - 1])))

ну это трэш

const createSelector = (...fns) => R.pipe( R.of , R.ap(fns.slice(0, -1)) , R.apply(R.memoize(fns[fns.length - 1])))

Такие функции надо писать максимально низкоуровнево, без комбинации ap, of и apply ?

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

Это да