Лучшая практика Backbone.js для именования обработчиков событий

Ответ 1

Я лично предпочитаю использовать имена onEventName, поддерживающие традиционное соглашение об именах для обработчиков событий DOM.

Как myElement.onclick = function() { /* ... */ } для события click.

Итак, для myEvent Я использую обработчик с именем onMyEvent.

И если у меня есть событие stateChange, я буду использовать обработчик onStateChange.

Но на самом деле этот вопрос более конкретен для каждой команды разработчиков и соглашений о стиле кода внутри команды/компании.

Таким образом, главная цель в таких вопросах - сохранить стиль кода одинаковым во всех частях, чтобы обеспечить читаемость.

Поэтому, если вы работаете в команде, просто придерживайтесь правил написания командного кода, и если вы работаете в одиночку в существующем коде, попробуйте сохранить его стиль кода (конечно, если этот стиль не является явно уродливым).

ОБНОВЛЕНИЕ: Понимание.

Что такое событие? Примерно это действие инициируется снаружи или внутри программы, другими словами, что-то происходит в системе, например. некоторые изменения состояния (состояние клавиатуры, мыши, устройств ввода-вывода и т.д.) не имеет значения, как (пользователь щелкнул мышью или какая-то программа отправила сигнал мыши в систему).

Скажите, что окно браузера подписано на получение уведомлений о некоторых событиях и операционную систему, отправляющих их ему как можно скорее, мы предположим, что в то же время, когда что-то происходит. Поэтому, если пользователь нажимает на мышь, когда окно браузера активно, а документ имеет фокус, браузер говорит документу, чтобы запустить событие click. И здесь наш обработчик onclick начинает свой вызов. Другими словами, система говорит нам, что теперь происходит изменение состояния. И мы обрабатываем это изменение и не обрабатываем факт, говорящий о том, что состояние было изменено.

Предположим, что наш обработчик назван onClicked.. Поскольку имя обработчика говорит в прошедшем времени, мы можем получить разумный вопрос: "Когда щелкнули, как давно это произошло? Сколько раз это щелкнули? Хм, может быть, слишком поздно справляться с этим действием (или действиями?) вообще...". Итак, это имя говорит нам, что что-то случилось где-то в прошлом.

В отличие от нашего обработчика, названного onclick, очевидно, что событие click только что было запущено и выпущено один раз, и мы были немедленно уведомлены об этом. И мы обрабатываем событие click - информацию о том, что состояние мыши изменилось прямо сейчас (не мышь нажал, но событие щелчка).

Таким образом, имена в прошедшем времени более подходят для случаев, когда нам нужно проверить, было ли какое-то состояние изменено или нет. Например. если переменная хранит state = 1, мы можем вызвать функцию isStateChanged();, которая будет сравнивать значение в переменной state с реальным значением в текущий момент. И вот прошедшее время - хороший выбор для именования.

Ответ 2

onStateChanged, потому что эта функция запускается всякий раз, когда изменяется какое-то состояние.

Ответ 3

Я просмотрел несколько имен и отметил количество полученных результатов. Вы можете получить некоторые сведения об относительной популярности наиболее распространенных форм для обработчиков событий:

stateChanged 168k
stateChange 81k [1] 
handleStateChange 61k
onStateChange 59k 
onStateChanged 12k 
beforeStateChange 2k

[1] Результаты показывают, что stateChange используется в основном как имя события, а не обработчик.

Использование разных типов событий дает гораздо более сильную рекомендацию по форме onStateChange:

change [2]
onChange 2000k
onChanged 85k
handleChange 36k
beforeChange 27k
afterChange 22k

click [2]
onClick 48000k
onClicked 58k
handleClick 50k
beforeClick 8k [3]

onDrag 100k
handleDrag 36k
beforeDrag 32k
afterDrag 4k
onDragged 5k

[2] Слишком много результатов, не связанных с программированием.

[3] Очевидно, что определенный API Microsoft может предвидеть, когда пользователь нажимает.

Ответ 4

Моя ставка для stateChanged из-за:

• stateChange выглядит как порядок и выглядит так: он получает параметр с новым состоянием.
• onStateChange и onStateChanged - больше ключей для хранения обработчиков, а не имени самого обработчика.

ИМХО

Ответ 5

Обычно я использую имя события с 2 факторами. Поскольку приложение растет в размерах, у вас может быть несколько объектов, которые заявляют об изменениях или, возможно, контроллер, который может транслировать события изменения для нескольких объектов, и поэтому хотел бы иметь возможность различать между ними как в коде, так и в голове:

Object1:event
Object2:event

Что касается имени события, я думаю, что это сводится к личным предпочтениям и последовательности.

Ответ 6

Я думаю, что нужно сделать разницу в зависимости от фактического момента, когда действие происходит. Для меня onStateChange означает, что он в настоящее время меняется, и я могу быть уведомлен об этом с технической точки зрения прямо перед изменением. OnStateChanged означает, что действие уже произошло, и я получил уведомление в конце его.

Итак, между onStateChange и onStateChanged существует важная разница в намерениях. Сначала говорится: "Подготовьтесь к этому изменению", а второй говорит "это уже произошло".

Изменить: меня увлекло намерение и не осознал самого имени. Почему префикс? Это зарезервировано для обработчиков. Обработчики будут делать что-то, связанное с этим событием. Поэтому я бы пошел с stateChange и stateChanged.