Class ComponentSpec

Current change request being processed, if any. Populated by Impact Assessor at the start of a modification flow. Updated by each agent as it processes the request.

This field is only present during active modification flows and for embedded components (never on registry components).

JavaScript code

Declares the contract this component implements.

Distinct from type (which is descriptive): componentRole is a commitment that the component's props, events, and methods conform to a role-specific contract, letting hosts mount it generically and letting authoring agents target a known shape.

• form: implements FormHostProps + standard form events/methods (see @memberjunction/interactivecomponents/forms). Hosted by InteractiveFormComponent against a BaseEntity record.
• dashboard | widget | report | detail-pane: reserved for future role contracts.

Unset = a generic component, mounted directly. No behavior change for existing components.

When an architect decides to use an existing component as a base for a new version, they can set this flag to true. This indicates that the new version will be created based on the existing component based on the namespace/name/version specified above

Describes the entities and queries a component requires to function.

Describes any other components this one depends on, if any

End-user friendly description of what the component does

Optional array of diagrams that use Mermaid syntax to illustrate component design. When provided each entry in the array specifies a title, optional description and the mermaid content itself. Examples of diagrams include:

• Flowcharts of the process the component implements
• Entity-relationship diagrams of the data model the component uses
• Sequence diagrams illustrating interactions between the components various parts

Events that the component emits, if any

Example of the component being used in JSX format. This is used to provide a clear example on the properties and event handling that the component supports.

A functional description of what the component should do in markdown.

Describes:

• Core functionality
• Any business rules
• Expected outcomes
• UX considerations

Result of the most recent test harness execution. Tells downstream agents whether the current code is working or broken.

Only populated for embedded components after code generation completes. Registry components do not have test results as they are pre-tested.

3rd party lib dependencies, if any

Components can be embedded or registry. Registry means we don't have the code directly here nor do we generate the code, we simply use the component from its registry

Metadata about methods the component supports, if any

Used when location === "registry", a hierarchical namespace such as "crm/analytics/accounts". The combination of the namespace and name are how a registry component is loaded. Registry components might have a root level segment that starts with @ such as "@memberjunction/examples/entities" or if the root segment doesn't have @ that means the component is local to that registry

Properties the component accepts, if any

Self-declared maturity level of the component. When a component is "in progress" and is not yet complete but is partially done, it can be marked as "incomplete". When it is functionally complete but not yet widely tested, it can be marked as "beta". When it is fully complete and tested, it can be marked as "production". This is intended to help architects and developers understand the readiness of a component for use in production systems.

Used when location === 'registry' - the unique name of a given registry without the @ sign for example MJ or Skip would be valid globally unique registry names (as registered with MemberJunction.org) You would not include @ here. Fully qualified component identifiers would be @Registry/Namespace/Name/Version but in the context of this field it is just the registry name.

Relevant examples of components intended to inspire this component's creation

Only used when location === 'registry', logic explaining why this component is being selected to serve a specific use case or requirement

Technical explanation of the component in markdown.

User-friendly name

Self-declared type - some common options below, can be any string if the standard ones aren't sufficient

Optional: Custom type definitions for complex prop types (e.g., ColumnDef, FieldDefinition). Similar to TypeScript interfaces, used for lint-time validation of object literals.

Used when location === "registry", a semantic versioning string such as "1.0.0" "^1.0.0" "~1.0.0" Follows conventions documented here: https://semver.org/ and https://docs.npmjs.com/about-semantic-versioning

If a component isn't complete or encounters problems in testing, this field can be used to track a work plan for completing or fixing the component. Generally this work plan string will contain a markdown formatted list of tasks to be done with rich explanations to allow developers (human+AI) to collaborate on completing the component.