Тесты: 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

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

Создаем плагин Vuex Undo/Redo для VueJS

Спасибо отличная статья дала о многом задуматься.

Пагинация во Vue.js

спасибо поправил

Пагинация во Vue.js

Здесь все зависит от того что дорого…
если дорого запросы то локально хранить.
Если хотим сэкономить место у пользователя то запросы.
А еще вы не рассмотрели SPA

Пагинация во Vue.js

спасибо уже поправил

ArrayBuffer и SharedArrayBuffer в JavaScript, часть 1: краткий курс по управлению памятью

так как же управлять памятью с помощью ArrayBuffer и SharedArrayBuffer?

Идеальный программист. Часть 1

Все-же полезно для краткого ознакомления такие статьи. Мне вот интересно. Интересно также и сами мысли после прочтения по поводу книги и около её.
Автора конечно с днюхой.