Skip to Main Content
Builder.io Ideas
Created by Korey Kassir
Created on Aug 2, 2022

Input types for SDKs

Feedback from Tekton:


So the first issue I notice when using the @builder.io/react and @builder.io/react/lite packages is that the Builder class is simply exported without new type definitions or specific React bindings. What I would expect to see in the React SDK is some class or function that wraps the core Builder Class to provide better ergonomics when using the Builder React SDK in a React TS project. Because there is no binding that defines React-specific types, the types given are the loose, framework-agnostic types. For example, Builder.registerComponent has the type signature of (component: any, options: Component): void. However, when I'm using this in my React app, we know what types the component can take on, so the function definition exported from the Builder React SDK should be <Props extends object>(component: React.ComponentType<Props>, options: Component): void. Yet, this is an incorrect type because Builder will inject the attributes property and the component needs to handle that when using the option noWrap is true, so the type should instead be similar to this: <Props extends { attributes: {'builder-id": string; builderBlock: BuilderBlock; builderState: BuilderStore } }>(component: React.ComponentType<Props>, options: Component): void. This behavior is not documented completely, and without type definitions, the user of the SDK has to realize through trial and error what fields exist on the attributes object injected by Builder.

Additionally, the second parameter in Builder.registerComponent is typed as Component. On a meta note, I would suggest naming this interface something less ambiguous, like BuilderComponentOptions. In context, this signature is confusing: (component: any, options: Component). A naive thought would be to assume this is wrong and component should be a type of Component.

The main issue I have with registerComponent is the lack of inference used on the Input interface to enforce correct usage of the inputs object. Say I have the following input options:

inputs: [

{

name: 'variant',

type: 'text',

enum: ['primary', 'secondary', 'inline'],

defaultValue: 'primary', // <------ this value should only be able to be 'primary' | 'secondary' | 'inline' and not any.

}

]}


  • Attach files