Adding an "API" property as an object to a DOM element as element.API

Question

I have a javascript framework that adds an API property to elements. It supplies an interface through this property.

<script type="javascript">
var $slider= document.getElementById('mySlider');

//this function inits a slider and adds API property o element
initMyFancySlider($slider);

//now I can access API
$slider.API.next();
$slider.API.play();
// etc...
<script>

This is not accomplished by extending any DOM prototype. The API property is directly linked on Element

<script type="javascript">
function  initMyFancySlider(element){
  //some staff

    Object.defineProperty(element, 'API', {
        enumerable: false,
        configurable: false,
        value: MyFancySliderManagerInstance.API;
    });
}
<script>

Some say adding properties to DOM elements is not a good practice. But I find it very useful for CMS type projects. Users can easily access API to customize an interface.

What is your point of view? Is there a better approach you can provide?

Just to make sure, in fact DOM element is not storing data, it just proxies to some API functionality. I know DOM elements are not for storing data or functionality. For instance $element.API.play() is just a method like $element.blur() . They are not related with data stored on element.

I don't see any performance overhead issue here. The only risk I can see here is element.API property may be used by DOM specification in the future. But i think it is a very low probability because no DOM properties are specified in uppercase. They always exist in camelCase (until now).

Thanks in advance.

This should be posted to https://codereview.stackexchange.com/ — palaѕн, Feb 22 '20 at 13:29
It's a design flaw at best. You shouldn't store your data to the DOM, nor your functional layer, there are JS data structures for these. The DOM is supposed to represent your data, not to store it. See also http://perfectionkills.com/whats-wrong-with-extending-the-dom/ , https://stackoverflow.com/a/3095584/1169519 — Teemu, Feb 22 '20 at 13:42
There's a ton of all-caps variable names in the DOM, mostly constants. It looks like you've already decided to extend the DOM in your app, so there's no use to trying to convince you the other way, the faster, easier to maintain, less error prone, independent, more secure way. — Teemu, Feb 22 '20 at 15:00
As an example, putting some of your logic to a global element, breaks the encapsulation of your code. The method in the element can easily be overwritten in the console, and make your API to do something you don't want it to do. Maybe it's not important in a slider case, but if you'll apply the same technique with some more important use cases, it may become very relevant. — Teemu, Feb 22 '20 at 15:16

score 0 · Accepted Answer · answered Feb 24 '20 at 08:31

In the end I gave up using this approach. Thanks for the comments.

I think it is better using "Youtube Iframe API" like approach.

<script type="javascript">
var $slider= document.getElementById('mySlider');    
let sliderInstance= new MFSlider.create($slider, {/*options*/});

sliderInstance.next();
sliderInstance.play();

// OR...

MFSlider.get('mySlider').next();
MFSlider.get('mySlider').play();

</script>

Adding an "API" property as an object to a DOM element as element.API

1 Answers1