Refactoring Core Functionality

[akkadaska]

After using jotai-ssr for a certain period in a large-scale Next.js App Router project that heavily utilizes Jotai Atoms, we found that only a small subset of the initially anticipated use cases were necessary, while we also encountered cases where functionality was lacking. Based on these experiences, we have revamped the features provided by the library.

Changes from v0.1.*

RenderingBoundary has been replaced with SSRProvider

• RenderingBoundary has been replaced by SSRProvider, and a simple replacement will ensure it works as expected.
• There is no equivalent for the performanceImpactingUseUpperStore option of RenderingBoundary. Instead, in environments where this is needed, placing the SSRProvider at the appropriate location and adhering to hydration rules will achieve the same result. These rules are detailed in the new README under the section "Soft Navigation in SSR Frameworks."

RenderingBoundary was designed to automatically support soft navigation by placing it at every rendering boundary. However, based on our practical experience, its use cases turned out to be very limited. Instead, placing the Provider manually at the appropriate locations and following hydration rules avoids opaque behavior and improves performance for commonly used scenarios. SSRProvider is a simple Provider that encapsulates considerations for creating stores in SSR environments.

Removal of SuspenseBoundary

• SuspenseBoundary has been removed. It is unnecessary if hydration rules are followed.

SuspenseBoundary was redundant if the hydration rules described in the new README under "Important Notes on Hydration Logic" were followed.

Addition of useHydrateAtoms

• While HydrationBoundary was the only hydration method provided by jotai-ssr, we have added useHydrateAtoms, which allows the same functionality to be utilized via a hook.
  While HydrationBoundary was particularly convenient for use in React Server Components, there were cases where a hook was more manageable. To address this, we introduced useHydrateAtoms.

Support for Re-Hydration

• Re-Hydration options have been added to HydrationBoundary and useHydrateAtoms. These options make it easier to synchronize Atoms with server-side state when refreshing a page using features like Next.js's revalidatePath or during soft navigation in slug-based pages in frameworks like Remix or Waku. Details are provided in the README under the "Re-Hydration" section.

Enhanced README

• The README has been significantly improved, with added explanations on creating Providers, important notes for hydration, and examples of hydration with streams.

close #8