Тайпчекинг, как и тесты, — на прекоммит.

Тайпчекинг, как и тесты, — на прекоммит.

мы пишем сначала тесты, потом код и пока не сталкивались со стрельбой себе в ноги или руки )) наверное продолжим пока без Flow или TS.

Тесты могут проходить по коду, но по логике они могут ломаться :)

Логика работы компонента такая-то, под это пишется тест, а дальше код. Не тесты же под код пишутся. о_О

Логика работы компонента такая-то, под это пишется тест, а дальше код. Не тесты же под код пишутся. о_О

Недавно обсуждали, оказалось не важно когда ты пишешь тесты, до или после.

Важно чтобы они были :)

Важно чтобы они были :)

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

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

Зачем писать тесты когда у тебя отдел QA?

(^ Это шутка, не стоит на это отвечать)

Еще про flow. У меня есть динамический и в то же время асинхронный DI. Так вот flow позволяет описать все это дело и пролинковать как надо.

Имхо смысл статической типизации в том что она есть в рантайме, если ее там нет то пользы от нее только автодополнение

Имхо смысл статической типизации в том что она есть в рантайме, если ее там нет то пользы от нее только автодополнение

А при проектировании? Или возможности абстракции и DI с помощью TS'а это плохо?

Имхо смысл статической типизации в том что она есть в рантайме, если ее там нет то пользы от нее только автодополнение

Какой смысл от неё в рантайме?

А что без di без ts не существует ?

Статика может рассчитываться при написании кода. В рантайм уже не попадёт ошибка.

А что без di без ts не существует ?

У тебя есть интерфейсы в JS?

Имхо смысл статической типизации в том что она есть в рантайме, если ее там нет то пользы от нее только автодополнение

Статическая типизация в рантайне — это нонсенс

Можно хоть по имени DI делать, но это ж попахивает

Она же чекается при билде

Она же чекается при билде

+

Ну т.е. если даже взять большие языки типа c++. Мб я туплю, конечно, поправьте если так

У тебя есть интерфейсы в JS?

У меня нет интерфейсов в js так как языке их нет,

Вот без интерфейсов фигово, кстати

Единственное, что я бы точно взял из ts/flow)

Почему защитники статический типизации хотят натянуть ООП а именно ООП наследование и интерфейсы на язык с прототипным наследование ? имхо в js и так хорошо, вот только ввели сахар на наследовании через класс и людей как переклинило

Дал бог класс, даст и интерфейс

Но вообще тебя с ножом у горла их не заставляют использовать )

Из того что мне не нравится в js это детские болячки на сравнение и приведении типов при этом

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

Но вообще тебя с ножом у горла их не заставляют использовать )

Я не про использование, я про смысл который люди понимают в этом

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

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

Гы сука лол Какие вещи можно делать в классическом ООП и нельзя в прототипном ?

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

Причем тут говнокодеры?

Причем тут говнокодеры?

да не обращай внимания, наболело :)

Есть кто-то, кто шарит ассемблр?

В личку скину сейчас чат

Ребята, привет. RactJS спецы миддл нужны. Спрашиваю заранее за месяц. Потому как через месяц нужно будет вписаться в разработку с миддлом, который сейчас основу делает. В CRM клиента переходим с чистого js на React. Обязательна коммуникабельность, т.к. позже, вероятно привлечем еще пару миддлов. Синьоры тоже пойдут, но сравнивать не с чем, поэтому определить крут или нет не смогу, следовательно, буду выбирать ооочень осторожно. И возможно даже не выберу. Понимаю, что глупо звучит, но переплачивать за то, что человек просто назвался синьором, я не готов Джуниоры не нужны, тормозить работу будут. В личку кидайте: цену часа, самую крутую (по вашему мнению вашу работу), можно рассказать про тех часть и там кодом похвастаться (если впаблик продакшне не посмотреть)

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

Простите за невежество, но позволяет ли flow описывать функции высшего порядка?

Ну типа compose например как будет выглядеть во флоу-нотации

Ну типа compose например как будет выглядеть во флоу-нотации

Compose нельзя, это слишком круто пока что))

Точнее можно, но немного с костылями

Потому что compose ещё на один уровень выше чем просто функция высшего порядка (если упрощённо), там нужен variadic kinds

Потому что в compose неограниченное количество принимаемых функций. А просто описать, что функция возвращает возвращаемый тип передаваемой функции (дженерик) можно

Ну, уже хорошо :)

Ну такое кажется только хаскель из известных языков и умеет

Так что это вообще нормально)

