@react_js - страница 932 - Telegram web archive

Sergey

да - императивны?

декларативны

Anonymous

мб, раз их расширять нельзя. По вашим словам

Илья

А что именно нравится?

Мне просто нравится, то как с ним пишется код.

Sergey

мб, раз их расширять нельзя. По вашим словам

кого нельзя?

Anonymous

классы

Sm•ok

Мне просто нравится, то как с ним пишется код.

А пробовал что ещё кроме редакса и мобх?

Sergey

классы

а разве можно?

Sergey

или вы наследуете в проекте их?

Anonymous

да

Sergey

пиздец

Sergey

уносите

Алексей

декларативны

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

Anonymous

понятно

Sergey

понятно

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

Danila

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

Декларативность-то как с этим связана?

Sergey

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

какая разница как они сделаны?

Sm•ok

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

Только так наследуются абсолютно все методы?

Илья

А пробовал что ещё кроме редакса и мобх?

Apollo в качестве стейт контейнера использовал.

Sergey

Только так наследуются абсолютно все методы?

ну да, будем создавать базовый класс компонента от него наследовать ещё а потом ещё

Sergey

https://ru.reactjs.org/docs/composition-vs-inheritance.html

Sm•ok

ну да, будем создавать базовый класс компонента от него наследовать ещё а потом ещё

Не делал так ещё, только считал теоретически возможным

Sergey

да

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

Sergey

да и вообще любой взрослый джаваскриптер понимает, что наследовать классы в жс это как-то криво

Sergey

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

Sergey

¯\_(ツ)_/¯

Sergey

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

Dmytro

Наследование компонентов в реакте 🤦‍♂

Danila

Мне кажется, что @mchuntonov просто перепутал ФП, декларативность и композицию или просто не с той стороны вообще смотрит, поэтому и не сразу понимает аргументы за хуки

Anonymous

хорошо. спасибо. что рассказали

Sergey

хорошо. спасибо. что рассказали

> But the really big problem with inheritance is that you’re encouraged to predict the future. Inheritance encourages you to build this taxonomy of objects very early on in your project, and you are most likely going to make design mistakes doing that, because humans cannot predict the future (even though it feels like we can), and getting out of these inheritiance taxonomies is a lot harder than getting out of them.

Sergey

хорошо. спасибо. что рассказали

чет я уверен, что сидишь по ту сторону экрана и насмехаешься, какие тут все тупые

Anonymous

я нигде не сказал, что с чем то не согласен или отвергаю. И нигде не говорил, что вы говорите что-то не правильно. Я просто задал вопрос чем это плохо. Получил много ответов. Изучу больше примеров кода, обращу на них внимание. Свою позицию я защищать не хочу, потому что действительно не так опытен и не готов так категорично спорить со всеми.

Danila

Самый простой ответ уже несколько раз дали - хуки - это возможность вынести самодостаточную логику за пределы компонента, разробить её на любое количество мелких частей, которые потом можно комбинировать, объединять и использовать полностью или частично в любых компонентах. Это - близко некоторым идеям ФП, это +1 к уровню декларативности, что всегда хорошо (выносишь детали конкретного куска логики за компонент), это большая ментальная разгрузка в мелких кейсах, где нужен один эффект и поле в стейте, можно писать 2 строки вместо 10.

Sergey

я нигде не сказал, что с чем то не согласен или отвергаю. И нигде не говорил, что вы говорите что-то не правильно. Я просто задал вопрос чем это плохо. Получил много ответов. Изучу больше примеров кода, обращу на них внимание. Свою позицию я защищать не хочу, потому что действительно не так опытен и не готов так категорично спорить со всеми.

круто

Danila

Пусть сова меня поправит, конечно, но кажись так

Anonymous

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

Sergey

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

https://medium.com/humans-create-software/composition-over-inheritance-cb6f88070205

ill-ya

привет всем, подскажите, как избавится от ошибки?

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

Алексей

Декларативность-то как с этим связана?

Ну просто императивное поведение этой самой декларативности весьма мешает. Так то я и классы декларативными могу назвать

Bogdan

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

я так же сделал) я подозреваю, что в декораторе дело, но не хочу решать

ill-ya

Серьезно, помогает иногда проверится и по возвращении решение приходит.

Danila

Ну просто императивное поведение этой самой декларативности весьма мешает. Так то я и классы декларативными могу назвать

Ну так нет абсолютной декларативности. Если ты обернул 1+1 в addOnePlusOne и потом оперируешь этй функцией - ты уже декларативный парень по сравнению с жалким прошлым тобой, не?

Danila

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

Danila

Тут ты пишешь x = useMousePosition(), а там ты сидишь ковыряешь детали реализации и ковыряешь их внутри компонента, что важно

Danila

Для этого изгобрели HOC, насколько я помню, но это привело к HOChell

Anonymous

Ребят, подскажите пожалуйста Есть родительский компонент в котором есть стэйт. И есть дочерний элемент, в котором инпут со значением стэйта родительского компонента. Для него стоит onChange который тоже находится у родителя. И тут получается петля: в onChange ставится стэйт, а value у инпута стоит то же зачение с стэйта родителя (через props). В итоге получается что значение инпута не меняется вообще. Как можно это решить?

Bogdan

1. императивность 2. многословность

но ведь функциональные компоненты не могут заменить классы в некоторых кейсах?