SolidJS 2.0 постачається з нативною моделлю асинхронних даних, яка дозволяє компоненту ставитися до промісу як до будь-якого іншого реактивного значення, і робить це без каскаду ререндерів, з якими стикаються розробники React при використанні Suspense та хуків. Ця зміна є важливою, оскільки вона дозволяє інтерфейсу залишатися на екрані під час оновлення даних, зменшує кількість шаблонного коду та пропонує чіткий шлях для команд React для перенесення свого коду отримання даних у Solid.

Чому асинхронна модель Solid відчувається інакше

У React компонент, якому потрібні дані, зазвичай викликає хук (часто кастомний), що повертає об'єкт, подібний до промісу, а потім огортає UI в <Suspense>, щоб показати fallback, поки проміс виконується. Щоразу, коли проміс завершується, React планує ререндер; якщо той самий компонент згодом виконує повторне отримання даних (refetch), fallback може миготіти поверх контенту, який уже відображається.

Solid змінює правила гри. Проміс — це просто значення, за яким стежить реактивний граф. Коли обчислення зчитує це значення, граф призупиняє це зчитування, доки проміс не виконається, але решта UI залишається відрендереною. Під час першого монтування компонента межа <Loading> може відобразити fallback; після цього повторне отримання даних не чіпає існуючий DOM, доки не надійдуть нові дані. Жодного явного «await» всередині компонента, жодного createResource, жодних ручних перемикань стану.

Основні примітиви

  • Межа <Loading> – замінює React-івський <Suspense>. Вона показує fallback лише під час початкового завантаження. Після першого рендерингу очікуване зчитування не замінює UI; старий контент залишається, доки не виконається отримання нового значення. Передайте проп on, щоб примусово показати спінер під час конкретного refetch.
  • Компонент <Reveal> – керує тим, як кілька меж <Loading> з'являються разом. Виберіть:
    • Sequential: межі з'являються одна за одною відповідно до порядку в DOM.
    • Together: усі з'являються одночасно, коли всі дані готові.
    • Natural: кожен з'являється, щойно приходять його власні дані.
  • Сигнал isPending – повертає true, поки триває конкретне зчитування. Використовуйте його, щоб накласти тонку смугу завантаження або ледь помітну анімацію, поки основний контент залишається видимим, що дає вам стратегію «stale-while-revalidate» без додаткових зусиль.
  • Генератор action – замінює оновлення мутабельного стану в React. action(function*…) може оптимістично оновити UI, використати yield, щоб дочекатися відповіді сервера, а потім узгодити результат, коли проміс виконається. UI відчувається миттєвим, а етап узгодження вбудований у примітив.

Як ці елементи співвідносяться з концепціями React

Функція Підхід React Підхід Solid 2.0
Отримання даних use() (експериментальний) або сторонні хуки; результат огортається в <Suspense> createMemo (або подібне), що повертає проміс; зчитування безпосередньо в JSX
UI завантаження <Suspense> може знову викликати fallback при кожному refetch <Loading> лише при першому завантаженні; refetch зберігає старий UI
Оновлення useTransition для відкладення оновлень UI isPending сигналізує про очікувані зчитування без заміни UI
Мутації useState/useReducer + асинхронні виклики, часто огортані в кастомні дії action(function*…) з вбудованою оптимістичною обробкою

Практичний підсумок полягає в тому, що Solid вбудовує те, що React розглядає як окремі хуки, безпосередньо в ядро рушія реактивності.

Покроковий посібник з міграції

  1. Identify the data source – In React you likely have const data = useMyFetch(url). In Solid replace that with a memo that returns the promise: const data = createMemo(() => fetch(url).then(r => r.json())).
  2. Wrap the top-level component – If the component renders before the promise resolves, surround it with <Loading fallback={<Spinner/>}>…</Loading>. The fallback appears only on the first mount.
  3. Replace per-refetch spinners – Where you previously toggled a loading flag, now read isPending(data). Use that boolean to render a subtle indicator while the existing UI stays on screen.
  4. Convert optimistic updates – If you had setState(prev => ({...prev, optimisticValue})) followed by an async call, rewrite as const update = action(function* (newValue) { state = newValue; const server = yield fetch(...); state = reconcile(server); });. The generator yields control until the server responds, then automatically updates the reactive graph.
  5. Handle multiple async pieces – Nest <Loading> boundaries as needed, then add a <Reveal> wrapper to decide whether they appear together or one after another. This replaces patterns where React developers staggered multiple <Suspense> components with complex state checks.
  6. Test the flow – Because Solid does not re-render on promise resolution, verify that UI updates still occur where you expect them. The reactive graph propagates changes automatically; there is no need for extra useEffect calls.

What’s still in flux

Solid 2.0’s async API is currently in beta. Names like <Loading> and action may shift before the stable release, and the documentation still evolves. The core idea—treating promises as reactive values—remains unchanged, but early adopters should expect minor breaking changes as the library settles.

Who stands to gain

  • React teams with heavy data fetching – The reduced need for external state libraries and the built-in stale-while-revalidate pattern can shrink bundle size and simplify codebases.
  • Performance-focused apps – By avoiding full component re-renders on every fetch, Solid delivers smoother visual updates, especially on low-end devices.
  • Developers tired of “flash of spinner” – The <Loading> boundary’s “first-load-only” behavior eliminates the common annoyance of a spinner flashing over content that is already visible.

Possible drawbacks

  • Beta status – Until the API stabilizes, long-term projects may need to budget for migration effort later.

What to watch next

Keep an eye on the official changelog for any renaming of <Loading> or action.

Bottom line: SolidJS 2.0 lets you treat promises as first-class reactive values, keeping the UI steady while data refreshes and removing the need for a suite of React-style hooks. For teams ready to move beyond the re-render-centric model, the migration path is clear, the performance upside is tangible, and the only real risk is the usual beta-stage uncertainty.