Ну они то обоснованно это пишут.

>кто ты такой, чтоб это делать

Хайповые статье в ваших интернетах пишут, что хоки не нужны

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

Яркий пример это если тебе нужны lifecycle хуки ?‍♀️

что за доклад? есть ссылка?

что за доклад? есть ссылка?

+

что за доклад? есть ссылка?

+

что за доклад? есть ссылка?

к сожалению ссылки нет. доклад с Минского BeerJs

ну lifecycle хуки - это вроде единственный пример, где нужны хоки.

ну lifecycle хуки - это вроде единственный пример, где нужны хоки.

наверное, а разве нужно больше ? )

ну lifecycle хуки - это вроде единственный пример, где нужны хоки.

Не совсем, иногда тебе нужно чуть ли не весь компонент завернуть в render пропу. Тогда тоже проще воспользоваться хоком...

? а find каждый раз не бьёт по нему ?

бьёт, ты бы для начала фразу "для начала" нашел бы. А потом , для начала, подумай, что в такой схеме с созданием фунции в рендене самое уязвимое место - find'ы в функции, или пересоздание самой функкции...

ну да, если у тебя просто проксирующий проспы компонент, типа как коннект у редакса, то лучше хок, это понятно.

бьёт, ты бы для начала фразу "для начала" нашел бы. А потом , для начала, подумай, что в такой схеме с созданием фунции в рендене самое уязвимое место - find'ы в функции, или пересоздание самой функкции...

Воу, чувак это сарказм был....забыл табличку

бьёт, ты бы для начала фразу "для начала" нашел бы. А потом , для начала, подумай, что в такой схеме с созданием фунции в рендене самое уязвимое место - find'ы в функции, или пересоздание самой функкции...

У тебя там какой-то научный проект?

Не распинайся)

больше не забывай:)

Ну а так, как я понимаю, минусов особо у рендер пропсов нет?

Ну а так, как я понимаю, минусов особо у рендер пропсов нет?

если их много они некрасивые )

ну это дело вкуса :)

Ну а так, как я понимаю, минусов особо у рендер пропсов нет?

Если у тебя их будет много в одном компоненте ты можешь запутаться в этих стрелках и рендер функциях

Я видел что-то типо compose для рендер пропов, но тогда появятся такие-же проблемы как с хоками: не всегда понятно откуда, коллизия имен - как на слайде выше.

Парни а нормально ли из селектора делать возврат return {obj1, obj2} ??

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

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

Да, должны быть. Это легко проверить.

Парни а нормально ли из селектора делать возврат return {obj1, obj2} ??

Объясню зачем я это делаю у меня есть таблица, и 4 связных сущности. Все нормализованно, я хочу в селекторе выдавать себе денормализованную строку со всеми связными данными делает ли так кто то в реакт ?

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

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

тоесть потход например author.byid[books.byid[1].author].nameFull такой код в компоненте будет более лучшим решением ?

Ребята, какое сейчас самое оптимальное и удобное решение для работы со стилями? (стайлед компонентс, цсс модули?)

тоесть потход например author.byid[books.byid[1].author].nameFull такой код в компоненте будет более лучшим решением ?

Парни хелп, помогите с вопросом

Ребята, какое сейчас самое оптимальное и удобное решение для работы со стилями? (стайлед компонентс, цсс модули?)

SC

почему я юзаю SC в реакте? Ответ очевиден css-loader sass-loader style-loader postcss-loader node-sass

почему я юзаю SC в реакте? Ответ очевиден css-loader sass-loader style-loader postcss-loader node-sass

2 и 5 можно спокойно выкинуть

Ребята, какое сейчас самое оптимальное и удобное решение для работы со стилями? (стайлед компонентс, цсс модули?)

можешь хоть scss писать по старинке, все норм (бери что больше нравится)

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

Ребята, какое сейчас самое оптимальное и удобное решение для работы со стилями? (стайлед компонентс, цсс модули?)

https://youtu.be/eOBz3_mQwo8

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

бэм решает

бэм решает

/warn бэм

/warn бэм

ро )

не, пока так

а, тут бан за ***?

да

это слово котороенельзяназывать

бЕм же

это слово котороенельзяназывать

почему?)

технология, которую не называют в слух

традиция-с

А вы для styled-components стили в самом компонете храните или делаете их импорт? А то компонент получается слишком большим

должны же быть у чатика свои традиции

принято)

Парни помогите с вопросом

А вы для styled-components стили в самом компонете храните или делаете их импорт? А то компонент получается слишком большим

Я делаю вот так Component index.jsx styles.js

http://telegra.ph/React-rules-07-24 в прежних правилах было про это

Я делаю вот так Component index.jsx styles.js

Ты джун?

Ты джун?

рофл с чего?

А вы для styled-components стили в самом компонете храните или делаете их импорт? А то компонент получается слишком большим

По разному можно. Если хочется серьёзно подойти к вопросу - Atomic Design

Ты джун?

давайте вы не будете здесь выяснять отношения

рофл с чего?

Та не это просто вопрос)

отдельная папка с components, где layout, header со index.js и header.js (например) , импорчу из в страницу из pages, либо containers p.s у каждого свои взгляды

давайте вы не будете здесь выяснять отношения

Сенатор можешь помочь в одном вопросе ?

отдельная папка с components, где layout, header со index.js и header.js (например) , импорчу из в страницу из pages, либо containers p.s у каждого свои взгляды

есть взгляды, а есть подходы

Я делаю вот так Component index.jsx styles.js

то есть это нормальный подход? я думал фишка SC в том что и стили и код в одном файле

то есть это нормальный подход? я думал фишка SC в том что и стили и код в одном файле

фишка sc в том что стилизованные компоненты легко переиспользуются

есть взгляды, а есть подходы

аргумент, так аргумент :)

ERROR: S client not available

то есть это нормальный подход? я думал фишка SC в том что и стили и код в одном файле

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

кстати, как в SC с автокомплитом, пару месяцев назад Emmet там не работал

работает все

кстати, как в SC с автокомплитом, пару месяцев назад Emmet там не работал

плагин для Webstorm и все гуд

можно писать через template tags или через obj

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

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

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

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

я их снизу кладу

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

Да согласен, но мне кажеться мой вапрос затрагивает всех, кто работает в связки реакт редакс, и заботиться о структуре своего стора.

я их снизу кладу

для const же нет хоистинга вроде?

то есть это нормальный подход? я думал фишка SC в том что и стили и код в одном файле

Что различный мусор в одном файле с компонентом. Разделяй и властвуй!

для const же нет хоистинга вроде?

так у тебя же же скоупы разные

для const же нет хоистинга вроде?

Конечно же const будет в var переделан.

Конечно же const будет в var переделан.

не факт и мы сейчас не берем в расчет это

так у тебя же же скоупы разные

можешь подробнее? чет не понимаю

const a = () => console.log(hello) const hello = 'hello world' a()

https://codesandbox.io/s/ry9okp11qo

мдемс)

у меня нет еслинта :)

const a = () => console.log(hello) a() const hello = 'hello world'

так работать не будет

ну эт понятно. но все равно это правило не зря существует. по моему это минус к читаемости когда что-то используется до объявления

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

ну эт понятно. но все равно это правило не зря существует. по моему это минус к читаемости когда что-то используется до объявления

после питона, хоист в жс был непонятен

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

не, все равно неоч

мне не очень разносить компонент на два файла

либо пихать стили до логики

Я внизу через function объявляю

И оно хоистится

const Wrapper = styled.div``