отсюда https://mobile.twitter.com/janiczek/status/859156300357390337

Причём документирован так, что лучше - никак, чем так))

Одна из худших документаций что я видел пожалуй, не хватает только вместо объяснений сразу "тут вполне очевидно, что" как в учебниках по матанам всяким

всем в укрытие https://github.com/ElmCast/elm-node

ну это игрушки какие-то. Где рендер виртуального дома в строку, например? Да и т.к. они используют нативные модули путь в elm packages пока закрыт.

https://twitter.com/janiczek/status/859179099440414720

кстати, в 0.19 обещают много интересного https://github.com/elm-lang/projects/blob/master/roadmap.md#how-do-i-make-a-single-page-app

да выбор фреймворка не простое дело в наши дни, все обещают много

https://www.youtube.com/watch?v=1CLBANCVHTw

да выбор фреймворка не простое дело в наши дни, все обещают много

Скорее выбор из чего компилировать в жс. ?

это не меняет сути дела)

Причём документирован так, что лучше - никак, чем так))

чет я не понял, в чем беда его доки

видал я доки и похуже

с доками все норм

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

и раскинуто

ну эт да

здесь не поспоришь

от балды как-то там накидано всего)

даже нет единой стратегии именования

хз там балда такая должна быть заряженная чтоб такие вещи накидывать

Привет, хотел спросить по тестам, если я тестирую функцию которая возвращает результат другой, то могу ли я в тестах expect данные передавать результат от функции которая будет вызвана внутри тестируемой, или я не должен пользоваться функциями которые вызываются внутри тестируемой?

Например: const a = (someProp, data) => { ...всяческие условия return b(data); } В одном из тест кейсов могу ли я писать так: expect(b(data)).toEqual(a...) Чтобы при изменении b не затрагивать тест а

ну и естественно тестировать b

не стоит так делать

тебе надо b индджектить

тебе надо проверить выполнение результата

у тебя функция a внутри вызывает какую то функцию b, по хорошему ее надо как аргумент указывать внутри функции а

тогда ты спокойно можешь застабить ее

и проверить выполнение скоупа функции а

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

ты хочешь проверить правильно ли работает функция а

сама абстракция а

и ты проверяешь ее застабив все внешние зависимости

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

Это да, спасибо , но немного уточню, тут речь идет о reducer ,просто там внутри есть функция b она больше даже как util функция идет

как-то так

внутри reducer

то есть как обычный редусер (state, action)

а это неважно ты сам решаешь насколько грязный твой тест

но в идеале

функция чистая

получила вернула

без сайд эффектов

если тебе надо что-то использовать ты явно инжектишь

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

тогда ты разбиваешь функцию на разные маленькие функции

То есть внешний инджект это уже грязно считается ?

внешний не являющийся аргументом имею ввиду

каждая из которых имеет разумное кол-во инжектов через аргументы

Спасибо большое!)

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

так

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

среднестатическая функция делаем как минимум 3-4 вещи

каждый if else

это еще один респонсибилити в копилку функции

так что как всегда надо взвешивать вкаждой конкретной ситуации

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

но не совсем мелкие

как-то так

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

точнее неподдерживаемо

колл стек уходит в бесконечность

это еще один респонсибилити в копилку функции

не, так мерять ответственность не оч затея

самые норм подходы: 1. количество вариантов ответа "для чего вам использовать эту функцию" 2. сколько ролей(менеджер, начальник по продажам, начальник по кадрам и т.д.) могут запросить требование, которое повлияет на эту функцию

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

идеал не нужен

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

я сам не пишу безифовые функции

все в меру

просто надо иметь в виду

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

и держать под уздой

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

иф не порождает ответственность, про мелкие опять же

это связь между coupling и cohesion

очень даже порождает потому что контролирует флоу

и?)

ретурн тож контролирует)

и вызов другой функции контролирует

не совсем понимаю аналогию

ретурн это конец функции

ифы опредлеяют флоу функции до конца

какая разница между: if (a) { b() } else { c() } и: a.then(b, c)

сама функция выполняет одно действие

конкретно здесь никакой разницы

промис чейнинг это тоже контрол флоу

эт не промис

но не суть

thenable

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

но это в идеале

нет, не указывает

опишите что такое идеал?

и почему это идеал

идеал это чистая функция в функцинальном понимании

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

с единственной ответственностью

unit сложности

максимально делимый