Comments 19
upd: кому интересно и текстом — medium.com/@baphemot/understanding-react-suspense-1c73b4b0b1e6
Это аналог $mol_fiber, но в 10 раз большим кодом, ибо реакт :-)
Suspense это не Fiber
Для того чтобы включить Fiber в реакте не надо переписывать приложение. И вообще разработчику не надо задумываться о том как там под капотом обновления происходят. Вы же предлагаете просто отдельное апи для этого: то есть про это апи надо думать на этапе разработки приложения.
Согласитесь немного разные подходы.
Suspense — это именно Fiber, а вот то, что в Реакте называется Fiber — это не Fiber, а progressive rendering.
$mol_fiber по своему предназначению — тоже самое что и React Fiber (pausable synchronous execution, в реакте эти паузы как раз для того чтобы изменения в браузер доставить). Suspense вообще не про то. Вы либо путаете что-то, либо сознательно заблуждаетесь.
Ну вон же ссылка сверху. Если вкратце — позволяет рисовать общий лоадер страницы, которая состоит из компонентов, каждый из которых может быть в состоянии загрузки, без того чтобы это состояние тянуть до самого верха страницы.
In short: the new feature allows you to defer rendering part of your application tree until some condition is met (for example data from an endpoint or a resource is loaded).
Вы намекаете на то, что я не прав? Но это именно то, о чем я и написал, и никакого отношения к pausable execution thread это не имеет. Советую еще и видео посмотреть.
До кучи советую посмотреть про то, что же на самом деле такое react fiber: https://m.youtube.com/watch?v=gULfnbZ7dJk
Илья, как обычно, много шутит, но не глубоко копает. В треугольниках серпинского есть задержка в 0.8мс. И проблема там не в количестве перерисовок, а в неэффективности архитектуры Реакта. Про глупости в духе "куча в 2 раза быстрее стека" я вообще молчу.
Технические подробности уже были? При просмотре видео у меня сложилось впечатление, что vintage устроился в facebook и продвинул там идею про throw-based программирование в React :)
1. если код оборачиваешь в Timeout, то он во время асинхронной подгрузки любого дочернего — покажет крутилку
2. если какой-нить дочерний тоже обернут в Timeout, то он будет иметь приоритет и верхний Timeout его проигнорирует
3. если код обернуть в Loading, то он вытащит статус загрузки isLoading со всего поддерева дочерних компонент
4. В рендере можно сделать throw new Promise и реакт перехватит исключение, проверит что пришел промис и перерендерит компонент при ресолве промиса. Если к этому прикрутить кэш, то код выглядит как синхронный.
Печально, что это все сильно реакт усложняет. Команде реакта можно было, например, сделать свой аналог mobx-а, запихнуть туда файберы, обработку асинхронности на исключениях и работу со стейтом.
Такое разделение ответственности позволило бы использовать эти фичи в клонах, вроде preact/inferno и других vdom и real dom библиотеках. Даже отдельного пакета можно не выкладывать, держать в проекте, а сейчас это все прибито к react-dom.
Добавив эту функциональность, они вступили на путь из граблей, по которым уже прошел vintage со своими атомами за последние года 2, есть множество проблем такого подхода. Например:
Что делать, если не promise, а observable?
Как сделать в реакте параллельную загрузку, если бросание эксепшена в render приостанавливает выполнение, а за ним может быть еще один асинхронный запрос.
Как делать retry в случае ошибки?
Как автоматизировать инвалидацию кэша, который в демках скорее всего достаточно примитивный, на каком-нибудь simple-cache-provider?
Возможно, что с их помощью можно будет решить и предложенные Вами сценарии =)
типа createFetcher и <Placeholder> я имел в виду
(постоянно забываю, что тут комментарии поддерживают HTML :-))
Там пока не видно решений этих проблем. Конечно, что-нибудь придумают, может где-то даже лучше чем в атомах. Просто это путь проб и ошибок, который им придется отчасти повторить за винтажем.
Новое API React: Suspense (ру субтитры, с выступления Дэна на JS Conf)