You need a component to re-render when a non-React store changes (a Redux-like store, a browser API like navigator.onLine, or a custom event emitter). Why not just useState + useEffect, and what does useSyncExternalStore solve?
Awareness of tearing under concurrent rendering and the correct subscription primitive.
The naive approach — subscribe in useEffect and copy the store value into local state — has two problems. First, there's a gap: the effect runs after render, so between the initial render and the subscription the store could change and you'd miss it. Second, and the real reason the hook exists: under concurrent rendering React can pause and resume renders, and different components (or different parts of one render) could read *different* values from a mutable external store mid-render — the UI 'tears', showing inconsistent data. useSyncExternalStore is the official primitive for subscribing to external mutable stores safely. You give it three things: a `subscribe(callback)` that registers a listener and returns an unsubscribe, a `getSnapshot()` that returns the current value, and (for SSR) a `getServerSnapshot()`. React uses it to read a consistent snapshot and to force a synchronous re-render when the store changes, avoiding tearing. This is what Redux, Zustand, and Jotai use internally. The snapshot must be referentially stable when unchanged (return the same object, don't build a new one each call) or you'll loop. For simple cases (online status, media queries, window size) it's cleaner than effect-based subscription and correct under concurrency.
Re-render on changes to a store outside React (Redux-like, browser API, event emitter) → useSyncExternalStore, not useEffect copying.