Ты же функцию в button прокидываешь, вот если бы прокидывал так в компонент, в котором внутри еще 10 компонентов, тогда была бы гора лишних ререндеров, а щас обернуть в useCallback будет даже хуже

Ты же функцию в button прокидываешь, вот если бы прокидывал так в компонент, в котором внутри еще 10 компонентов, тогда была бы гора лишних ререндеров, а щас обернуть в useCallback будет даже хуже

Попробую ещё раз Если есть форма и данные из неё передаются через Link c onClick вместо input[submit] с onSubmit на форме, это грубый косяк или нет? И вообще косяк ли это?

Но вообще useCallback с id в зависимостях тут будет элегантно выглядеть)

Попробую ещё раз Если есть форма и данные из неё передаются через Link c onClick вместо input[submit] с onSubmit на форме, это грубый косяк или нет? И вообще косяк ли это?

а как это с id в зависимостях? я кроме такого представить ничего не могу

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

Ну если не исключительный случай, лучше кнопка с type submit и обработчик на форме, так как это позволяет использовать некоторые встроенные возможности браузера вроде отправки формы на enter

Это косяк, так как ломается семантика. Люди с плохим зрением твоим сайтом воспользоваться не смогут.

Спасибо! К слову о нажатии Enter, которое управляет формой. Если нажатие на кнопку контролируется событием onSubmit, работает ли в это случае на форме onKeyup? И если нет, как мне onSubmit ещё и к Enter подвязать?

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

В общем, в любом случае корректнее с обработчиком на форме и кнопкой/инпутом submit, со всех точек зрения, там и браузерные возможности, и семантика, и a11y, в общем шик Единственное, бывают реально корявые либы которые такое делать не позволяют, например rsuite

В общем, в любом случае корректнее с обработчиком на форме и кнопкой/инпутом submit, со всех точек зрения, там и браузерные возможности, и семантика, и a11y, в общем шик Единственное, бывают реально корявые либы которые такое делать не позволяют, например rsuite

К слову, есть какой-нибудь топ паттерн для структуры приложений? Например, должна быть тонна компонентов и минимум чистой вёрстки в них в случае map или switch, или же наоборот?

Нет такого.

Понял. Сам как считаешь касательно вопроса о количестве компонентов в предыдущем сообщении?

К слову, есть какой-нибудь топ паттерн для структуры приложений? Например, должна быть тонна компонентов и минимум чистой вёрстки в них в случае map или switch, или же наоборот?

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

У меня сейчас вопрос стоит таким ребром: Есть 4 route с путями: /test, /test/:type, /test/:type/:id, /test/:type/results. Я сначала каждый из них сделал компонентами, но необходимость постоянного поднятия состояния в основной компонент test обязывает писать больше кода. И тут внутри меня холивар)

Используй стор менеджер.

Я чуть позже буду редакс подвязывать

Тогда будешь писать больше кода.

Здесь стейт менеджер проблему с пропсами решает, надо страницу/компонент каждого роута к нему подключить просто

Что за стейт менеджеры?)

Тут не спорю. А ты какие имел ввиду стор менеджеры?

Редаксы и так далее, + их биндинг для реакта

Любые которые тебе нравятся: Redux, mobX, effector, reatom.

Говорили тут обсуждалось, что редакс умирает. Так ли это и почему?

Говорили тут обсуждалось, что редакс умирает. Так ли это и почему?

Говорили тут обсуждалось, что редакс умирает. Так ли это и почему?

Большинство компаний используют его потому что надежно

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

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

Что сам используешь и что можешь посоветовать на замену редаксу?

Т.е. буду я использовать его или нет, если идти работать в нормальное место с React, Redux нужно знать по умолчанию?

Если для целей поиска работы что-то конкретное изучать, это сначала естественно редакс или мобх, если для себя и для понимания других вариантов, это всякие эффекторы, реатомы и тд)

А если ты любитель юзать классовые компоненты, тогда даже лучше избегать большое количество компонентов :)

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

Касаясь этого, конечно куча компонентов пугает, но и код, в котором куча map, filter, switch, if-else в одном компоненте с длиной строк кода 100+, тоже выглядит грубо

Классовый компонент такие проблемы не решает)

Касаясь этого, конечно куча компонентов пугает, но и код, в котором куча map, filter, switch, if-else в одном компоненте с длиной строк кода 100+, тоже выглядит грубо

Ребят, подскажите, тут всё ок с этим кодом?

Так я их использую просто за то, как они выглядят) Не именно потому что я с их помощью пытаюсь что-то исправлять в качестве кода

Если ты конкретно про количество компонентов, то конечно надо выносить все до определенной степени в компоненты, но не так чтобы из блока текста делать 3 компонента друг в друге по очереди

По-моему const Message = ({ ... }) = { return ... } куда лучше выглядит как классовый аналог, но вот function Message({ ... }) {} как в доке у реакте - я не очень понимаю Для меня конструкция function как-то не подходит логически для такой сущности как реактовский компонент

По-моему const Message = ({ ... }) = { return ... } куда лучше выглядит как классовый аналог, но вот function Message({ ... }) {} как в доке у реакте - я не очень понимаю Для меня конструкция function как-то не подходит логически для такой сущности как реактовский компонент

Не совсем так. Больше про такой случай: <Switch> <Route exact path="/test"> <h1>Test</h1> </Route> <Route path="/test/:type"> <h1>Test type</h1> </Route> </Switch> или <Switch> <Route exact path="/test"> <Test /> </Route> <Route path="/test/:type"> <TestType /> </Route> </Switch>

Функция билдер. Не пойму что воспринимать сложно?

Помнится, видел какое-то видео, где автор разбирая react на примере твиттера говорил, что компонент там буквально всё. И кнопка лайков, и кнопка твита, и текстовое поле и блок, который их объединяет. По сути правильно, понятно, но когда в components 10-100 файлов, реально можно потеряться

<Route exact path="/test" component={Test} />

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

Помнится, видел какое-то видео, где автор разбирая react на примере твиттера говорил, что компонент там буквально всё. И кнопка лайков, и кнопка твита, и текстовое поле и блок, который их объединяет. По сути правильно, понятно, но когда в components 10-100 файлов, реально можно потеряться

В Фейсбуке 50к компонентов

Т.е. components/test/components, components/book/components? Или как?

features/ SignIn/ reducers/ components/ Something.js Form/ index.js Form.js FormView.js index.js SignIn.js SignInView.js

Как-то жутко...

Что жутко?

Что жутко?

Я ещё понимаю: components/ test/ templates/ test.js testType.js testTypeID.js testResults.js reducers/ test.js actions/ test.js styles/ test.scss Но так....

Те же яйца

1) Редьюсеры, экшны, типы и тд разделять по разным папкам - невозможно поддерживать, вот нормальное решение reducers/ test/ index.js reducer.js actions.js types.js selectors.js 2) 100 компонентов в одной папке, серьезно?

features/ SignIn/ reducers/ components/ Something.js Form/ index.js Form.js FormView.js index.js SignIn.js SignInView.js