feat(Vectorizer): add option to support camel case attributes

[kumilingus]

PR allows to use of both kebab-case and camel-case attribute names when setting/reading/removing attributes to/from SVGNodes.

vel.attr('strokeWidth', 2);
vel.attr({ strokeOpacity: 0.5, stroke: 'red' });
vel.removeAttr('strokeWidth');

The feature needs to be enabled with V.supportCamelCaseAttributes = true;.

[alexandernst]

Why not enabled it by default? 🤔 Maybe perf concerns?

[kumilingus]

Would not that be a breaking change? e.g. if someone used the camel case attributes on purpose.

vel.attr('myAttribute', 5); 
vel.node.getAttribute('myAttribute')  // => null

The plan is to release it as an experimental feature as part of the upcoming patch release.

[alexandernst]

But that change will be merged into v4, which will introduce breaking changes anyways, right? Or maybe I assumed (wrongly) that it will do so just because it's a major version?

[kumilingus]

No. It will be included in v3.7.6 (September).
Until v4.0 is released, you can enable it at your own risk.
In v4 we will enable it by default and publish a changelog, migration guide, and add type definition and documentation.

[zbynekstara]

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object#null-prototype_objects

Do we need to use a null-prototype object here? It can apparently lead to unexpected behavior, which may be problematic (e.g. if a customer tries to modify the list of attributes for which not to split camel-case).

I think we should be able to use a normal object here, since we are then using a Proxy object anyways to specify the custom getter (line 1444).

[kumilingus]

What problems specifically?

This:

V('rect', { toString: true }).node

Should produce:

<rect to-string="true"/>

And it would not if we define _attributeNames as {}.

[zbynekstara]

I'm not questioning that part, but my point is that the {} which would be used as a replacement would be a normal Object (i.e. with an Object prototype) - so if using that is okay, then it should be okay to say const _attributes = {} on this line by default, as well.

Examples of potential problems of using null-prototype objects according to the MDN link:

• An object with a null prototype can behave in unexpected ways, because it doesn't inherit any object methods from Object.prototype. This is especially true when debugging, since common object-property converting/detecting utility functions may generate errors, or lose information (especially if using silent error-traps that ignore errors).
• The main problem problem is with missing toString, valueOf, hasOwnProperty functions and the constructor property

[kumilingus]

Added a comment explaining why we use an object without prototype.
Note It's a private variable and can not be accessed from outside.