Конструктор обёртки DOM-элементов и возвращаемые значения

[Octane]

Допустим есть такой конструктор обёртки, который ищет элемент по идентификатору:

function $(…) {
    if (this.constructor != $) {
        return new $(…);
    }
    …
    this.node = …;
    …
    return …;
}

Используем:

var obj = $(…);

Вот как будет лучше, чтобы вел себя этот конструктор:

obj → {node: Element} или null

или

obj → {node: Element или null}

?

В первом случае удобнее выполнять проверки:

if ($("#id")) { … }

Но если написать так:

var obj = new $("id");

то не логично в результате получать null, в случае, когда элемент не найден?

[Kolyaj]

то не логично в результате получать null, в случае, когда элемент не найден?

Да вроде логично, элемента же нет.

[Octane]

Просто в результате выражения с оператором new, ожидается получить объект, а тут вдруг еще и null появляется. Хотя мне этот вариант больше нравится, да и typeof null по счастливой случайности везде выдает "object", но будет ли он удобен для других программистов? Может еще есть какие-то достоинства и недостатки у вариантов:

$(…) → {node: Element} или null
$(…) → {node: Element или null}

Это еще для того, чтобы не было мертвых цепочек, как в jQuery:

$("#id-которого-нет-на-странице").method1(…).method2(…).method3(…) // нет ошибок

[Dmitry A. Soshnikov]

Просто в результате выражения с оператором new, ожидается получить объект, а тут вдруг еще и null появляется.

Вообще, функция-конструктор (когда на последнем этапе вызывается, как инициализатор) может запросто что-то вернуть. И именно это "что-то" и будет результатом new (вновь созданный объект, в свою очередь, просто удалиться, т.к. ссылок на него не будет). Поэтому с точки зрения алгоритма, нарушений нет, если вернуть null. Разве что, "страдает" интуитивно-ожидаемый результат. Но, это дело привычки и знания/не знания, что new не обязательно должен возвращать вновь созданный объект.

Этот "сахар" с new часто используют в обёртках для классов, типа:

var MyClass = new Class({...});

где new - что есть, что нет - так, для красоты и интуитивно-ожидаемого результата.

С другой стороны, "мёртвые цепочки" в jQuery, выглядят ещё менее интуитивно. Действительно, если объект не найден - его нет, и обёртка - ни к чему. Хотя, это только моё мнение.

[Octane]

Значит всем нравится вариант:

$(…) → {node: Element} или null
new $(…) → {node: Element} или null

Хорошо так и сделаю.


Еще вопрос, как лучше этот Element в документации записывать/называть и вообще эту обёртку {node: Element} записывать? Cейчас на объявление переменной node типа Element больше похоже, как в Delphi

[Kolyaj]

Octane,
а тебя не смущает, что для использования кастомных методов нужно будет писать el.method(), а для нативных -- el.node.method()?

[Octane]

А как по другому цепочки строить? Если ты имеешь ввиду этот пример, то там тоже не все хорошо, в IE экземпляр $(Element) и this→Element будут иметь разный набор методов. А еще повсеместный apply снизит производительность.

[Kolyaj]

А как по другому цепочки строить?

Ну лично меня цепочки не втыкают. И я именно из-за разности типов методов отказался от этого подхода.

[Octane]

Сообщение от Zeroglif

Как можно не любить Джикверицепочки? Вы с какой планеты?

исходное сообщение

Ну а если серьезно, то мне кажется удобным применение/построение цепочек, несмотря на этот недостаток.

Такие вещи:

$(document.body).append("div").text("…");

делают код более читабельным

[Dmitry A. Soshnikov]

Как можно не любить Джикверицепочки? Вы с какой планеты?

Ну, это, вряд ли, новаторство jQuery. Но стилистика удобная, цепь "событий" над объектом.