Импорт зависимостей напрямую имеет один плюс и рассчитан на то что это будет делаться с гитхаба или чего-то подобного. Плюс заключается в том что исходники и репозиторий в одном месте. Сейчас в npm можно опубликовать один код (например с эксплойтом), а на гитхаб другой. Большинство разработчиков будет читать гитхаб исходники и не найдут там ничего проблемного и поставят себе зависимость.
Насчет минусов, тут все подругому: в Deno «под копотом» исполняется тот же JavaScript как и в Node.js, просто он компилируется из TypeScript посредствам tsc перед запуском в V8. Скомпилированная версия кэшируется, чтобы сократить издержки загрузки и компиляции скриптов из Интернета. Посмотрите папку ~/.deno после запуска скрипта, если не верите
Вы путаете принципы IoC с чем-то другим… с DI контейнерами?
В Реакте часто применяются приницпы инверсии контроля, когда например передаете в компонент функцию для обратного вызова в качестве пропса.
Да, это на основе User-Agent можно делать. Еще можно сделать небольшой серверный скрипт, который смотрит пришедший запрос и ищет по User-Agent и browserlist наиболее подходящий бандл, который уже и отдает. Примерно так работает polyfill.io
Советую вам изучить другие направления, вне React экосистемы — вы слишком узко смотрите на современность во фронтенде. Есть ворох интересных решений на веб-компонентах к примеру. Запомните, что фреймворки появляются и исчезают, а платформа останется с нами на очень долгое время.
По поводу описания типов в докстрингах, если есть время упариваться, то лучше всё-таки вместо это выбрать Flow или TypeScript — так актуальность типов будет лучше поддерживаться, да и получите хорошие инструменты статического анализа :)
В ожидании включения предложения «optional chaining» в EcmaScript комитетом TC39, можно пользоваться очень удобной библиотекой, которая оборачивает опасный доступ ко вложенному значению с помощью магии в виде try/catch + regex.
Потому что при большом количестве фич с течением времени, начинается ад из-за отсутствия архитектуры
Я согласен что это излишне для мелких приложений, но подумайте о веб-приложения уровня Enterprise, и я считаю вы поймете к чему такие сложности на фронтенде.
Лучше подход, когда берёшь чистый компонент (без этих сайд эффектов в виде того же реакт-роутера) и его тестируешь отдельно от всех. Чтобы его достать из груды применённых к нему HOCs есть именованные экспорты.
Стоило бы упомянуть в статье что это костыль, появившийся из-за отсутствия в js возращения значений из таких конструкций как if/else. Есть proposal с введением do-выражений, но это ИМХО ещё один костыль
Подправьте статью, данное предложение больше не является кандидатом (стадия 3)
В Реакте часто применяются приницпы инверсии контроля, когда например передаете в компонент функцию для обратного вызова в качестве пропса.
Советую вам изучить другие направления, вне React экосистемы — вы слишком узко смотрите на современность во фронтенде. Есть ворох интересных решений на веб-компонентах к примеру. Запомните, что фреймворки появляются и исчезают, а платформа останется с нами на очень долгое время.
github.com/facebookincubator/idx
к сожалению авторство данного сниппета потерял
Я согласен что это излишне для мелких приложений, но подумайте о веб-приложения уровня Enterprise, и я считаю вы поймете к чему такие сложности на фронтенде.
PS: отличный перевод статьи! особенно в дополнению к medium.freecodecamp.org/scaling-your-redux-app-with-ducks-6115955638be приходит виденье как хорошо спроектировать архитектуру фронтенда на годы