Микрофронтенды — универсальное решение всех проблем или просто удобный подход?

| И почему перестанут конфликтовать на общем функционале, он же останется?

Не перестанут, доработки в библиотеку компонентов или аналогичные модули (которые используют вообще все) всегда придется согласовывать и вносить с оглядкой на обратную совместимость.

Будет меньше заморочек.

Вот есть команда А и Б, есть у этих команд свои модули, есть общий ui-kit, вынесенный в отдельный npm пакет.

Команде А нужно что - то поменять в одном из компонентов kit-a, вносят они эту правку, и оказывается, что в модуле команды Б что - то сломалось. Команда Б об этом узнает только если обновит версию kit-a, может это вообще не понадобится никогда, если модуль команды Б это легаси, которое лениво ковыряют. Но даже если нет - они просто откатят версию кита, отправят команде А багрепорт, и будут дальше работать над своим функционалом.

В монолите, после деплоя доработки командой А, на какое - то время всё встанет у обоих команд.

Преимущества становится еще более очевидными, если допустить, что команд не 2, а 10 :)

Велосипедим Promise на TypeScript

Добрый день!

> promise создаёт микротаски, а не макро

Все верно. Об этом было упомянуто в самом конце, возможно стоит подсветить это более явно.

Не совсем понял формулировку "нарушает постановку задач". Скорее всего вы говорите про примеры совместного использования промисов и webAPI, в которых действительно можно увидеть разницу между велосипедом, и тем, как оно работает нативно:

// macrotask queue
setTimeout(() => { console.log(1); }, 0);
PromiseImplementation.resolve().then((x) => { console.log(2); });
console.log(3);
// Output: 3, 1, 2

// microtask queue
setTimeout(() => { console.log(1); }, 0);
Promise.resolve().then(() => { console.log(2); });
console.log(3);
// Output: 3, 2, 1

Мне в голову не пришел адекватный сценарий, при котором такие отличия в работе могут повлиять на заложенную в коде логику. Ввиду этого, использование setTimeout вместо queueMicrotask, показалось допустимым упрощением. Всё таки основной фокус немного на другом.

Разумеется, при разработке промышленного полифила, было бы необходимо учесть и такой кейс. Но тогда бы пришлось использовать setimmediate для IE / Node.js или что - то ещё для конкретной среды. Промисы и queueMicrotask, друг без друга, в природе не встречаются.

Велосипедим Promise на TypeScript

Теперь понял, про что речь. Благодарю за разъяснения, чуть позже улучшу код в репозитории и статье.

Велосипедим Promise на TypeScript

Здравствуйте!

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

2) В целях сделать текст чуть проще, setTimeout это основа основ, которая интуитивно понятна любому разработчику, в то время как сравнительно недавно появившийся queueMicrotask, на практике, используется совсем редко.

Малоизвестное изобретение Николы Теслы, заинтересовавшее ученых

> заинтересовавшее внимание
Вы этим очень больно делаете

В интерфейсе телефонов Sony — неотключаемая реклама

Там же есть кнопка force stop, так что возможность остановить приложение все таки есть

Опрос по инструментам фронтенда 2019 — результаты

Кто эти люди, которые никогда не слышали про Babel, JQuery, React, npm? x_X