Ivan
function withSubscription(WrappedComponent, selectData) {
// ...and returns another component...
return class extends React.Component {
Ivan
Такая конструкция сложная
Ivan
Тайпинги падают в typescript
Maksim
да ну эти хоки
Андрей
Общие методы хотябы.
Смотри, в случае локализации ты перехватываешь value, для валидации on Change и т.п.
Ivan
Переходы сложнее в IDE
Ivan
Уже использую. Не сам выбирал правда.
Андрей
Там тебе надо просто работать с пропсах и, не опуская на уровень компонента.
Ivan
Короче композиция - наше всё?
Андрей
Верно
Ivan
Эххх. Спасибо
Дима
Общие методы хотябы.
Внезапно, но чтобы вызывать из компонентов одну и ту же функцию наследование не нужно
Sergey
Ivan
Композиция проще наследования
function withSubscription(WrappedComponent, selectData) {
// ...and returns another component...
return class extends React.Component {
Ivan
Вот это проще чем написать extends?
Sergey
Я пробовал разобраться с парсером их 10 наследуемых классов, реализация выбирается во время исполнения.
Ухх... Такой паззл
Sergey
Полный пиздец
Sergey
Код вообще перестает быть очевидным и читаемым
Sergey
ООП головного мозга...
Sergey
Я за однообразность. В этих композициях еще тайпинги теряются
На жс все равно невозможно нормально писать в ооп
Sergey
Это как заниматься сексом через матрас
Sergey
Чтобы не залететь
Андрей
Я за однообразность. В этих композициях еще тайпинги теряются
Используй нормальную систему типов.
Ivan
Зачем использовать ещё один язык?
Это оч маленькое дополнение. Если знаешь JS на крепкую пятерку автоматически и тайпскипт на 5- знаешь
Sergey
Ivan
В тс очень много своего
Нууу даже если так, я может много чего не использовал и TS меня устраивал. TS == JS для меня. Синтаксис практически одинаковый
Андрей
Да без проблем, просто тс туп как пробка.
Ivan
Да без проблем, просто тс туп как пробка.
Flow мне больше нравится пока что. Если он не баговый, то на него бы перейти
Андрей
Просто у него плохой тулинг и маленькое сообщество.
Андрей
По сравнению с ts, конечно же.
Андрей
Анонс Dart 2.0: Оптимизированный для клиентской разработки / Хабрахабр
https://habrahabr.ru/company/wrike/blog/349790/
Ivan
А Flow легко вкручивать в существующий ES6-7 react-redux-webpack проект?
Ivan
Typescript не особо легко
Андрей
Ts вообще не очень в существующий проект интегрировать.
Ivan
С TS проблема надо переименовывать файлы на ts, tsx и править их (importы и пр)
Андрей
С TS проблема надо переименовывать файлы на ts, tsx и править их (importы и пр)
В Flow пишешь комментарий там где тебе надо.
Андрей
И в этом файле проверка будет.
Ivan
Ну короч Flow проще вкрутить в такой проект чем TS
Андрей
Да.
Ivan
А автокомлит в IDE, все фишки проверки будут удобны как и в Typescript?
Ivan
IDE - Jetbrains
Андрей
С тулингом хуже.
Ivan
С тулингом хуже.
Ну подсказка хоть появится что метод принимает или возвращает отличные типы данных от передаваемых?
Андрей
Андрей
А где там основная разница с typescript, если не лень сформулировать?
Нет рефакторингов, чуть тормознее, хуже вывод ошибок.
Arlen
ребят всем привет
Arlen
http://www.altayresort.ru/ нужен такой слайдер, может кто знает какой фрейм ворк или js библиотека
ge0gr4f
b.addEventListener("click", function() {alert('Еще раз спасибо!')}, false); - вот к примеру сработает, да, но это канвас в целом реагирует. А как сделать чтобы кликая на шарик именно срабатывало событие ???
это не svg. так просто не получится. только если будешь запоминать координаты шарика, затем проверять координаты клика, а затем перерисовывать шарик с новым цветом. либо создавать отдельный канвас с шариком на фоне общего канваса и вешать на него, но все равно перерисовывать/пересоздавать
Oleg
@XaveScor ты зачем ответ-то удалил?
Oleg
http://www.altayresort.ru/ нужен такой слайдер, может кто знает какой фрейм ворк или js библиотека
в коде упоминается https://bxslider.com/
Дима
А Flow легко вкручивать в существующий ES6-7 react-redux-webpack проект?
За последние полтора года дважды переводил огромные проекты целиком на флоу. Можно начинать даже вообще без изменений в сетапе, сколько файлов хочешь покрыть — столько и покроешь. Насчёт рефакторинга — комоды эффективнее чем опции редактора, уникальные у каждого из команды. Я одним махом выпилил лодаш и конвертировал компоненты в современный типизированный формат
Sergey
Не все кейсы осилить может
Ivan
codemode. Я их не писал
Дима
Не все кейсы осилить может
Как раз таки в отличии от инструментов редактора кодмоды охватывают все кейсы которые выполнимы с помощью бабеля
Дима
Долго же кодмод писать, не?
Учиться писать тяжело) Но профит существенный. Я например сделал у себя автоматическое подставление метаданных в вызовы api. Разом снял тонну рутины по ручной адаптации кода под изменения схемы
Sergey
http://sinelaw.github.io/infernu.org/s/
Дима
http://sinelaw.github.io/infernu.org/s/
Нет проблемы описать идеальный язык, проблема в том, что в жс огромный синтаксис и бесчисленное количество эдж кейсов, авторы флоу именно в это и уперлись
Дима
А в чём проблема конкретно?
Дима
Это косяк вс кода самого по себе