How to specify widget behavior for component properties with a custom A-Frame inspector?

user_5347747 0
Viewed 56

We are working on a custom version of the A-Frame inspector. The default inspector exposes all properties of all components of an entity for editing, but we wish to be able to specify at the component level which properties may be displayed to a user and render certain properties using custom widgets.

What is the best way to specify which properties to hide, rename, or use a custom widget (such as button or large-text-field)?

Here are some ideas we came up with:

  1. Write custom logic in the editor that determines which fields to display depending on the component name. For example if component name is street then display custom widgets via custom logic inside of the modified inspector.

  2. Define at the entity level with an attribute such as data-editor-hide-props="prop1, prop2, prop3"

  3. Define at the component level. There are a few options for this:

    • A. Create a new method on every component that we want to have custom UI for. This method returns an object that indicates which fields should be displayed, hidden, and if certain field should use a custom widget.
    • B. Use the property name to indicate which custom widget should be rendered. For example, if a boolean field is named buttonFoo_Bar render a button widget (instead of a checkbox) with the display text "Foo Bar"
    • C. Add extra values to the schema to indicate rendering preference. Such as below:
AFRAME.registerComponent('street', {
  schema: {
    JSON: { type: 'string', editorWidget: 'large-text-field' },
    type: { default: 'streetmixSegmentsFeet' }, 
    left: { default: '', editorDisplay: false },
    right: { default: '', editorDisplay: false },
    showGround: { default: true },
    showStriping: { default: true },
    length: { default: 150 },
    actionRefresh: { type: 'boolean', editorWidget: 'button', editorDisplayName: 'Refresh Street' }
  },

These extra component schema values seem to be ignored by A-Frame and do not throw an error. Is this a safe assumption?

Suggested answer: 3C seems like the "right" answer in the long-term, but it might be easier to start with 1 and then later migrate to 3C.

What do you think?

aframe
1 Answers

Hardcoding any logic in the editor will deny any flexibility (though might be simple for some initial prototyping)

I'm also not sure about option 3, You'd have to modify lots of existing components, sometimes it may add some level of complication to already complex components.

I would try going somewhere in the way of the second option - adding a new component, inspector__<component name>, where you will define which fields of the component should be displayed and how. It can pass all info to a predefined system, which is easily accessible and manageable.

It will work with existing components, and will be an add-on which is bound to the inspector, but won't affect any components (not only from a 'single responsibility' standpoint, even from the aspect of the components readability, and maintainability).

user_24257870
Related