https://github.com/akashnimare/is-yarn/blob/master/index.js

не сложно же

но это не совсем то

подключить лоадеры и установить target и source?

есть забавный пакет

да, пакет забавный) надо чтобы yarn npm заменял в npm скриптах(

https://gist.github.com/zerobias/01eae0e49e5542ed85cb8074423fe757

лучше бы стиль в коде соблюдал

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

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

лучше бы стиль в коде соблюдал

Все претензии принимаются исключительно в пул реквест ?

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

Кто бы спорил

это ни разу не миксины

Почему же?

Почему же?

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

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

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

В js всё наследование динамическое

Иначе бы такие конструкции не работали

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

Я не создаю новый класс, я определяю наследника для существующего

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

смотри. был билд на CI 4 минуты, стал 1. Так npm install с 0 занимал 3 минуты.

смотри. был билд на CI 4 минуты, стал 1. Так npm install с 0 занимал 3 минуты.

Ну ок меньше кофе пьется. Дополнительные обвязки не мешают или не усложняют? Просто еще не успел поюзать.

что за дополнительные обвязки?)

Я не создаю новый класс, я определяю наследника для существующего

А сможешь еще адекватными тестами эту всю штуку покрыть?

у меня вопрос возник с electron приложением. Там postinstall: cd app && npm install. и почему-то из yarn npm не пашет)

а менять на yarn везде пока не хочется. тк сейчас это прям опционально, хочешь npm, хочешь yarn. но не в этом месте

ты сделал у себя alias npm = 'yarn'?

можно на 'yar' биндануть и ничего не теряется

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

ну он быстрый

вот и все счастливые

Всем привет! так и что, уже все реально начинают переходить на yarn -который выпустили в свет меньше месяца назад?

Всем привет! так и что, уже все реально начинают переходить на yarn -который выпустили в свет меньше месяца назад?

лично не собираюсь и не хочу пока не потрогаю + не вижу смысла вводить еще 1 левую зависимость.

А сможешь еще адекватными тестами эту всю штуку покрыть?

А в чём проблема протестировать один раз обычный extends класс?) const Execution = Sup => class extends Sup { get run() { return true } } class TestObject { get isTestObject() { return true } } tap('execution mixin test', function(t){ class ExtendedObject extends Execution( TestObject ) { } const tested = new ExtendedObject() t.ok(tested) t.ok(tested.isTestObject) t.ok(tested.run) t.end() }) /* # Subtest: execution mixin test ok 1 - expect truthy value ok 2 - expect truthy value ok 3 - expect truthy value 1..3 */

150 это много?

А в чём проблема протестировать один раз обычный extends класс?) const Execution = Sup => class extends Sup { get run() { return true } } class TestObject { get isTestObject() { return true } } tap('execution mixin test', function(t){ class ExtendedObject extends Execution( TestObject ) { } const tested = new ExtendedObject() t.ok(tested) t.ok(tested.isTestObject) t.ok(tested.run) t.end() }) /* # Subtest: execution mixin test ok 1 - expect truthy value ok 2 - expect truthy value ok 3 - expect truthy value 1..3 */

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

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

Что-то как-то всё сложно)) Добавив в пример memoization внутри функции, для проверки на расширение класса можно будет просто вызывать obj instanceof Execution( TestObject ) К тому же я не говорю, что пользуюсь этим постоянно, я просто показал пример) "мопед не мой"

ты сделал у себя alias npm = 'yarn'?

неа. в 15 версии точно были расхождения. сейчас полностью ок, если слинковать?

кстати lockfile можно отключить по дефолту?

кстати lockfile можно отключить по дефолту?

зачем?

потому что он мне не нужен?)

Что-то как-то всё сложно)) Добавив в пример memoization внутри функции, для проверки на расширение класса можно будет просто вызывать obj instanceof Execution( TestObject ) К тому же я не говорю, что пользуюсь этим постоянно, я просто показал пример) "мопед не мой"

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

Последнее время я все чаще слышу о библиотеке recompose. Ее пользователи есть и в этом чате. Может ли кто просто объяснить чем она сможет облегчить мою жизнь как пользователя реакта с редаксом? )

