давай так делать каждый день

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

вот поэтому иногда нужно что то сверху, но вот такие штуки как Promise лучше полифилить, чем использовать Bluebird

+

я имею ввиду функционал

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

никогда не перекочует

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

бабель юзаем чтобы писать на новом жс

никогда не перекочует

+ :)

я имею ввиду функционал

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

частично перекочует конечно

через лет 5

в новых проектах

но наверное нет )

в новых проектах

+

итак мы пришли к выводу: блуберд не нужен

.finally уже есть в пропозале, таки полифилл будет скоро (или уже есть)

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

В стандарте нет множества удобных утилиток, что есть в lodash. Лично меня порой парит их самому писать

superagent тоже, так как над fetch пишется обертка всегда

Вместо Bluebird нужен https://polyfill.io/v2/docs/

Тащить его целиком, канеш, от лукавого, но потырить то, что нужно и выкинуть остальное сам б-г велел

тащить не нужно

он же сам подключает только необходимое

Тащить его целиком, канеш, от лукавого, но потырить то, что нужно и выкинуть остальное сам б-г велел

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

Тащить его целиком, канеш, от лукавого, но потырить то, что нужно и выкинуть остальное сам б-г велел

или ты не о полифилле?

по useragent

Я о лодаше

Про полифилл я в курсе

проще ramda юзать он прям хорош

и чем же проще?)

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

и чем же проще?)

фп же

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

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

хотя возможно что-то поменялось

Alex уже сто раз тут обсуждали) для лодеша есть плагин babel-plugin-lodash

а для рамды babel-plugin-ramda

только одно работает, а другое нет

проще ramda юзать он прям хорош

Ну не проще, но мне лично нравится, да

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

только вот рамда имеет каррированные параметры

для минимальных нужн пару тройку методов самое то

проще ramda юзать он прям хорош

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

а для рамды babel-plugin-ramda

для рамды тож работает плагин лодаша)

Единственное чо, некоторые видят всякие там juxt и страшно пугаются :)

А я над проектами все-таки не в одно рыло работаю

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

близки == привычны мне и то и то показалось диким так что одинаково

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

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

А я над проектами все-таки не в одно рыло работаю

Особенно на тех, где фронтенд пишут отбитые пыхеры, да?))

Ну это отдельная песня и у нас таких не водится

По щастью

Ну, я помню, ты жаловался

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

в этом и плюс

Я работал с такими одно время плотно

api.validateEmail({email: s_.email}).then(res => { if (res.blabla) { return 'error'; } }).then(err => { if (!err) { api.blabla(sdfsdf).end(..) } })

в этом и плюс

с какой стороны зайти) но да, в чем то плюс

выглядит так

чем выше порог входа, тем меньше говнарей попадет на собеседование

оценивать по знанию рамды мммда

чем выше порог входа, тем меньше говнарей попадет на собеседование

ну, вот неправда, сейчас фп станет мейнстримом - тогда вообще кисель будет, все будут думать что они фп пишут

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

только вот рамда имеет каррированные параметры

А как же lodash/fp?

А как же lodash/fp?

он же совсем плохо написан?

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

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

комбинаторы? это же из логики, не?

комбинаторы? это же из логики, не?

фп вообще походу матано-ореентированное

фп вообще походу матано-ореентированное

для кого как) имхо знать о композии функций уже достаточно)

он же совсем плохо написан?

Реализацию не смотрел, но всё-таки находил почти все те вещи, которые в рамде использовал. Использовал не много вещей, но основные есть. Там даже алиасы есть для функций, которые дублируют названия функций из рамды.

ERROR: S client not available

Реализацию не смотрел, но всё-таки находил почти все те вещи, которые в рамде использовал. Использовал не много вещей, но основные есть. Там даже алиасы есть для функций, которые дублируют названия функций из рамды.

Аласы не просто так появились ведь

Лично из своего небольшого опыта ФП в JS скажу, что если речь идёт об обработке большого массива данных, то лучше использовать for. Если не прав, то поправьте.

api.validateEmail({email: s_.email}) .then(res => {

как можно вызывать reject?

чтобы попасть в catch

throw new Error()

а если мне нужно передать строку?

в качестве аргумента

Лично из своего небольшого опыта ФП в JS скажу, что если речь идёт об обработке большого массива данных, то лучше использовать for. Если не прав, то поправьте.

Да прав. Особенно если надо быстро

а если мне нужно передать строку?

Ну передай в ошибку

мне конкретно нужно чтобы содержало 1 слово

без Error:

Ну потом возьмешь из error.message

ща проверю

Лично из своего небольшого опыта ФП в JS скажу, что если речь идёт об обработке большого массива данных, то лучше использовать for. Если не прав, то поправьте.

Не просто for, а for классический, потому что for of помедленнее map будет, пожалуй

И таких мест на всё приложение, как правило, немного

И таких мест на всё приложение, как правило, немного

А как в репо с лерна гонять тесты и покрытие? Травис и коверолс. Просто я не представляю как это адекватно должно быть

Не просто for, а for классический, потому что for of помедленнее map будет, пожалуй

Конечно классический.

А как в репо с лерна гонять тесты и покрытие? Травис и коверолс. Просто я не представляю как это адекватно должно быть

Ну во первых в трависе можно любые скрипты прописывать, во вторых корневой package.json никто не отменял)

Ну во первых в трависе можно любые скрипты прописывать, во вторых корневой package.json никто не отменял)

С тестами вроде понятно А с покрытием

Это уже от твоего тест-раннера зависит, скорее всего

Лерна ж это просто небольшая абстракция над prepublis preinstall скриптами

И таких мест на всё приложение, как правило, немного

Смотря какое приложение. Если легкое UI с React, то да. А если работа с императивной графикой(canvas, webgl), то тут уже не до ФП, как мне кажется.

Смотря какое приложение. Если легкое UI с React, то да. А если работа с императивной графикой(canvas, webgl), то тут уже не до ФП, как мне кажется.

Лол

d3 иммутабелен

Как бы

И не то чтобы повернут на фп, но явно ближе к этой парадигме

В принципе, на этом примере вопрос производительности фп в жс можно закрывать

Лерна ж это просто небольшая абстракция над prepublis preinstall скриптами

Ладно, посмотрим)) Спасибо

если я юзаю SSR, нужен ли мне react-router на клиенте?

если я юзаю SSR, нужен ли мне react-router на клиенте?

Да

а для чего?