@uniweb/api 0.2.13 → 0.3.1

package/README.md

@@ -1,25 +1,25 @@
 # @uniweb/api
 
-The client a foundation uses to talk to **its site's own backend** — sign-in, the
+The client a foundation uses to talk to **its site's `api` service** — sign-in, the
 site's members, and the content they create.
 
 You import it the way you import `@uniweb/kit`. It is bundled into your foundation,
-tree-shaken, and **inert on a site that has no backend**: nothing throws, no request
+tree-shaken, and **inert on a site that has no `api` service**: nothing throws, no request
 leaves, and your components render the version of themselves that does not need one.
 
 ```bash
 npm install @uniweb/api
 ```
 
-## Is there a backend?
+## Does the site have the service?
 
 Ask before you draw. This is a synchronous read of the site's own configuration, not
 a probe — there is nothing to await.
 
 ```jsx
-import { isEnabled } from '@uniweb/api'
+import { isApiEnabled } from '@uniweb/kit'
 
-if (!isEnabled(website)) return <StaticVersion />
+if (!isApiEnabled()) return <StaticVersion />
 ```
 
 ⛔ **And when the answer is no, draw nothing** — not a disabled button, and not an
@@ -62,8 +62,8 @@ const { status, records, matched, hasMore } = useRecords({ schema: '@/session' }
 ```
 
 ⭐ **`absent` and an empty `ready` are different answers.** `absent` means there is no
-live source — no backend, or nobody signed in — so render your site's own content.
-`ready` with `records: []` means the backend answered and there is nothing there.
+live source — no `api` service, or nobody signed in — so render your site's own content.
+`ready` with `records: []` means the service answered and there is nothing there.
 Showing "nothing yet" for the first case tells a visitor their content is missing
 when it is simply not being asked for.
 
@@ -100,13 +100,13 @@ Three things it does for you, and one it deliberately does not:
 
 ⚠️ `update` replaces the item's data whole. Spread what you are not editing.
 
-## A backend on your machine
+## The service on your machine
 
-Building against a live backend is slow and puts a shared database behind your
+Building against a live service is slow and puts a shared database behind your
 experiments. Name a local one in `site.yml`:
 
 ```yaml
-api: /_api                 # where the backend answers — the same in production
+api: /_api                 # where the service answers — the same in production
 $devApi: ./mock/api.js     # what answers it locally; never published
 ```
 
@@ -137,7 +137,7 @@ npx uniweb-api-mock --port 8787
 ```
 
 ⛔ **The mock is a fixture of what this package expects, not a model of any real
-backend.** Behaviour it happens to have is evidence about the mock and nothing else.
+server.** Behaviour it happens to have is evidence about the mock and nothing else.
 
 ## Outside React
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@uniweb/api",
-  "version": "0.2.13",
+  "version": "0.3.1",
   "description": "The client for a Uniweb site's own backend — session, records, entities — imported by a foundation the way it imports @uniweb/kit.",
   "type": "module",
   "exports": {
@@ -34,7 +34,7 @@
     "node": ">=20.19"
   },
   "dependencies": {
-    "@uniweb/core": "^0.24.2"
+    "@uniweb/core": "^0.24.4"
   },
   "peerDependencies": {
     "react": "^19.0.0"

package/src/client.js

@@ -31,8 +31,8 @@ export const CONTRACT = 1
 /**
  * Where the site's backend is, if it has one.
  *
- * `resolveService` answers with the site's own declaration first (`api:` in
- * `site.yml`), then the host's (`config.services.api`), and `null` when neither
+ * `resolveService` answers with the host's offer first (`config.services.api`),
+ * then the site's own declaration (`api:` in `site.yml`), and `null` when neither
  * names an address. Absence is the ordinary state of a site with no backend,
  * not an error.
  *
@@ -44,16 +44,34 @@ export function resolveBase(website) {
 }
 
 /**
- * Does this site have a backend the package can talk to?
+ * Does this site have an app backend — the `api` service?
  *
  * The question to ask before drawing a sign-in affordance or any control only a
  * backend can answer. False means: draw nothing, or the static alternative the
  * site already carries.
  *
- * @param {object} website
+ * ⭐ **The website argument is OPTIONAL and defaults to the active one**, so this
+ * is the same call as `@uniweb/kit`'s `isApiEnabled()` — one predicate per
+ * service, no arguments, the website resolved for you. Pass one explicitly only
+ * when you already hold it, or are working outside a render.
+ *
+ * ⛔ **THE DEFAULT IS NOT A CONVENIENCE, IT CLOSES A TRAP.** For one commit this
+ * took a REQUIRED website while every doc and template showed the no-argument
+ * spelling — so `import { isApiEnabled } from '@uniweb/api'` followed by
+ * `isApiEnabled()` resolved `undefined`, returned `false` forever, and drew no
+ * sign-in UI on a site that had a backend. Silent, and indistinguishable from a
+ * site with no backend: exactly the invisible absence this predicate exists to
+ * prevent. Caught in review the same day; pinned by `tests/enabled.test.js`.
+ *
+ * ⛔ **Renamed from `isEnabled` (2026-09-10).** The old name said nothing about
+ * its subject and collided with three unrelated `isEnabled`s in the framework —
+ * including the field `useSearch()` returns, which made `uniweb doctor` read a
+ * search control as gated when it was gated on this instead.
+ *
+ * @param {object} [website] - defaults to the active website
  * @returns {boolean}
  */
-export function isEnabled(website) {
+export function isApiEnabled(website = getUniweb()?.activeWebsite ?? null) {
   return resolveBase(website) !== null
 }
 

package/src/index.js

@@ -13,7 +13,7 @@
 export {
   SERVICE_NAME,
   resolveBase,
-  isEnabled,
+  isApiEnabled,
   probeSession,
   signIn,
   completeChallenge,