На официальном сайте нет ни одного внятного довода

Все в духе "она поощряет использовать то-то, но так же вы можете использовать и в прежнем стиле"

Thunk или saga? Что выбрать?

Thunk или saga? Что выбрать?

redux-observable

)

Выбор инструмента от многого зависит

redux-observable

Чем лучше? Он похоже тянет за собой rx

Thunk или saga? Что выбрать?

Thunk - 15 строчек, саги намного больше и довольно своеобразные

Чёт загоняюсь на тему куда лучше саги сохранять

Чем лучше? Он похоже тянет за собой rx

Тем, что rx - это очень много где применимая штука. Ее можно воспринимать как утилитную библиотеку для множетсва задач. А saga - это узкоспецифичный инструмент

Короче, освоил работу с rxjs, и это тебе пригодится много где, а сага лишь для определенного типа задач

Есть ОЧЕНЬ большая вероятность что в будущем тебе придется-таки работать с одной из FRP-библиотек (скорее всего rxjs, но это не принципиально, так как они все похожи по использованию и названиям операторов). Так что зачем тратить время на освоение саги, если потом все-равно придется осваивать rxjs? )

Короче, освоил работу с rxjs, и это тебе пригодится много где, а сага лишь для определенного типа задач

каким образом Можешь рассказать о своем опыте?

Сага небольшая, rx по размеру доков схож с lodash

Разного рода асинхронные задачи, и более наглядное их описание, чем работа с каллбеками. В какой-то степени rx-библиотеки можно описать как многократно расширенный словарь промисов. Вот зачем нужны промисы? За тем же нужны и rx-библиотеки. Только они обладают многократно большим словарем операторов.

react-bootstrap-table кто использовал?

как сделать локализацию там?

Салют! Извиняюсь за то что перебиваю, у меня тут пригорело. Надеюсь на помощь в вопросе: У меня есть миксин который хитро подтягивает локализацию, обращаясь к стору. Вот возникла проблема на разбиения больших компонентов на стейтлесс компоненты, ну и не опрокидывать же родительский миксин в них артибутом?

у плейсхолдеров

Как решить такое, не обращаясь к родителю по ссылке?

тупой вопрос, уже не надо)

Подскажите простую либу которая умеет анимировать скролл в зависимости от положение курсора на элементе. Когда курсор ближе к краю, тогда анимация быстрее

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

который может компилировать js в продакшин

https://github.com/petehunt/webpack-howto

Ребят. Я тут короч про Redux почитываю и чот не могу понять, если стэйт на приложение один и нужно с помощью редьюсеров возвращать новый объект стэйта после изменения это не вызовет перерендера всего проложения? Или же получается, что другие части будут обновлять своё состояние из глобального стейта только при определённом action'е? Типа если вызвался этот экшон - значит данные, необходимые для компонента поменялись и можно перерендериться?

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

connect проверяет пропсы в mapStateToProps и если они не изменились не вызывает рендер

Если у тебя сложный стейт то тогда использовать shallowCompare

Ребят. Я тут короч про Redux почитываю и чот не могу понять, если стэйт на приложение один и нужно с помощью редьюсеров возвращать новый объект стэйта после изменения это не вызовет перерендера всего проложения? Или же получается, что другие части будут обновлять своё состояние из глобального стейта только при определённом action'е? Типа если вызвался этот экшон - значит данные, необходимые для компонента поменялись и можно перерендериться?

https://telegram.me/javascript_jobs - обсуждение прям этого вопроса только что было)

ребят, пользовался кто redux-persist?

там есть какая-нибудь возможность отследить момент когда state пушится в localStorage?

А что делает эта либа вообще?

ну ты можешь на изменение стораджа подписаться

синхронизирует куски стейта или стейт целиком с localStorage (или подобной штукой) чтобы потом при старте восстановить их в стейт

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

а если нужно в самой глубине перерендер? cлаживать чемоданы и убегать?

а если нужно в самой глубине перерендер? cлаживать чемоданы и убегать?

Всмысле?

Всмысле?

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

это же пиздец, нет

?

Да

Вооот))

Именно поэтому это делать не обязательно))

жопа

ну я теоретик

до такого не доходило