в рабочем проекте сделал менюшку с огромной вложенностью но без close хендлера. Там попробовал бегать по менюшке через Children.map и мемоизировать В итоге вроде получилось норм

ох, я этим путем тоже ходил. очень бесит, когда вроде передаешь что-то, а оно потом видоизменяется через React.Children. очень неочевидно

хотя конечно, можно делать const Menu1 = useMenu() но зачем?

const { Menu, onClose } = useMenu() <Menu> <span onClick={onClose}>Item</span> </Menu>

const { Menu, onClose } = useMenu() <Menu> <span onClick={onClose}>Item</span> </Menu>

видно ошибку?

const { Menu: UserMenu, onClose: onCloseUserMenu } = useMenu() const { Menu: CardMenu, onClose: onCloseCardMenu } = useMenu() <UserMenu> <span onClick={onCloseCardMenu}>Created cards by user</span> </UserMenu>

в разные компоненты это разделить

Да видно. Наверху юзать два одинаковых кастомный хука уже плдозрительно

const { Menu: UserMenu, onClose: onCloseUserMenu } = useMenu() const { Menu: CardMenu, onClose: onCloseCardMenu } = useMenu() <UserMenu> <span onClick={onCloseCardMenu}>Created cards by user</span> </UserMenu>

Просто суть хука что это отдельная переиспользуимая логика *одного* компонента

const state1 = React.useState(1) const state2 = React.useState(2) и такое допустимо

Я про кастомный хук

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

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

const { Menu: UserMenu, onClose: onCloseUserMenu } = useMenu() const { Menu: CardMenu, onClose: onCloseCardMenu } = useMenu() <UserMenu> <span onClick={onCloseCardMenu}>Created cards by user</span> </UserMenu>

Зачем в хуке useMenu возвращается комплект, если этот компонент генерируется динамически в хуке то он ломает реконсиляцию

я обычно размышляю так, если возможно написать код так, чтобы он порождал меньше ошибок при использовании, лучше так и написать. В данном кейсе, если меню требует дополнительных переменных это не очень правильно. Как минимум нарушается инкапсуляция. Меню уже не контролирует самостотельно свое внутреннее состояние открыто/закрыто. То есть меню может быть закрыто в любой неизвестный момент, то есть даже мимо логики. И по факту, этот хендлер должен называть onItemClick, так как может не закрывать меню, а открывать вложенное, например. Поэтому сам по себе контроль таких состояний должен быть изнутри меню. Поэтому возможно, контекст это лучший выбор в данном случае

Смотри но на компоненты мы ж и вью бьём. Просто заметь. Там где в компоненте вью используется два одинаковых кастомный хука - это кандидат на разделение.

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

а пруфы какие-нибудь есть про ломание реконсиляции??

а пруфы какие-нибудь есть про ломание реконсиляции??

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

А вообще это очень легко проверить, реконсиляция идёт по ссылкам, если ссылка меняется то все ломается

А чего удалили мое мнение о vue?

потому что это чат по реакту. По vue есть отдельный чат. Не надо здесь оффтопить. Вон уже три сообщения появились вообще мимо темы чата

А какое правило я нарушил то? Где оффтоп в ключе со сравнением с реактом

Админ может вообще запретить тут обсуждать js

То как он внутри устроен это совершенно другая область проектирования. И компонент Меню должен самостоятельно отвечать за собстенное устройство. Пользователи компонента ни в коем случае не должны знать как открывать вложенные менюшки, как закрывать меню. Как минимум потому, что тогда рефакторинг менюшки просто невозможен, ибо может быть множество пользователей, которые использовали его неизвестным для тебя способом. Один из вариантов решения это определить конечное количество возможностей использования компонента. И в данном случае внутренний контроль за всем что связано с меню выглядит как принцип единственной ответственности. То есть меню самостоятельно реализует и управляет своими элементами, способом их отображение, состоянием открытия/закрытия и субменю

А какое правило я нарушил то? Где оффтоп в ключе со сравнением с реактом

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

Слишком гибко это тоже крайне плохо

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

То есть сухие диалоги типа «ребят, почему это не работает» круче. Ок.

мемоизация решает

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

вот сейчас тред интересный, про рендер-пропы и прочее. Всё в контексте реакта. Обсуждать штуки которые мимо реакта вообще не имеет смысла никакого

Обсуждать реакт вне контекста рынка и его конкурентов это смерть продукту

Слишком гибко это тоже крайне плохо

То есть сухие диалоги типа «ребят, почему это не работает» круче. Ок.

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

Тот пример, что я расписал мне не нравится. Поэтому я предпочитаю <Menu импортировать, а не создавать в рантайме

у меня вообще замечательный кейс: около 25 разработчиков на проекте и каждый с разным уровнем знаний реакта и программирования вообще. плюс половина из них за океаном и надо сделать компоненты такими, чтоб все могли нормально пользоваться :) и чтоб задачи решали

согласен. сейчас сижу балансирую

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

у меня вообще замечательный кейс: около 25 разработчиков на проекте и каждый с разным уровнем знаний реакта и программирования вообще. плюс половина из них за океаном и надо сделать компоненты такими, чтоб все могли нормально пользоваться :) и чтоб задачи решали

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

@sovasergey глянул тред про рендер пропс. У вас есть открытый репо какого либо проекта для изучения исходного кода?

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

github.com/howtocards

специалисты, чет пропсы сюда не садятся. в функцию withStateAllProducts

А почему фигурные скобки при деструктуризации? Вроде же квадратные везде

А почему фигурные скобки при деструктуризации? Вроде же квадратные везде

А почему фигурные скобки при деструктуризации? Вроде же квадратные везде

есть деструктуризация массивов а есть объектов const [a, b] = [1, 2] const { a, b } = { a: 1, b: 2 }

А дебажить не пробывал ?

Привет народ, у кого-то есть опыт работы с монако ?

посмотри что в this лежит

nometa.xyz

а тв собсно говоря и не передаешь Wrapped

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

— Кто-нибудь щупал монако? Какие впечатления?

да да там проблема в передаче. compose вроде должен передавать

да да там проблема в передаче. compose вроде должен передавать