я думал history.back году в 2006 перестали делать ) нет, нормального решения нет если он откроет в новой вкладке

я думал history.back году в 2006 перестали делать ) нет, нормального решения нет если он откроет в новой вкладке

сяп

Норм спека, или ещё что-то нужно добавить? PASS __tests__/getRc.test.js getRc(): Read, parse rc file and return this data when it is exists and valid ✓ from given path in filename option (12ms) ✓ from $PWD/.jabtrc when filename option is not given (3ms) Returns given default data ✓ when resolve() throws error (1ms) ✓ when readFileSync() throws error (3ms) ✓ when JSON.parse() throws error (20ms) Returns preset default data when defaults option is not given ✓ and resolve() throws error (1ms) ✓ and readFileSync() throws error (1ms) ✓ and JSON.parse() throws error (1ms)

есть живые/не спящие?

Смотря зачем...

по ФП спросить хочу

есть: const run = fun => fun(object) run результат исполнения fun использует в своих целях а также есть функция которая преобразует одно значение: const make = val => 'some${val}'

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

что-то вроде run(pick('foo')) но дальше не могу придумать

https://t.me/scala_ru

Fira Code лучше всех

Input

Для лисперов есть каналы?

я сказал что это крутая гора

и меня забанили

Для лисперов есть каналы?

тот же вопрос

и меня забанили

/ban и правильно

Oleg banned Koprofil!

Разбираю один упоротый код, смотрите какая красота

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

мрак

Лорчане есть?

@erzent

а try/catch вообще нужны? Помню читал что-то что они оптимизируются плохо/не оптимизируются. Редко вижу в коде, а потом раз - и увидел в продвигаемых подходах в redux-saga для некоторых кейсов.

нужны конечно, что бы отловить ошибку

Ошибки можно и по-другому ловить, в общем-то

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

Ошибки можно и по-другому ловить, в общем-то

Расскажи, как в обычном коде можно еще ловить ошибки?

Консоль лог наше все

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

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

Вообще, лучше, конечно, чтобы переменные не менялись.

Каламбур, да.

ERROR: S client not available

ну как бы... что лучше, и что мы по факту имеем... не всегда совпадает

а try/catch вообще нужны? Помню читал что-то что они оптимизируются плохо/не оптимизируются. Редко вижу в коде, а потом раз - и увидел в продвигаемых подходах в redux-saga для некоторых кейсов.

Будут у тебя async await — будут и try/catch))

ну как бы... что лучше, и что мы по факту имеем... не всегда совпадает

Всегда. Почти. Ну, совсем почти.

Я не помню, когда в последний раз использовал let.

Но объекты ещё мутирую, грешен.

Веруешь ли ты в рамду, сын мой

?

Нормально ли при тестировании использовать такие конструкции? describe('getRc():', () => { const resolveThrows = (fname, def, opts) => () => { ... }; const readFSThrows = (fname, def, opts) => () => { ... }; const parseThrows = (fname, def, opts) => () => { ... }; describe('Returns given default data', () => { it( 'when resolve() throws error', resolveThrows(FILENAME, DEFAULTS, OPTIONS), ); ... }); describe('Returns preset default ...', () => { it( 'and resolve() throws error', resolveThrows( FILENAME_DEFAULT, DEFAULTS_DEFAULT, ), ); ... }); });

Типа комбинаторики много, и я сначала объявляю криейторы правил, и создаю правила, подставляя нужные параметры. Мм?

Или это всё от лукавого, т.к. неявно?

Веруешь ли ты в рамду, сын мой

Я ещё на пути к истине.

@ZeroBias Хоть ты скажи.

Ёпрст.

Да нормально) Хелперы в тестах это ок, если не увлекаться)

Ну, слава Богу.