Подтвердить что ты не робот

Как написать многоразовый Javascript?

Я начал обматывать свои функции внутри объектов, например:

var Search = {
  carSearch: function(color) {
  },
  peopleSearch: function(name) {
  },
  ...
}

Это помогает с удобочитаемостью, но у меня все еще есть проблемы с повторной активацией. Чтобы быть более конкретным, сложность заключается в двух областях:

  • Получение параметров. Много раз у меня будет экран поиска с несколькими полями ввода и кнопкой, которая вызывает функцию поиска javascript. Я должен либо положить кучу кода в onclick кнопки для извлечения, а затем ввести в действие значения из полей ввода в вызове функции, или мне придется жестко кодировать имена/идентификаторы полей ввода HTML, чтобы впоследствии их можно было восстановить с Javascript. Решение, для которого я решил, заключается в передаче имен/идентификаторов полей в функцию, которые затем используются для извлечения значений из полей ввода. Это просто, но на самом деле кажется неправильным.

  • Возвращаемые значения. Эффект большинства вызовов Javascript имеет тенденцию быть тем, в котором некоторые визуальные эффекты на экране меняются напрямую или в результате другого действия, выполняемого в вызове. Повторное использование - это тост, когда я помещаю эти эффекты, изменяющие экран, в конце функции. Например, после завершения поиска мне нужно отобразить результаты на экране.

Как другие справляются с этими проблемами? Полагаю, что мой мыслящий колпачок наводит меня на мысль, что мне нужно иметь слой Javascript, специфичный для страницы, между каждым использованием в моем приложении и создаваемыми мной универсальными методами, которые будут использоваться в масштабах всего приложения. Используя предыдущий пример, у меня была бы кнопка поиска, чья onclick вызывает функцию myPageSpecificSearchFunction, в которой идентификаторы/имена полей поиска жестко закодированы, что упорядочивает параметры и вызывает функцию общего поиска. Общая функция возвращает только данные/объекты/переменные и не будет непосредственно читать или вносить какие-либо изменения в DOM. Функция поиска по конкретным страницам затем получит эти данные и соответствующим образом изменит DOM.

Есть ли я на правильном пути или есть лучший шаблон для обработки повторного использования объектов/методов Javascript?

4b9b3361

Ответ 1

Основная модель

С точки зрения вашего основного шаблона, могу ли я предложить модифицировать вашу структуру, чтобы использовать шаблон модуля и именованные функции:

var Search = (function(){
    var pubs = {};

    pubs.carSearch = carSearch;
    function carSearch(color) {
    }

    pubs.peopleSearch = peopleSearch;
    function peopleSearch(name) {
    }

    return pubs;
})();

Да, это выглядит сложнее, но отчасти потому, что здесь не задействована вспомогательная функция. Обратите внимание, что теперь у каждой функции есть имя (ваши предыдущие функции были анонимными; у свойств, с которыми они были связаны, были имена, а у функций - нет, что имеет значение с точки зрения отображения стека вызовов в отладчиках и т.д.). Использование шаблона модуля также дает вам возможность иметь полностью закрытые функции, к которым могут обращаться только функции в вашем объекте Search. (Просто объявите функции в большой анонимной функции и не добавляйте их в pubs.) Подробнее об этом я расскажу (с преимуществами и недостатками, а также с тем, почему вы не можете объединить объявление функции и назначение свойства) здесь.

Получение параметров

Одна из функций, которые мне действительно очень нравятся в Prototype, - это функция Form#serialize, которая проходит по элементам формы и создает простой объект со свойством для каждого поля на основе имени поля. (У прототипа - 1.6.1 - реализация имеет проблему, когда она не сохраняет порядок полей, но удивляет, как редко это становится проблемой.) Похоже, что вас это устроит, и они ' не трудно построить; тогда ваша бизнес-логика имеет дело с объектами со свойствами, названными в соответствии с тем, с чем они связаны, и не имеет представления о самой форме.

Возвращаемые значения/Смешивание пользовательского интерфейса и логики

Я склонен думать о приложениях как об объектах, а также о связях и взаимодействиях между ними. Поэтому я склонен создавать:

  • Объекты, представляющие бизнес-модель и тому подобное, независимо от интерфейса (хотя, конечно, бизнес-модель почти наверняка частично управляется интерфейсом). Эти объекты определены в одном месте, но используются как client-, так и на стороне сервера (да, я использую JavaScript на стороне сервера) и разработаны с учетом сериализации (в моем случае, через JSON), чтобы я мог отправить их обратно и вперед легко.
  • Объекты на стороне сервера, которые знают, как использовать их для обновления основного хранилища (поскольку я склонен работать над проектами с базовым хранилищем), и
  • Сторона объектов client-, которая знает, как использовать эту информацию для визуализации в пользовательском интерфейсе.

(Я знаю, вряд ли оригинально!) Я пытаюсь сохранить хранилище и рендеринг объектов, чтобы они в основном работали, просматривая общедоступные свойства бизнес-объектов (в основном это все свойства; я не использую такие шаблоны, как Крокфорд, который позволяет вам действительно скрывать данные, я считаю их слишком дорогими). Прагматизм означает, что иногда хранилище или объекты рендеринга просто должны знать, с чем они имеют дело, в частности, но я стараюсь держать вещи по-своему, где могу.

Ответ 2

Javascript является смехотворно гибким, что означает, что ваш дизайн особенно важен, поскольку вы можете делать все по-разному. Это то, что, вероятно, делает Javascript менее похожим на возможность повторного использования.

Существует несколько различных обозначений для объявления ваших объектов (функций/классов), а затем их имен. Важно понимать эти различия. Как упоминалось в комментарии здесь, "namespacing - это легкий ветерок" - и это хорошее место для начала.

Я не смог бы зайти достаточно далеко в этом ответе и только перефразировать, поэтому я рекомендую покупать эти книги:

Шаблоны проектирования JavaScript

Про Javascript-методы

Ответ 3

Я начал использовать шаблон модуля, но затем начал делать все в jQuery. Плагины позволяют передавать параметры страницы.

Использование jQuery также позволит вам переосмыслить то, как вы определяете условия поиска и находите их значения. Вы можете подумать о добавлении класса к каждому входу и использовать этот класс, чтобы избежать однозначного обозначения каждого входа.