@relyio/sdk 0.8.0 → 0.9.0

package/CHANGELOG.md

@@ -1,5 +1,36 @@
 # @relyio/sdk
 
+## 0.9.0
+
+### Minor Changes
+
+- 187624c: **`<RelyIOProvider live>` no longer misses a publish that lands while the page is loading.** The provider used to send its reads first and open the feed afterwards, from the feed's position at that moment — so anything published in between was in neither, and the page showed the old content until that entry changed again. With `live` on, the reads beneath the provider now wait until the feed has opened and sent its position — the first thing it sends, so there is no extra request and the edge counts your visitor once — and then go; anything published after that position is announced and refetched like any other change. The same holds after a connection that failed before it had a position: everything is refetched once the new one has sent its position. If the feed fails before it has one — it is down, or refuses the key — the reads are sent without it, so content never waits on a feed that is down. A server render is unchanged: its reads never wait. Nothing to change in your code, but `@relyio/react` now needs `@relyio/sdk` 0.9.0 or later, the release that carries this.
+
+  **A socket that neither opens nor fails is given up after fifteen seconds.** `liveChanges()` used to wait on such a socket — a network that holds the upgrade without refusing it — for as long as the page was open. It now closes a socket that has not opened and been told its position within `LIVE_SOCKET_OPEN_TIMEOUT_MS` (the poll interval, fifteen seconds; newly exported) and polls the edge from the same cursor instead, as it does for a socket that fails to open. That also bounds how long the provider's first reads wait.
+
+  **Read after the feed's position, with no request of your own for it.** Opened without `since`, `liveChanges()` and `changes()` hand the position they start from to `reached` before anything after it — the edge's `feed.opened` or first poll's answer; `/v1/changes`' first answer. `ChangesOptions` gains `reached` for this; `changes()` calls it once, with that head, and never with a later page's cursor — so `followChanges()` over `changes()` now reopens from that head after a failure before the first change, rather than refetching everything. Read what you show after that call, and a publish your read did not see is announced. With `followChanges()`, which hands the source its own `reached`, call both:
+
+  ```ts
+  let positioned!: () => void
+  const position = new Promise<void>(resolve => (positioned = resolve))
+  const following = followChanges(
+    from =>
+      relyio.liveChanges({
+        ...from,
+        ids: [id],
+        reached: cursor => {
+          from.reached(cursor)
+          positioned()
+        },
+      }),
+    { signal, onChange, onResync, onState: state => state.kind !== 'following' && positioned() },
+  )
+  await position
+  const post = await relyio.content('post').findById(id).execute()
+  ```
+
+  `changesHead()` still takes the position with a request of its own, for a feed you open later.
+
 ## 0.8.0
 
 ### Minor Changes