значит надо учитывать где этих данных нет и думать что делать

Ты можешь кастомные блоки обработчики навесить по желанию.

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

вот так например vk.group.posts.title.reject(&:nil?)

это же от задачи уже зависит. Можешь написать конкретный кейс.

сложна

map(filter(map(...), ... ), ...)

R.pipe( R.map(fn1), R.reject(R.isEmpty), R.map(fn2), ...)

es5, кстати

Что за R кстати?

Что за R кстати?

Ramda

Бесточечная композиция функций - кайф)

ramdajs.com

> Бесточечная композиция функций just one question, why?

> Бесточечная композиция функций just one question, why?

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

В примере выше те же точки только больше символов

плюс, я могу написать например так

stuff .map .reject() .select() и также менять их местами и редактировать

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

В примере выше те же точки только больше символов

Ты не можешь вставить вместо одного из шагов какую-либо свою фугкцию или целый пайплайн

больше похоже на искуственное граничение?

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

в этой рамде ведь принципиально другой подход верно? только я его не понимаю.

больше похоже на искуственное граничение?

Это расширение возможностей) Через точку можно вызывать только заранее добавленные в либу вещи, а без точек — что угодно

Плюс мне не нужно упоминать данные вообще

А, тоже верно

http://fr.umio.us/why-ramda/

я как то не подумал об этом.

У меня просто не помню чтобы нужно было вызывать что то чего мне не хватало.

обычно просто кастомный обработчик писал.

Ну это и есть кастомный обработчик, только в одну срочку)

Сейчас найду пример)

Ну это и есть кастомный обработчик, только в одну срочку)

stuff.map(&:title).map { |e| "#{e.title} - is awesome!" }

у меня тоже в одну.

т.е я пытаюсь понять преимущества рамды в подходе, кроме того, конечно же что можно lazy назначить заранее (хотя в рубях недавно тоже стало можно)

(вроде)

stuff.map(&:title).map { |e| "#{e.title} - is awesome!" }

stuff

У меня его нет, у меня на выходе функция, его принимающая

Да я понял что ты заранее все это назначаешь.

Для JS наверное и неплохая вещь.

Во, это один целиковый поток исполнения с кучей опций и обработок, читать снизу вверх https://github.com/zerobias/speak-r/blob/develop/app/core/splitter.js

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

> потому что я вообще не понимаю происходящего)) Перловые однострочники FTW

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

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

В смысле?)

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

Ну, это оно и есть

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

Да

Вот, а у меня не надо лезть к определению.

оно сразу там где юзается.

А зачем? Я лучше напишу функцию один раз

Потому что эти обработчики редко когда совпадают

В плане? А если у тебя пришли не те данные, а ты от них с точкой что то вызываешь?

В смысле не те данные?

как у тебя могут прийти не те данные?

Вместо массива - число, а ты от него .map делаешь

Вместо массива - число, а ты от него .map делаешь

Каким образом оно так получится то? ))

Может у меня еще объект придет?

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

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

А не fatal error

Не может программа не ломаться

У тебя всегда могут быть моменты которые ты не учел

и если программа вместо того чтобы выдать фатал станет unusable - будет хуже

Нет, она просто грамотно соберет данные для отладки и всё выведет в нужной форме

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

ERROR: S client not available

Нет, она просто грамотно соберет данные для отладки и всё выведет в нужной форме

Объясни. Представь что АПИ ответило тем способом которым ты не ожидал. А тебе надо пользователю страницу отдать. Что ты предлагаешь делать?

я сваливаюсь в FATAL ERROR потому что апишка не должна так отвечать ни в коем случае.

соотв пользователь видит "произошла ошибка, попробуйте позже".

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

Всегда есть варианты которые сложно учесть.

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

Подожди. Пользователю ты что отображаешь?

разработчики курят логи

в логах все эксепшены есть.

А какие логи, если у тебя программа упала?

ну, я на рельсах

в логах все эксепшены есть.

В логах у юзера, а по упало

оу, я про вебсайт говорил все это время ахах.

Извини.

Да, на фронте надо собирать данные для какого нибудь багснета.

Тем не менее представим что фронт сломался. Что ты покажешь пользователю? наверное в конкретном куске напишешь "извините произошла ошибка, попробуйте позже" верно?

по возможности оставив все остальное приложение работать.

Я сейчас в голове представляю react приложение если что.

по возможности оставив все остальное приложение работать.

Что значит по возможности, ты же в error выпадаешь?)

Имея Maybe я не могу себе представить, как что-то вообще может идти "не так"

запросто. Что то может пойти не так. Не обработанная ситуация.

Допустим никто не обрабатывал момент что этот микросервис отвалился, вариантов тысячи.

До тех пор пока не пришел ответ у меня объект имеет значение Maybe Nothing()

До тех пор пока не пришел ответ у меня объект имеет значение Maybe Nothing()

На чем фронт пишешь?

ты ведь про фронт верно?

Ну не обязательно

На ноде это даже лучше работает

Ну если про бэк то я просто сваливаюсь в FATAL ERROR

потому что это действительно не обработанная ситуация

и я должен ее быстро увидеть.

просто на фронте и бэке подходы кардинально отличаются.

Ну я скорее про сам подход

Если я попытаюсь вызывать у объекта Either.Right(serverResponse) какой то ключ, а его там не будет, то у меня будет объект Left('handler123 recived wrong data'), который автоматически безопасно пройдет через любые обработчики и будет корректно документирован любым способом