Подскажите плз, у меня компоненты разбиты по папкам, в которых лежат файлы index.jsx, стили. Вопрос заключается в том, чтобы импортить их без указывания в пути "index.jsx". import List from './components/List' вместо import List from './components/List/index.jsx' Я где-то читал, что это можно настроить в webpack, мб кто-то сталкивался?

Resolve alias

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

https://github.com/airbnb/react-dates , но с моментом

В таком случае делается enum в TS'е. Если это будет намбер - это грустно

Enum в ts с версии 2 не делается

А интерфейсы не нужны, да

Подскажите самую удобный и простой способ валидации форм на реакте?

А интерфейсы не нужны, да

Вам кол по архитектуре

Вам кол по архитектуре

Type для слабаков да?)

Пока в ts нет номинальных типов, нет никакого смысла использовать интерфейсы. Да ещё это в js зарезервированное слово

Подскажите плз, у меня компоненты разбиты по папкам, в которых лежат файлы index.jsx, стили. Вопрос заключается в том, чтобы импортить их без указывания в пути "index.jsx". import List from './components/List' вместо import List from './components/List/index.jsx' Я где-то читал, что это можно настроить в webpack, мб кто-то сталкивался?

https://webpack.js.org/configuration/resolve/#resolve-extensions

Подскажите самую удобный и простой способ валидации форм на реакте?

https://github.com/hapijs/joi

Пока в ts нет номинальных типов, нет никакого смысла использовать интерфейсы. Да ещё это в js зарезервированное слово

Еще раз думаем, потом пишем. interface A contains method b. class C receives from DI/constructor implementation of interface A, and somewhere calls method b. Write a test for class C where it calls method b.

Зачем в этой связке интерфейсы? Есть типы, более продуманная в ts и flow конструкцич

Блядь. Ну как так-то

У тебя получится)

Ты вообще понимаешь, для чего делабт интерфейсы? Какие нахер типы

Ты вообще понимаешь, для чего делабт интерфейсы? Какие нахер типы

В ts есть конструкция type, прости что раньше не сказал

В ts есть конструкция type, прости что раньше не сказал

Вопрос посмотри:)

Давай по-другому. Ты когда-то писал код и архитектуру на чем-то кроме js?

ERROR: S client not available

const c = new C (mockWithBMethod); c.doSmth (); expect (mockWithBMethod.b ).to.have.been.calledWith (contract)

Давай по-другому. Ты когда-то писал код и архитектуру на чем-то кроме js?

Java/пых

Так, хорошо. Для чего в джавке интерфейсы?

Ну с хаскелем немного балкюсь

Так, хорошо. Для чего в джавке интерфейсы?

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

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

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

Потому что мы можем использовать тип, который больше фич в ts&flow имеет?

И не заигрывает со спекой es

https://webpack.js.org/configuration/resolve/#resolve-extensions

Спасибо!

И не заигрывает со спекой es

Так-то спека у тс своя.

Так-то спека у тс своя.

Он же superset

Введут в js interface и быть беде

Потому что мы можем использовать тип, который больше фич в ts&flow имеет?

Вот только интерфейсы подходят для описания архитектуры взаимодействия объектов, а типы как-то не очень

Вот только интерфейсы подходят для описания архитектуры взаимодействия объектов, а типы как-то не очень

Чем же типы не очень?)

А как можно протестить this.someMethod = _.debounce(this.someMethod, 300) в Jest? Чет не пойму

Введут в js interface и быть беде

ну ты так говоришь, будто microsoft мимо себя это пропустит.

ну ты так говоришь, будто microsoft мимо себя это пропустит.

Так это и проблема. Теперь чтобы делать интерфейс надо оглядываться на ts&flow. Вряд ли будет страшно, но практика плохая

Введут в js interface и быть беде

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

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

Да, скорее всего

Я вот сейчас не полностью уверен, но давай так: Есть интерфейс a, в нем три метода. Есть тип б, в нем те же три метода. Экстендим интерфейс а: Пути: 1) дописываем метод в интерфейс, получаем кучу ошибок ввиду того, что везде, где он имплементируется, не реализован новый метод. 2) создаем новый интерфейс, который экстендит уже существующий, используем его там, где надо. Твои пути решения проблемы с type?

Type B = A & Smth

Type B = A & Smth

Итого: class A implements C vs A:B

Не кажется ли второй вариант пидорством ?:)

implements тоже не обязательная штука

Если соблюдается контракт+интерфейс, то берем

Не обязательная, но код не только ты смотиришь

поясните базовую вещь - если тут пишут - https://github.com/uberVU/react-guide/blob/master/props-vs-state.md что PROP компонет сам себе менять не может

Что такое второе я не понял

Find usages

Объект твоего типа

то почему мы с редуксом делаем mapStateToProps