Ну раз пошла жара про хуки/классы. Какие есть изящные решения по

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

Stub / mock кастомного хука? DI через Props? другие способы?

А зачем тестировать компонент в изоляции от его же логики?)

Поддерживаю вопрос. Тоже не понял

тестировать все вместе. в реакте нет (практически) чистого юнит-тестирования

Просто "юнит" - понятие растяжимое)

растяжимый юнит :) толстеет до интеграционного размера

ну не хочу я "интеграционные" тесты, например. Хочу видеть разные состояния просто передачей свойств. Не нужно чтобы оно какими-то эффектами в api стучало, и т.п.

https://kentcdodds.com/blog/write-tests/

так апи и мокай

Так это и не интеграционные Компонент - это один "юнит", его можно так и тестировать Мне так кажется А если вы используете react testing library - там вообще не юнит тесты же

так это уже интеграционный тест и есть, если api мокать. в этом случае мне проще сам хук без UI тестировать

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

ну так что плохого

Это никак не гарантирует, что он работает хорошо в компонентах же

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

с каких пор? компонент - это верстка, не более. Захочу - могу то же самое хоть в консоли делать, но функциональность должна быть +/- та же (я не про кнопконажимание сейчас)

Не согласен, что компонент - это "просто верстка"

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

И всё-равно логичнее будет делать уже интеграционный тест из этих двух компонентов потому, что по отдельности они не имеют смысла😁

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

ну например, я могу переписать ту же форму в виде ввода-вывода в терминал, на каком-нибудь ink , но формой она от этого быть не перестанет, со своей же логикой и api.

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

вот вопрос как раз в том - как при таких условиях должен быть организован компонент на хуках? чтобы не дублировать логику (переиспользовать её) и тестировать все необходимые состояния? т.е. очевидно будет что-то про api (отдельный хук), что-то про внешний вид самого компонента (в props или state)

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

> Это деталь его внутренней реализации вот у меня этот пункт до сих пор вызывает сомнения. логика сайд-эффекта, который ходит в api - деталь реализации кнопки submit?

Кнопка же не ходит в апи)

Деталь - это то, как именно происходит сабмит, грубо говоря

часто обсуждаемый пример: компонент - форма (немного упрощу - состоит из одной кнопки и поля ввода). Но: - при 401 ошибке - пользователя нужно перенаправить на login - при 200 - перебросить на следующую страницу и так для 2 из 3 форм на сайте (третья доступна неавторизованному пользователю, форма - "кнопка" - теперь уже знает что есть какая-то авторизация?)

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