Aframe: Consolidate all component configuration in a single config object

[dmarcos]

In discussions over Slack about the need of adding a flag so some components tick / tock methods have a higher priority made me think. We now have dependencies and schema that turn into reserved words. The approach won't scale if we want to keep adding things like the flag mentioned before. We might want to consider consolidating all the fields in a single config object:
javascript AFRAME.registerComponent('my-component', { config: { dependencies: { ... }, schema: { ... }, priorityTick: true }, init: function () { ... }, update: function () {...}, tick: function () { ... } });

[wizgrav]

I also lean to the consolidation as it will future proof the api. On the other hand it breaks component with dependencies and may also conflict with anyone setting a config property of his own. Maybe you could call on all component writers to consult/prepare them

[dmarcos]

We can still take the old form and provide a warning message in console for a couple of versions before deprecating.

[dmarcos]

@donmccurdy @ngokevin what do you think?

[donmccurdy]

Offhand, I like the idea of having a config property, but I'm not sure dependencies and schema should be in it. They feel less like configuration, or at least schema does. Can we think of other properties that make sense? Some ideas:

• system name for components that are part of a multi-component system
• multiple could be moved into config.

[machenmusik]

really it's not the component configuration as much as the specification though, right? when I think of configuration, I think of configuration of an instance of the component (which for public properties is data)

[wizgrav]

@donmccurdy I think the point is to keep prototype pollution to a minimum. The property name could vary, for instance I was thinking of "meta" or something, but it doesn't really make a difference for me at least

[machenmusik]

sidebar - I don't think a Boolean priorityTick will suffice if we have enough complexity to require prioritization

[wizgrav]

@machenmusik you're right and it probably won't. I did this PR at some point https://github.com/aframevr/aframe/pull/1437 . I lean more for a simple solution right now though as it would cover present needs. If more is needed in the future it can be provisioned then on top of the flag which would have minimal impact

[wizgrav]

@donmccurdy if you mean being able to specify an alternative system for components, I'm also all in for that. It would make the effect components tidier

[machenmusik]

@wizgrav w.r.t. priorityTick -- if we're talking pre/post-processing, presumably those need ordered chains / graphs, and a Boolean can't represent any but the most trivial ordering - use a number at minimum, at which point you probably want to call it tickPriority - or maybe I misunderstand the use case

[wizgrav]

@machenmusik postprocessing is covered adequately as it is right now. Systems always run after components and there can be only one system that finally outputs to canvas. So there are two lanes of order (components then system) and that's good enough.

The use case for more prioritization would be to have a screenshot system that would always run after the post processing system to record the final frame

[machenmusik]

@wizgrav there you need to be able to specify ordering of systems right? e.g. this system needs to go after system X... Note that there is indeed a screenshot facility in A-Frame, is it not yet accommodated correctly?

[wizgrav]

@machenmusik the screenshot component basically redraws the scene on its own so it's not very efficient and no post processing. On its good side it can draw into cubemaps and do 360 video.

[ngokevin]

It sounds okay, but I don't think the prototype is much polluted at the moment, and it's not much work for developers to avoid reserved properties. It does sound like work to migrate the component ecosystem however. The whole component definition is sort of like a config in itself as well.

[dmarcos]

But as we add more properties it will harder to avoid the collisions. We have components already that add all sort of stuff like mapping , axisLabels or their own private methods.

[machenmusik]

maybe when/if we get around to deprecating primitives, this will be more palatable / necessary.
another option, of course, is to keep namespace flat but use a prefix to avoid collisions

[dmarcos]

Prefixes hurt my eyes. No please

[machenmusik]

(the traditional thing is to do something like underscore as prefix, not some further camelCase, but I agree that is somewhat less desirable)

[ngokevin]

It might be pre-emptive as that hasn't been an issue, and even as we add more properties, it's easy to avoid collisions. Also unlikely to hit those collisions as well. Just validate the component prototype and throw errors. A component is likely to try todefine config as the other names. Perhaps if we can batch it with other breaking changes in the future.

[machenmusik]

yeah I think config is maybe not the best choice, but something like meta, spec / specification, properties, definition would be much less likely to clash (and much more obvious a problem if it happened)

or something more readable like is or has

[donmccurdy]

It's hard to come up with a useful word that means "everything about the component that isn't a method". I was suggesting omitting at least schema from the config, because it feels conceptually different from primitive configuration values anyway (and something like tickPriority does really feel like configuration). I don't think finding a more ambiguous word is helpful — if there are meaningful ways to group properties let's do if; if not, I don't think this is a pressing issue yet.

For reference, here are Polymer's top-level properties: https://www.polymer-project.org/2.0/docs/api/#function-Polymer.Class

[cvan]

although it's not arguably better than just a config object namespace (which is what I'd suggest, in line with what most folks are as well) – just for the sake of evaluating other options, what about accepting a third argument for the config object?

AFRAME.registerComponent('my-component', {
 init: function () { ... },
 update: function () {...},
 tick: function () { ... }
}, {
  dependencies: { ... },
  schema: { ... }
});

if there are three arguments, use this format. if there are only two arguments, go with what @dmarcos said and continue to allow that format to work and print a console deprecation warning, keeping things backwards compatible until the release of the first A-Frame major version (1.0.0).

[ngokevin]

Going to wontfix. Don't think it's an issue for handlers / other stuff to be separated and will be slightly more difficult to remember if it goes within the root config or the inner config.