@rebasepro/common 0.11.0 → 0.11.1-canary.g8caabf3

package/dist/data/buildRebaseData.d.ts

@@ -28,10 +28,10 @@ export declare function buildRebaseData(driver: DataDriver, options?: EntityData
 /**
  * Wrap a flat {@link RebaseSdkData} into a Entity-shaped {@link RebaseData}.
  *
- * This is the **CMS boundary**: the SDK client (`client.data`) returns flat
+ * This is the **admin boundary**: the SDK client (`client.data`) returns flat
  * rows, but the admin renders the `Entity` view-model (`entity.values.*`).
  * `core/Rebase.tsx` wraps `client.data` through this before handing it to the
- * CMS `RebaseDataContext` — without it the admin renders rows with only their
+ * admin `RebaseDataContext` — without it the admin renders rows with only their
  * `id`.
  */
 export declare function wrapAsEntityData(sdkData: RebaseSdkData, options?: EntityDataOptions): RebaseData;
@@ -50,6 +50,6 @@ export declare function wrapAsSdkData(entityData: RebaseData): RebaseSdkData;
  * This is the developer-facing SDK data layer used by backend framework
  * callbacks & scripts (`context.data` / `rebase.data`). It returns flat rows —
  * identical in shape to the frontend SDK client — so the API is symmetric
- * across front and back. The admin CMS uses {@link buildRebaseData} (Entity).
+ * across front and back. The admin uses {@link buildRebaseData} (Entity).
  */
 export declare function buildSdkData(driver: DataDriver): RebaseSdkData;

package/dist/index.es.js

@@ -142,7 +142,7 @@ function traverseValueProperty(inputValue, property, operation) {
 	return value;
 }
 /**
-* Create a lightweight relation stub for CMS views.
+* Create a lightweight relation stub for admin views.
 * Replaces inline `{ id, path, __type: "relation" }` object literals.
 */
 function createRelationRef(id, path) {
@@ -3051,7 +3051,7 @@ function toSdkCollectionClient(snap) {
 /**
 * Wrap a flat {@link SDKCollectionClient} into a Entity-shaped
 * {@link CollectionAccessor}. Every returned row is re-wrapped into the
-* `{ id, path, values }` view-model the admin CMS renders.
+* `{ id, path, values }` view-model the admin admin renders.
 */
 function toEntityAccessor(sdk, slug, getPks = () => []) {
 	const accessor = {
@@ -3099,10 +3099,10 @@ function toEntityAccessor(sdk, slug, getPks = () => []) {
 /**
 * Wrap a flat {@link RebaseSdkData} into a Entity-shaped {@link RebaseData}.
 *
-* This is the **CMS boundary**: the SDK client (`client.data`) returns flat
+* This is the **admin boundary**: the SDK client (`client.data`) returns flat
 * rows, but the admin renders the `Entity` view-model (`entity.values.*`).
 * `core/Rebase.tsx` wraps `client.data` through this before handing it to the
-* CMS `RebaseDataContext` — without it the admin renders rows with only their
+* admin `RebaseDataContext` — without it the admin renders rows with only their
 * `id`.
 */
 function wrapAsEntityData(sdkData, options) {
@@ -3154,7 +3154,7 @@ function wrapAsSdkData(entityData) {
 * This is the developer-facing SDK data layer used by backend framework
 * callbacks & scripts (`context.data` / `rebase.data`). It returns flat rows —
 * identical in shape to the frontend SDK client — so the API is symmetric
-* across front and back. The admin CMS uses {@link buildRebaseData} (Entity).
+* across front and back. The admin uses {@link buildRebaseData} (Entity).
 */
 function buildSdkData(driver) {
 	return wrapAsSdkData(buildRebaseData(driver));