Stage and set values of components before attaching them

[ngokevin]

Community components are most guaranteed to work well on the initialization. How well they can handle updates or handle being attached with zero data, is less reliable since it requires closer management of the lifecycle. That means they may work great from HTML, but may not with the Inspector.

Ideally, we seek to improve those components, but it'd be great to have most of them working out of the box today without having to chase down and PR each one. When we add a component, we should "stage" the addition, allow people to set values, and then finally save/attach the component.

[fernandojsg]

I don't really like it. It will add another step on the editor just to handle bugs on components, and we'll have two different path while adding a new component, if the components come from core you'll just add them straightforward, but if they're thirdparty you'll have that extra "stage" step, even if the component are working properly.

That extra step seems unnecessary and not very nice from the UX point of view, and also it doesn't fix the problem, It just tries to hide it or delays it. Because for example I could add a text component, enter some data on the "stage" step, and click apply, but then I would like to modify the text and it won't works, so people could think that the inspector is buggy too.

For this kind of problems is why we're going to do curation on the aframe-registry, we should validate that they've implemented the updates and zero-init, otherwise we won't add them to the registry, so they people could add them at their own risk. If we let entering buggy components onto the registry and we create paths to "fix" them on our tools, we're adding complexity and potentially encouraging users to upload components without taking care of this issues as it will "just works".

Also we should take advantage of the initial PRs to populate the registry from early adopters and put our effort on helping them to fix these issues.

[ngokevin]

OK, makes sense.

[dmarcos]

Schemas could have a prompt flag that is false by default. If a component sets it to true a modal dialog is shown before adding the component to the entity

[ngokevin]

It's true that incorrect update handling and zero-init does seem buggy. For particle system, I am currently making a PR to fix updates because it wouldn't clear the old one. For my animation component, the Inspector was breaking on zero-init so I need to investigate that.

Going to see how much work most components need before considering overloading the schema/package.json flag + Inspector UI

[fernandojsg]

@dmarcos yes that could be a solution but still we need to curate the use: this should be used just on components/attributes where once the value is set it's not possible to do changes. But we should do something after showing that modal, should we hide the whole attributes panel for that component? just the attribute that was shown on the component?

[ngokevin]

Just noting, there could be components that optimize/test for the use case of setting via HTML once and not expecting to handle updates. Which sounds mostly fine for development, but not the Inspector. But for now, we can optimize for Inspector and see where that leads...

[fernandojsg]

IMHO we should try to delay this as much as we can, and try to put the effort as @ngokevin says on trying to fix the components before adding a new workflow. And after a while we could identify the edge cases and work on a proper solution to fit them.

[fernandojsg]

Maybe a bruteforce solution for this kind of components is to mark them as "Impossible to edit once first loaded" and every time you modify something it will destroy and attach a new component? In that case still we need to be sure that the destroy process go well and we don't leave garbage somewhere.

[ngokevin]

I think many components ensure remove less than they do update so that probably wouldn't work well, on top of it already being hacky.

[fernandojsg]

yep, you're right :\

[dmarcos]

We will have to explore soon what hints we have to add to the schema for the inspector: prompt? editable? The latter for those values that cannot be changed once they're set because they do irreversible operations. We could have an optional inspector object per property:

schema: {
    buffer: {default: true},
    mergeTo: {type: 'selector', inspector: {editable: false, prompt: true},
    primitive: {default: 'box', oneOf: geometryNames},
    skipCache: {default: false}
  },

[ngokevin]

At https://github.com/aframevr/aframe-registry/issues/22

[dmarcos]

We could even eventually let properties or components provide some customized UI that will embed in the editor. Imagine for instance a turbosquid component that prompts for the user credentials implements a model viewer / picker'