Как я перестал бояться тестов и полюбил зелёный CI

добавил спс, забыв). Да это одна из обязательных к прочтению про тестирование. Автор замечательно разбирается в теме.

Как я перестал бояться тестов и полюбил зелёный CI

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

Как я перестал бояться тестов и полюбил зелёный CI

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

Юнит-тесты — трата времени или суперсила разработчика?

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

Юнит-тесты — трата времени или суперсила разработчика?

ты хочешь в таком коде ковырятся ? или все же Предпочитаешь работать в хороших условиях?

Юнит-тесты — трата времени или суперсила разработчика?

в смысле? а кто дает время на хороших код? написание юнит тестов для кода это огромный фильтр для качества кода. Гавнокод нельзя покрыть юнит тестами только интеграциоными или вообще эндтуэнд. От сюда на выходе имеем код который будет читаемым чистым поддерживаемый . Мы в своей массе новый код пишем очень мало даже в бурно развивающемся проекте. В основном юзаем и преюзываем код который уже написан. А если он будет по феншую то это же хорошо и ускорит в разы разработку даже нового функционала

Тесты: 100% покрытия и юниты не нужны

Скорей всего зависит от проекта и подхода. Но в большинстве случаев думается что rtl тестирует лишнее.

Пример: есть много видов карточек с полями формы. Что rtl тестировать ? Заполнение формы и правильный post? Но тогда мы большинство функций и компонентов будем тестировать много много раз . А оно нам надо?

Еще ензим ругает автор за скорость. Вот rtl точно тормоз . Чуть сложный кейс тестирования и даже jest падает с таймаутом. Приходиться ручками ставить в каждом тесте таймауты ожидания. А поиск... это вообще нечто что бы найти инпут он столько время тратит. А если их много?

Еще минус rtl .... это поддержка тестов. Поменялось в зависимостях .. хуках. И все приплыли, что бы найти что поправить в тестах уходит уева куча времени (когда не по тдд а просто сделал задачу закрепил в тестах). Это самое важное в тестах.

Клавиатура с трекболом. Как с ней работать

Чел вообще не адекватный. Хотел купить удаленно. Просит отправить деньги и только потом товар отправит. Никаких доказательств что это не наяб...ло нет. Прошу предоставить хотя бы что то. что меня обезопасило от мошеничества сразу перестает выходить на связь. Телегу трет. Будьте бдительны товарищи.
Возможно при встрече можно у него купить . Но с таким подходом надо проверять все досконально. о поддержке которую продавец обещает думаю можно и не говорит. не сильно то верится.

Dependency Injection в React — максимально просто

Все, спасибо понял )).
Можно еще вопрос. Если повсеместно использовать в проекте не будет ли от этого страдать отладка и поддержка? Появляется же как бы магия. И очень тяжело потом найти источник?
Был опыт использования на больших проектах и долгих.. ? Просто даже в столь не запутаном редаксе на первый взгляд большой проект (очень большой) начинает тонуть в этом плане. А тут вообще будет одна магия.

Dependency Injection в React — максимально просто

Было

import { useMyHook } from ...;

const MyComponent () => {
  ...
  var someResult = useMyHook();
  ...
}

стало

const Container = {
  foo,
  bar,
};

const DIContext = React.createContext(Container);
const useInjection = () => {
  return useContext(DIContext);
};

const MyComponent= () => {
  ...
  const { foo, bar } = useInjection();
  ...
}

в первом случае же у нас тоже обертка ?
или у вас useMyHook(); это не кастомный хук? а хук в виде прямого использования как useContext(DIContext)

А я кажется возможно не туда смотрю. Вы реализовали ДИ по средством самого контекста? то есть контекст === ДИ. А у вас реализация не внедрение самой зависимости а его инструмента.

Dependency Injection в React — максимально просто

ди предполагает что вы сможете использовать .. то есть внедрять зависимость без изменения кода. Как в вашем примере это будет выглядеть? вам надо будет идти в useInjection и изменять код. Что ДИ такого не подразумевает
https://habr.com/ru/company/devexpress/blog/440552/
сходите почитайте как должно выглядеть то о чем вы пишете.

Думаю если бы вы просто пропсом прокинули то это было бы более лучший варик.

> Вам покажу и распишу подробно где, вы готовы вчитаться, вникнуть и увидеть?
Попробуйте расписать.

Dependency Injection в React — максимально просто

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

Dependency Injection в React — максимально просто

где у вас все это ? как была связанность так и осталась. То что знаете модные слова это хорошо. Но пример не удался. У вас пример с контекстом .. для тестов не надо ничего кроме как обернуть как у вас показано. Для связи с бэком вы все равно так же будете делать прибивать гвоздями хук и оборачивать его просто другим. Это будет по всему коду и наивно полагать что вы не привязываетесь к логике. Если что то изменится вы будете ходить и по всему коду менять свои обертки.
Для тестов существуют моки как вы и сказали если надо затестить то надо мокать запрос...
К сожалению комьюнити фронтенда пытается всегда прыгать выше головы. Зачем вы сюда засунули тс? что бы показать какой вы молодчик и вы в тренде? вы же про другое пытались сказать... Ваш рассказ должен быть лаконичным без мусора.

Посмотрите что такое депенденси в спринге это зло которое уже будет вами управлять. Это как за место редакса везде юзается контектс причем 16 реакта. Вот это настоящее депенденси ... И найди кто кинул или создал свойство или функцию. Только поиск по проекту. и дай бог что бы у вас нейминг был хороший что бы не найти 20 одних и тех же функций

Читайте книги... Преждевременная оптимизация самый большой грех .

Dependency Injection в React — максимально просто

А чем отличается исходный код от полученного?

В первом случае мы имеем MyComponent имеет прямую зависимость в виде хука useMyHook.

Во втором тоже самое только прямая зависимость от useInjection().

А как в тестах депендонси помог? Точно также будет работать без вашего депендонси.

Повышаем производительность разработки на примере Vue — часть 2

спасибо за комментарий

Redux — пересмотр логики reducer'a и actions

Пример с Object.assign взят из оф доки по redux

Redux — пересмотр логики reducer'a и actions

будете иметь уйму обработчиков в файле `actions`, в последствие, по мере разрастания проекта, по-прежнему придется пользоваться тем же поиском.

Ну будет как у вас с редусерами… Просто множество actions.
Так что тут +-
Про константы поправил. Спасибо. Была опечатка.

ECMAScript Proposal: Array.prototype.{flat,flatMap}

`Array.prototype.{flat,flatMap}` to stage 4, per 2019.01.29 TC39

ECMAScript Proposal: Array.prototype.{flat,flatMap}

да он перешел в stage 4 и в самом низу вашей ссылки
github.com/tc39/proposal-flatMap

Повышаем производительность разработки на примере Vue — часть 1

Это всего лишь первый шаг. Потерпите немного и увидите все.