с 90% вероятностью он там будет лежать ))

это невероятно тупой аргумент

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

isarray неплохой модуль

помимо всего прочего, у меня flow, а для статической типизации нужны вменяемые API

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

что не принято в js экосистеме

сваггер - и неожиданно принято

я про js api

вот кстати про бизнес-логику

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

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

ну это по определнию велосипед

ну может процентов 5 времени это занимает, да

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

если глаз наметан, на мой взгляд быстрее

ты уже примерно понимаешь, что это вот скорее всего в lodash есть, а это там-то и тд

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

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

плохой пример

иногда сантехники дотачивают ключи если они не совсем подходят ))

какие основания считать, что код с npm лучше того, что ты напишешь сам?

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

или что он вообще работает?

в тесты посмотреть

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

или ты пишешь быстрее, чем читаешь?

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

дописать нужные. Это быстрее, чем все написать

вы никогда PR с тестами не видели?

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

это ты сейчас говоришь, понимая redux вдоль и поперек)

у меня как раз руки чесались недавно thunk самому написать) Как раз из-за типов

да, потому что я как-то раз такое сделал, еще когда не было редакса

это заняло 15 минут

это все нас возвращают к аргументам про других разработчиков

если бы я пошел в npm, не знаю чем бы кончилось

доки существуют не для тебя. А для других разработчиков

опять же утилы - от силы 10% кода

допустим их заменить либами с npm с отличными доками

утилиты пронизывают твой код весь

на них держится код

90% кода останутся как есть

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

это не фреймворк, это просто функции, чаще всего pure

эм, если у тебя isArray не правильно работает, все может развалиться, не?)

Я не пишу свой isArray

если у тебя не правильно работает debounce, клиент может данных не дождаться в каких-то случаях

и так далее

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

я говорю про то, что утилы, это просто функции с простым конкретным функционалом

конечно

как ключ

и вытачивать свой необязательно. Можно за 50р купить в соседнем магазине

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

его уже протестировали. И если он тебе резьбу сорвет - есть куда пожаловаться)

кто знает, что там в магазине

> @gusnkt есть куда пожаловаться куда? на гитхаб? это явно решит все проблемы

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

ну это отдельная история - само собой

> @gusnkt есть куда пожаловаться куда? на гитхаб? это явно решит все проблемы

угу, сделать PR

зачем мне тратить время на это?

это как дерево посадить))

в общем

вот линус тебя прямо точно не одобряет

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

ты чего, тогда тесты прийдется писать. Там 5 строк, ну зачем тесты?

ERROR: S client not available

лол) у меня 100% покрытие тестами всех утил. плохой пример!

у нас на проектах обычно требуется покрытие 50-70% больше уже излишне потому что на написание тестов потратишь времени больше чем на ручное исправление всплывших во время эксплуатации в этих местах багов

100% покрытие к тому же не гарантирует абсолютную стабильность?

ага

нет, конечно. но всема неплохо

Ребят, как можно закрыть nodejs процесс не из самого процесса? Есть скрипт, типо upgrader-а, который должен закрыть nodejs процесс, заменить/обновить файлы и снова запустить. Все остальное реализовал, сейчас вспомнил про убийство nodejs процесса. Да убить так, чтоб upgrader не убил самого себя(ведь upgrader - это скрипт на nodejs)

по pid прибей

pid удобно в файлик при запуске писать

Это практикуют в продакшене?

process.kill(123, ’SIGTERM’)

Ребзя, а pure-json-api чем-то выигрывает у RESTful ?

> Владимир Это практикуют в продакшене? чаще всего такие вещи на баше пишут

но суть та же

Это практикуют в продакшене?

вполне нормальное поведение, если надо что то перед смертью сделать то можно обработчик на sigterm повесить

не можно, а нужно)

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

А это все на одной машине происходит или удаленно?

# Что-то я не понимаю этого примера https://github.com/reactjs/redux/blob/master/examples/todos/index.js рендер вызывается один раз в index.js а как оно дальше работает? Суть реакта, как мне казалось, в вызове render реактом при изменении стейта

лол

state это миф

ну это в другой чат но вообще в большинстве случаев render вызывается ровно также 1 раз. А дальше уже реагирует дейсвтительно элемент на изменение state/properties

Кто-то кроме меня хотел бы в es7+ вот такой оператор existial prop accessor?: const {fooBar} = res?.data?.buisnessData // equals const fooBar = _.get(res, 'data.buisnessData.fooBar')

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

Кажется это можно запрототипировать на sweet.js

Линза для доступа к существующему свойству?

да ух ты так это и есть частный случай линз? Они в хаскеле же более широкий смысл имеют?

Ну я просто такую штуку на линзах реализовывал, по сути же это они и есть, по крайней мере в смысле lenses Ramda

Очень такой фичи не хватает, может соберёмся и сделаем propose?

Очень такой фичи не хватает, может соберёмся и сделаем propose?

он уже скорее всего есть

https://github.com/claudepache/es-optional-chaining

Кто-то кроме меня хотел бы в es7+ вот такой оператор existial prop accessor?: const {fooBar} = res?.data?.buisnessData // equals const fooBar = _.get(res, 'data.buisnessData.fooBar')

да, хотел бы, видел подобный синтаксис в C#. странно, что еще не добавили)

Офигеть, даже синтаксис совпадает!