Ангуляр это путь к позору, лучше мигрировать на реакт

Позор путь к позору

Ангуляр это путь к позору, лучше мигрировать на реакт

Не позорьте себя. Ангуляр ништяк

Дружище, новый тинькофф.ру в разы больше старого иб, включает в себя огромную неавторизованную зону, а в авторизованной не переиспользует (и не использовал) ни строки из бизнес логики старого иб. Да, я называю это "написать с нуля".

Слушай, ну я больше про то, что "переписать" и "написать с нуля" - практически синонимы

Не позорьте себя. Ангуляр ништяк

Не позорьте себя, Реакт ништяк

классные аргументы, да?

Не позорьте себя, Реакт ништяк

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

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

Уже пишем megaplan.ru

классные аргументы, да?

Насколько известно тинькофф с ангуляржс мигрирует ангуляр 2+, вот это аргумент

Уже пишем megaplan.ru

Тогда сочувствую

классные аргументы, да?

Когда я слышу слово аргумент то представляю ругающихся ментов

Тогда сочувствую

Не требуется, нам хорошо

Насколько известно тинькофф с ангуляржс мигрирует ангуляр 2+, вот это аргумент

Уже ангуляр 4+

А на самом деле angular + redux, вот это вещь

5

Уже ангуляр 4+

Ч. т. д.

Тогда сочувствую

Зря

Уже ангуляр 4+

Речь про интернет банк?

Ч. т. д.

Что это доказывает?)

Речь про интернет банк?

про ИБ для бизнеса

и некоторые внутренние проекты

про ИБ для бизнеса

вот они, кстати, как раз «переписывали». форкнули старый ИБ для физлиц и переписывают его на новый ангуляр

Слушай, ну я больше про то, что "переписать" и "написать с нуля" - практически синонимы

По моему мнению, «переписывать» - это постепенный процесс, когда в условно новом продукте используются части старого. В случае с tinkoff.ru такого не было, она писалась с нуля =)

В теории с ангуляра на реакт можно «переписывать», если проект грамотно написан и бизнес логика в целом не сильно зависит от платформы Но если проект грамотно написан, зачем переписывать?)

В теории с ангуляра на реакт можно «переписывать», если проект грамотно написан и бизнес логика в целом не сильно зависит от платформы Но если проект грамотно написан, зачем переписывать?)

Есть специальный отдел задача которого все переписывать

Есть специальный отдел задача которого все переписывать

ага, «отдел веб-разработки» называется

Так, товарищи фронтедеры, скажите мне пожалуйста, что нужно знать ньюфагу, чтобы сбацать проект на Тайпскрипте и Реакте (при условии, что я уже знаю и умею в реакт)?

каждые 6 недель переписываем

ага, «отдел веб-разработки» называется

Что там специального?

Что там специального?

._.

._.

Вот же ш

а… ну глубокое наследование это в принципе нехорошо ни где

Не соглашусь, после того как я понял главный профит наследования я теперь считаю наследование круче композиции (а множественное наследование еще лучше) При композиции каждое переопределение какого-то поведения требует создать объект. В итоге если у нас цепочка из 10 переопределений (например 10 хокков на реакт-компоненте) то на списке из тысячу объектов будет создано в сумме 10 тысяч объектов - а это тратится сpu на создание объектов, тратится в n раз больше памяти, и главное тратится в время на сборку всех этих объектов сборщиком мусора потом. Причем для хокков реакт-компонентов это не только время на создание объектов - это еще время на увеличения diff-а при рендере из-за n-кратного увеличения количества компонентов. А при наследовании для тысячного списка будет только тысячу объектов в рантайме - то есть, сколько бы раз бы не наследовались и добавляли или переопределяли методы, сколько бы цепочек переопределений бы не строили - да хоть тысячу хокков - в рантайме будет создан только один объект а не в n-раз больше. То есть наследование это механизм который позволяет вынести очень много работы в compile-timе и после того как я это понял я теперь не понимаю людей которые говорят что композиция лучше наследования

Рип

Даже пояснять ничего не нужно )

Ну дык, а что я неправ? Композиция явно хуже по производительности чем наследование

в 99% кейсов это похуй

что будет 10 обьектов а не один

а те кто попадают в 1% уже начинают решать эти проблемы сами

С реакт-компонентами там будет далеко не 1 процент. Реакт в рендер-методе на каждый перерендер создает новые объекты и цепочка из 10 хокков выльется в создании 10 объектов вместо одного и потом diff-а десяти компонентов вместо одного. И для списка из тысячу таких компонентов разница думаю будет заметна

С реакт-компонентами там будет далеко не 1 процент. Реакт в рендер-методе на каждый перерендер создает новые объекты и цепочка из 10 хокков выльется в создании 10 объектов вместо одного и потом diff-а десяти компонентов вместо одного. И для списка из тысячу таких компонентов разница думаю будет заметна

Ключевое слово тут "думаю". Без бенчмарков лучше даже не начинать такой разговор.

С реакт-компонентами там будет далеко не 1 процент. Реакт в рендер-методе на каждый перерендер создает новые объекты и цепочка из 10 хокков выльется в создании 10 объектов вместо одного и потом diff-а десяти компонентов вместо одного. И для списка из тысячу таких компонентов разница думаю будет заметна

