У меня есть javascript инфраструктура, которая добавляет свойство API к элементам. Он предоставляет интерфейс через это свойство.
<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>
Это не достигается путем расширения любого прототипа DOM. Свойство API напрямую связано с элементом
<script type="javascript">
function initMyFancySlider(element){
//some staff
Object.defineProperty(element, 'API', {
enumerable: false,
configurable: false,
value: MyFancySliderManagerInstance.API;
});
}
<script>
Некоторые говорят, что добавление свойств к элементам DOM не является хорошей практикой. Но я нахожу это очень полезным для проектов типа CMS. Пользователи могут легко получить доступ к API для настройки интерфейса.
Какова ваша точка зрения? Есть ли лучший подход, который вы можете предложить?
Просто чтобы убедиться, что на самом деле элемент DOM не хранит данные, он просто прокси для некоторых функций API. Я знаю, что элементы DOM не предназначены для хранения данных или функциональности. Например, $element.API.play()
- это просто метод, подобный $element.blur()
. Они не связаны с данными, хранящимися в элементе.
Я не вижу здесь проблем с производительностью. Единственный риск, который я вижу здесь, это свойство element.API
, которое может быть использовано спецификацией DOM в будущем. Но я думаю, что это очень низкая вероятность, потому что никакие свойства DOM не указаны в верхнем регистре. Они всегда существуют в CamelCase (до сих пор).
Заранее спасибо.