Скорей всего зависит от проекта и подхода. Но в большинстве случаев думается что rtl тестирует лишнее.
Пример: есть много видов карточек с полями формы. Что rtl тестировать ? Заполнение формы и правильный post? Но тогда мы большинство функций и компонентов будем тестировать много много раз . А оно нам надо?
Еще ензим ругает автор за скорость. Вот rtl точно тормоз . Чуть сложный кейс тестирования и даже jest падает с таймаутом. Приходиться ручками ставить в каждом тесте таймауты ожидания. А поиск... это вообще нечто что бы найти инпут он столько время тратит. А если их много?
Еще минус rtl .... это поддержка тестов. Поменялось в зависимостях .. хуках. И все приплыли, что бы найти что поправить в тестах уходит уева куча времени (когда не по тдд а просто сделал задачу закрепил в тестах). Это самое важное в тестах.
Чел вообще не адекватный. Хотел купить удаленно. Просит отправить деньги и только потом товар отправит. Никаких доказательств что это не наяб...ло нет. Прошу предоставить хотя бы что то. что меня обезопасило от мошеничества сразу перестает выходить на связь. Телегу трет. Будьте бдительны товарищи. Возможно при встрече можно у него купить . Но с таким подходом надо проверять все досконально. о поддержке которую продавец обещает думаю можно и не говорит. не сильно то верится.
Все, спасибо понял )). Можно еще вопрос. Если повсеместно использовать в проекте не будет ли от этого страдать отладка и поддержка? Появляется же как бы магия. И очень тяжело потом найти источник? Был опыт использования на больших проектах и долгих.. ? Просто даже в столь не запутаном редаксе на первый взгляд большой проект (очень большой) начинает тонуть в этом плане. А тут вообще будет одна магия.
в первом случае же у нас тоже обертка ? или у вас useMyHook(); это не кастомный хук? а хук в виде прямого использования как useContext(DIContext)
А я кажется возможно не туда смотрю. Вы реализовали ДИ по средством самого контекста? то есть контекст === ДИ. А у вас реализация не внедрение самой зависимости а его инструмента.
ди предполагает что вы сможете использовать .. то есть внедрять зависимость без изменения кода. Как в вашем примере это будет выглядеть? вам надо будет идти в useInjection и изменять код. Что ДИ такого не подразумевает https://habr.com/ru/company/devexpress/blog/440552/ сходите почитайте как должно выглядеть то о чем вы пишете.
Думаю если бы вы просто пропсом прокинули то это было бы более лучший варик.
> Вам покажу и распишу подробно где, вы готовы вчитаться, вникнуть и увидеть? Попробуйте расписать.
где у вас все это ? как была связанность так и осталась. То что знаете модные слова это хорошо. Но пример не удался. У вас пример с контекстом .. для тестов не надо ничего кроме как обернуть как у вас показано. Для связи с бэком вы все равно так же будете делать прибивать гвоздями хук и оборачивать его просто другим. Это будет по всему коду и наивно полагать что вы не привязываетесь к логике. Если что то изменится вы будете ходить и по всему коду менять свои обертки. Для тестов существуют моки как вы и сказали если надо затестить то надо мокать запрос... К сожалению комьюнити фронтенда пытается всегда прыгать выше головы. Зачем вы сюда засунули тс? что бы показать какой вы молодчик и вы в тренде? вы же про другое пытались сказать... Ваш рассказ должен быть лаконичным без мусора.
Посмотрите что такое депенденси в спринге это зло которое уже будет вами управлять. Это как за место редакса везде юзается контектс причем 16 реакта. Вот это настоящее депенденси ... И найди кто кинул или создал свойство или функцию. Только поиск по проекту. и дай бог что бы у вас нейминг был хороший что бы не найти 20 одних и тех же функций
Читайте книги... Преждевременная оптимизация самый большой грех .
Здесь все зависит от того что дорого…
если дорого запросы то локально хранить.
Если хотим сэкономить место у пользователя то запросы.
А еще вы не рассмотрели SPA
Все-же полезно для краткого ознакомления такие статьи. Мне вот интересно. Интересно также и сами мысли после прочтения по поводу книги и около её.
Автора конечно с днюхой.
Скорей всего зависит от проекта и подхода. Но в большинстве случаев думается что rtl тестирует лишнее.
Пример: есть много видов карточек с полями формы. Что rtl тестировать ? Заполнение формы и правильный post? Но тогда мы большинство функций и компонентов будем тестировать много много раз . А оно нам надо?
Еще ензим ругает автор за скорость. Вот rtl точно тормоз . Чуть сложный кейс тестирования и даже jest падает с таймаутом. Приходиться ручками ставить в каждом тесте таймауты ожидания. А поиск... это вообще нечто что бы найти инпут он столько время тратит. А если их много?
Еще минус rtl .... это поддержка тестов. Поменялось в зависимостях .. хуках. И все приплыли, что бы найти что поправить в тестах уходит уева куча времени (когда не по тдд а просто сделал задачу закрепил в тестах). Это самое важное в тестах.
Чел вообще не адекватный. Хотел купить удаленно. Просит отправить деньги и только потом товар отправит. Никаких доказательств что это не наяб...ло нет. Прошу предоставить хотя бы что то. что меня обезопасило от мошеничества сразу перестает выходить на связь. Телегу трет. Будьте бдительны товарищи.
Возможно при встрече можно у него купить . Но с таким подходом надо проверять все досконально. о поддержке которую продавец обещает думаю можно и не говорит. не сильно то верится.
Все, спасибо понял )).
Можно еще вопрос. Если повсеместно использовать в проекте не будет ли от этого страдать отладка и поддержка? Появляется же как бы магия. И очень тяжело потом найти источник?
Был опыт использования на больших проектах и долгих.. ? Просто даже в столь не запутаном редаксе на первый взгляд большой проект (очень большой) начинает тонуть в этом плане. А тут вообще будет одна магия.
Было
стало
в первом случае же у нас тоже обертка ?
или у вас
useMyHook(); это не кастомный хук? а хук в виде прямого использования как
useContext(DIContext)А я кажется возможно не туда смотрю. Вы реализовали ДИ по средством самого контекста? то есть контекст === ДИ. А у вас реализация не внедрение самой зависимости а его инструмента.
ди предполагает что вы сможете использовать .. то есть внедрять зависимость без изменения кода. Как в вашем примере это будет выглядеть? вам надо будет идти в useInjection и изменять код. Что ДИ такого не подразумевает
https://habr.com/ru/company/devexpress/blog/440552/
сходите почитайте как должно выглядеть то о чем вы пишете.
Думаю если бы вы просто пропсом прокинули то это было бы более лучший варик.
> Вам покажу и распишу подробно где, вы готовы вчитаться, вникнуть и увидеть?
Попробуйте расписать.
попробуйте написать тоже самое только без понятия ди .. я уверен у вас будет тоже самое .. возможно даже чище
где у вас все это ? как была связанность так и осталась. То что знаете модные слова это хорошо. Но пример не удался. У вас пример с контекстом .. для тестов не надо ничего кроме как обернуть как у вас показано. Для связи с бэком вы все равно так же будете делать прибивать гвоздями хук и оборачивать его просто другим. Это будет по всему коду и наивно полагать что вы не привязываетесь к логике. Если что то изменится вы будете ходить и по всему коду менять свои обертки.
Для тестов существуют моки как вы и сказали если надо затестить то надо мокать запрос...
К сожалению комьюнити фронтенда пытается всегда прыгать выше головы. Зачем вы сюда засунули тс? что бы показать какой вы молодчик и вы в тренде? вы же про другое пытались сказать... Ваш рассказ должен быть лаконичным без мусора.
Посмотрите что такое депенденси в спринге это зло которое уже будет вами управлять. Это как за место редакса везде юзается контектс причем 16 реакта. Вот это настоящее депенденси ... И найди кто кинул или создал свойство или функцию. Только поиск по проекту. и дай бог что бы у вас нейминг был хороший что бы не найти 20 одних и тех же функций
Читайте книги... Преждевременная оптимизация самый большой грех .
А чем отличается исходный код от полученного?
В первом случае мы имеем MyComponent имеет прямую зависимость в виде хука useMyHook.
Во втором тоже самое только прямая зависимость от useInjection().
А как в тестах депендонси помог? Точно также будет работать без вашего депендонси.
Ну будет как у вас с редусерами… Просто множество actions.
Так что тут +-
Про константы поправил. Спасибо. Была опечатка.
github.com/tc39/proposal-flatMap
если дорого запросы то локально хранить.
Если хотим сэкономить место у пользователя то запросы.
А еще вы не рассмотрели SPA
Все-же полезно для краткого ознакомления такие статьи. Мне вот интересно. Интересно также и сами мысли после прочтения по поводу книги и около её.
Автора конечно с днюхой.