Происходит это так же, в отдельной микротаске, в которой происходит ряд проверок, в том числе, определяется и приоритет следующей задачи.
Не совсем понятно, а как определяется приоритет следующей задачи?
Планировщик занимается обработкой поставленных в очередь задач (Fiber-ов) и всегда работает в микротаске или после завершение обработки текущего события. Конкретный рендер имеет возможность определить свою специфику работы планировщика посредством переопределения scheduleMicrotask в API пакета react-reconciler. Например React Native может использовать для этих целей queueMicrotask, если поддерживается платформой, а React DOM - промисы.
Вот это тоже любопытно, как конкретный рендер определяют свою специфику планировщика, от чего это зависит? где можно читать об этом?
А так - спасибо большое за статью, невероятно круто!
Было бы здорово, если бы вы нарисовали простой скетч механизма (например, в excalidraw), а то иногда может быть сложно слету понять ход мыслей, когда нет какой-то схемы
>отсутствие формализованной методологии
Когда входят новые разработчики, вы даете документацию к методологии? или вы описали это в рамках своей документации?
Если даете просто линк на сайт, то люди будут сталкиваться с тем, что все по разному понимают сущности в FSD и страдают
И вопрос про масштабируемость, а как вы ощущаете/понимаете, что ваша прошлая архитектура не могла масштабироваться? с какими проблемами столкнулись?
Не совсем понятно, а как определяется приоритет следующей задачи?
Вот это тоже любопытно, как конкретный рендер определяют свою специфику планировщика, от чего это зависит? где можно читать об этом?
А так - спасибо большое за статью, невероятно круто!
Было бы здорово, если бы вы нарисовали простой скетч механизма (например, в excalidraw), а то иногда может быть сложно слету понять ход мыслей, когда нет какой-то схемы
Круто! И как экспорт отработал для Apple notes? все корректно? были проблемы какие-то?