чувак, удачи тебе с разгребанием адовой лапши из реакт-компонентов, наследующихся друг от друга

прям вот удачи

++

чувак, удачи тебе с разгребанием адовой лапши из реакт-компонентов, наследующихся друг от друга

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

Ну вцелом я с Богданом согласен. Ну наследоваться по разному можно... Главное делать это с умом

чувак, удачи тебе с разгребанием адовой лапши из реакт-компонентов, наследующихся друг от друга

А в каких случаях это будет адовая лапша? Чем кардинально отличается такой хокк с наследованием functon withProps(Component, props){ return class extends Component { static defaultProps = { ...(Component.defaultProps || {}), ...props } } }от такого хокка с композицией functon withProps(Component, props){ return class extends React.Component { render(){ return <Component {...props}/> } } }? И там и там хокки, только с композицией каждый хокк приводит к созданию еще одного объекта в рендере, дополнительного диффа в новом компоненте реактом и еще одной ступеньке в лесенке компонентов в девтулзах а с наследованием нет

Ах, если бы всё было так просто

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

А в каких случаях это будет адовая лапша? Чем кардинально отличается такой хокк с наследованием functon withProps(Component, props){ return class extends Component { static defaultProps = { ...(Component.defaultProps || {}), ...props } } }от такого хокка с композицией functon withProps(Component, props){ return class extends React.Component { render(){ return <Component {...props}/> } } }? И там и там хокки, только с композицией каждый хокк приводит к созданию еще одного объекта в рендере, дополнительного диффа в новом компоненте реактом и еще одной ступеньке в лесенке компонентов в девтулзах а с наследованием нет

recompact

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

Это все будет и в композиции :)

А в каких случаях это будет адовая лапша? Чем кардинально отличается такой хокк с наследованием functon withProps(Component, props){ return class extends Component { static defaultProps = { ...(Component.defaultProps || {}), ...props } } }от такого хокка с композицией functon withProps(Component, props){ return class extends React.Component { render(){ return <Component {...props}/> } } }? И там и там хокки, только с композицией каждый хокк приводит к созданию еще одного объекта в рендере, дополнительного диффа в новом компоненте реактом и еще одной ступеньке в лесенке компонентов в девтулзах а с наследованием нет

а для рендер пропов что?)

Это все будет и в композиции :)

ну вообще да

Вы так спорите постоянно как буд-то композиция это замена наследования. Нет, это дополнительная возможность в архитектуре

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

Так, товарищи фронтедеры, скажите мне пожалуйста, что нужно знать ньюфагу, чтобы сбацать проект на Тайпскрипте и Реакте (при условии, что я уже знаю и умею в реакт)?

Пока ваша дискуссия стихла повторю свой вопрос:

Пока ваша дискуссия стихла повторю свой вопрос:

при условии, что уже знаешь реакт, остается только ТС выучить

и готово

Так, товарищи фронтедеры, скажите мне пожалуйста, что нужно знать ньюфагу, чтобы сбацать проект на Тайпскрипте и Реакте (при условии, что я уже знаю и умею в реакт)?

эээ, тайпскрипт и реакт

Вай нот?

Пока ваша дискуссия стихла повторю свой вопрос:

create-react-app-typescript

если без этого, то тайпинги не забыть поставить

на tsc не полагаться, бандлить вебпаком через awesome-typescript-loader

вопрос очень абстрактный у тебя

и готово

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

без вебпака не получится

Ок, спасибо. Ещё что-нибудь?

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

да больше не нужно ничего вроде

два лоадера есть, и awesome typescript loader вроде как побыстрее typescript loader

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

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

ну да

Спасибо

Всем привет. Есть ли возможность запретить дочернему классу переопределять метод родительского?

Конечно

Посмотри так на него пронзительно

И пальцем «но-но-но!»

sealed или final почему-то не хотят добавлять, к сожалению :(

два лоадера есть, и awesome typescript loader вроде как побыстрее typescript loader

ts-loader (с опцией happyPackMode: true) + ForkTsCheckerWebpackPlugin (с подключенным tslint, что позволяет избавиться от tslint-loader) самый космос сейчас

В ts-loader недавно добавили ещё experimental watch api, но его пока не тестил, обещают ещё более ускорение

круто

надо попробовать

↑ Тру стори, самое быстрое решение по результатам моих тестов на нескольких проектах. Тслинт вообще иногда неюзабелен тслинт-лоудером (по полчаса работает)

а по flow тут тоже отвечают?

ts-loader (с опцией happyPackMode: true) + ForkTsCheckerWebpackPlugin (с подключенным tslint, что позволяет избавиться от tslint-loader) самый космос сейчас

Попробую, спасибо

а по flow тут тоже отвечают?

В описании ссылка

ForkTsCheckerWebpackPlugin можно перевести в async режим и тогда бандл будет готов ещё до тайпчекинга, что удобно когда например только стили колбасишь

class SomeClass { method() { return this.other() } other() { return 123 } } const a = new SomeClass(); const method = a.method method() Такую лажу на TS как то можно отлавливать?

playground со всеми включенными галочками не ругается, а в рантайме ошибка

only-arrow-functions не решает случайно эту же проблему с другой стороны?

ребята, как сконвертить type A = 'a' | 'A'; в переменную рантайма const myA = ['a', 'b']?