@rebasepro/common 0.13.0 → 0.13.1-canary.g249daa1

package/src/util/resolutions.ts

@@ -261,11 +261,11 @@ export function resolveArrayProperties<M>({
                 ignoreMissingFields,
                 ...props
             });
-            const {
-                values,
-                previousValues,
-                ...rest
-            } = props;
+            // Destructured to be *excluded* from `...rest`, not to be used —
+            // see the comment below. Said explicitly so the discarded-value
+            // ratchet does not carry a finding that is working as intended.
+            // eslint-disable-next-line @typescript-eslint/no-unused-vars
+            const { values, previousValues, ...rest } = props;
             const ofProperty = resolveProperty({ // we don't want to pass the values of the parent entity
                 property: of,
                 ignoreMissingFields,
@@ -449,6 +449,78 @@ singularName: customName } : {})
     return views;
 }
 
+/**
+ * Each of `collection`'s tabs paired with the property that declared it, when a
+ * property declared it: child view key → property key.
+ *
+ * A many-relation can only be declared as a property — that is the documented
+ * and only mechanism — and {@link getEntityChildViews} promotes it to a tab. So
+ * one declaration reaches the panel twice, and neither surface knew about the
+ * other. The form rendered a relation picker beside the tab, and the collection
+ * table rendered *two* columns under one heading: the relation's own column,
+ * showing the child rows, and a jump-to-tab button carrying the same name.
+ *
+ * The pairing is what lets each surface decide which half is redundant, and it
+ * has to be a pairing rather than two sets because the two keys differ whenever
+ * a relation is named. The match is on the resolved `relationName` — the
+ * identity `getEntityChildViews` itself dedupes on — so a relation declared in
+ * `relations` and pointed at by a differently-named property is recognised too.
+ *
+ * A relation with no property of its own is absent here, which is the point: it
+ * has exactly one surface already, and nothing to weigh it against.
+ *
+ * Only top-level properties: a relation nested inside a `map` gets no tab.
+ */
+export function getChildViewDeclaringProperties<M extends Record<string, unknown> = Record<string, unknown>>(
+    collection: CollectionConfig<M>
+): Map<string, string> {
+    const pairs = new Map<string, string>();
+
+    const relationProperties = Object.entries((collection.properties ?? {}) as Record<string, Property>)
+        .filter(([, property]) => property?.type === "relation");
+    if (relationProperties.length === 0) return pairs;
+
+    const relationViews = getEntityChildViews(collection)
+        .filter(view => view.source.kind === "relation");
+    if (relationViews.length === 0) return pairs;
+
+    const resolvedRelations = resolveCollectionRelations(collection);
+    const identityOf = (relationKey: string): string =>
+        resolvedRelations[relationKey]?.relationName ?? relationKey;
+
+    const declaringPropertyByIdentity = new Map<string, string>();
+    for (const [propertyKey, property] of relationProperties) {
+        const relation = (property as RelationProperty).resolvedRelation ?? resolvedRelations[propertyKey];
+        // A to-one relation is a foreign key the author edits, never a tab. No
+        // view will match it — the views here are many-relations only — but
+        // reading the cardinality says so where someone is looking.
+        if (relation?.cardinality !== "many") continue;
+        const identity = relation.relationName ?? propertyKey;
+        if (!declaringPropertyByIdentity.has(identity)) declaringPropertyByIdentity.set(identity, propertyKey);
+    }
+
+    for (const view of relationViews) {
+        const propertyKey = declaringPropertyByIdentity.get(
+            identityOf((view.source as { relationKey: string }).relationKey));
+        if (propertyKey) pairs.set(view.key, propertyKey);
+    }
+
+    return pairs;
+}
+
+/**
+ * The property keys of `collection` whose relation is already one of its tabs.
+ *
+ * What a form asks: the tab is the treatment for a list of child rows, so the
+ * picker beside it is the redundant half. See
+ * {@link getChildViewDeclaringProperties}.
+ */
+export function getChildViewRelationPropertyKeys<M extends Record<string, unknown> = Record<string, unknown>>(
+    collection: CollectionConfig<M>
+): Set<string> {
+    return new Set(getChildViewDeclaringProperties(collection).values());
+}
+
 /**
  * The child views of `collection` as bare collections.
  *