@relyio/sdk 0.8.0 → 0.10.0

package/CHANGELOG.md

@@ -1,5 +1,57 @@
 # @relyio/sdk
 
+## 0.10.0
+
+### Minor Changes
+
+- d147cb3: **A view's filters are a flat list.** `defineView`'s `filters` take `{ field, operator, value }` filters, joined by AND — the Filters the Studio's entry list takes, each shown as a chip. The group form, an `operator` with `conditions`, is gone: `ViewFilterGroup` is no longer exported, `ViewFilter` is one filter, and `defineView` throws, naming the view and the filter, if you pass a group from JavaScript. For an OR within one field, use `isAnyOf`:
+
+  ```ts
+  defineView('newsAndSport', {
+    name: 'News and sport',
+    scope: { type: 'contentType', contentType: 'post' },
+    filters: [
+      { field: 'category', operator: 'isAnyOf', value: ['news', 'sport'] },
+      { field: 'featured', operator: 'is', value: true },
+    ],
+  })
+  ```
+
+  A YAML schema's `views[].filters` are the same list, and `relyio validate` and `relyio deploy` refuse a filter group by name, at `views.<n>.filters.<n>`.
+
+  **Deploy now checks each view filter against the entries it narrows.** The field must be one the view's entries can be filtered by, and must offer the operator and take the value — so a boolean field takes `is` with `true` or `false`, not `isTrue`, and a tags field is not filtered with `includes`. A filter that does not fit is refused by name at `views.<n>.filters.<n>.field`, `.operator` or `.value`. `relyio status` refuses it too. `relyio validate` checks a view filter's shape, not this: run `relyio status` to see what deploy will say.
+
+## 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