@veltdev/react 6.0.13 → 6.0.14

package/esm/types/primitive-config.types.d.ts

@@ -0,0 +1,41 @@
+/**
+ * @experimental Local stand-ins for the config types returned by the R3 `use*Config` hooks.
+ *
+ * The SDK exposes these objects at runtime (`getCommentDialogConfig()`, `getNotificationsPanelConfig()`,
+ * ...), but `@veltdev/types` does not export their TYPES yet: they live in model files that import
+ * runtime helpers, and the SDK's element `.d.ts` types every one of those methods as `Observable<any>`.
+ *
+ * Importing them from `@veltdev/types` compiles with warnings only, and the published `index.d.ts`
+ * then carries imports of members that do not exist — a TS2305 for every customer with
+ * `skipLibCheck: false`. Until the SDK publishes the real types, alias them to `any` here.
+ *
+ * Deliberately NOT re-exported from the package root, so a later `@veltdev/types` export of the same
+ * names cannot collide with these. When that publish lands, delete this file and import from
+ * `@veltdev/types` again.
+ */
+/** Comment dialog — `CommentElement.getCommentDialogConfig()` */
+export type ComponentConfig = any;
+/** Comment bubble — `CommentElement.getCommentBubbleConfig()` */
+export type BubbleDataConfig = any;
+/** Comment pin — `CommentElement.getCommentPinConfig()` */
+export type PinDataConfig = any;
+/** Comments tool — `CommentElement.getCommentsToolConfig()` */
+export type CommentsToolDataConfig = any;
+/** Multi-thread dialog — `CommentElement.getMultiThreadDialogConfig()` */
+export type MultiThreadDialogDataConfig = any;
+/** Sidebar button — `CommentElement.getSidebarButtonConfig()` */
+export type SidebarButtonDataConfig = any;
+/** Text comment — `CommentElement.getTextCommentConfig()` */
+export type TextCommentDataConfig = any;
+/** Inline comments section — `CommentElement.getInlineCommentsSectionConfig()` */
+export type InlineSectionComponentConfig = any;
+/** Comments sidebar — `CommentElement.getCommentSidebarConfig()` */
+export type SidebarComponentConfig = any;
+/** Notifications panel — `NotificationElement.getNotificationsPanelConfig()` */
+export type NotificationsPanelComponentConfig = any;
+/** Notifications tool — `NotificationElement.getNotificationsToolConfig()` */
+export type NotificationsToolDataConfig = any;
+/** Activity log — `ActivityElement.getActivityLogConfig()` */
+export type ActivityLogComponentConfig = any;
+/** Autocomplete — `AutocompleteElement.getAutocompleteConfig()` */
+export type AutocompleteComponentConfig = any;

package/esm/utils/propUtils.d.ts

@@ -3,6 +3,23 @@ export declare const transformWireframeProps: (props: {
 }) => {
     [key: string]: any;
 };
+/**
+ * Props a wrapper does not handle itself, prepared for spreading onto the Velt custom element.
+ *
+ * - `children` is ALWAYS removed. A wrapper that supports children renders `{children}` itself; one
+ *   that does not must keep dropping them. Spreading them would place customer React nodes inside
+ *   elements that never received them before, where Angular can wipe them out from under React.
+ * - React 16-18 do not map `className` to `class` on custom elements — they render a literal
+ *   `classname="..."` attribute, which no stylesheet matches (React 19 maps it). So `className` is
+ *   rewritten to `class`, merged with an explicit `class` if one is given.
+ * - Everything else (`id`, `style`, `data-*`, `aria-*`, event handlers) already behaves on custom
+ *   elements and passes through unchanged.
+ */
+export declare const transformCustomElementProps: (props: {
+    [key: string]: any;
+}) => {
+    [key: string]: any;
+};
 /**
  * To deep compare two objects.
  * @param arg1 object 1

package/esm/utils/propUtils.test.d.ts

@@ -0,0 +1 @@
+export {};