Тъй като току-що говорихме за събития, сега е подходящ момент да споменем персонализирани събития. Всички събития, за които говорихме досега, са „реални“ събития, така да се каже. Събития, които произхождат от DOM въз основа на реални неща, които се случват, като щракване или натискане на клавиш. Тези събития могат да бъдат „задействани“ изкуствено в jQuery. Например, за да „фалшифицирате“ едно щракване върху бутон, можете да направите:
$("#some-button").trigger("click");Тогава всички манипулатори на кликвания, свързани с този бутон, ще се задействат, сякаш потребител наистина е щракнал върху този бутон. Но какво, ако го направихме:
$("#some-button").trigger("dance");Какво става тогава? „Танц“ не е „истинско“ събитие. Но грешка няма да бъде хвърлена. Случва се, че вероятно няма „танцови“ манипулатори, обвързани с този бутон. Но може да има и по същество това е събитие по поръчка. Събитие с име, което просто измисляте.
Защо направи това? Предимно организационни причини. Може би искате да отделите вашия JavaScript, който обработва събития и действия, и вашия JavaScript, който обработва данни и административни неща. Това е много разумно. Ако този бутон беше бутон „Запазване на настройките“, можете просто да задействате персонализирано събитие, наречено „save-settings“, а другаде да имате манипулатор, който чака това събитие да се задейства и реално запазва данните. По същество това направихме в примера от видеото.
Друг случай на употреба за персонализирани събития е създаването на общи компоненти на потребителския интерфейс. Говоря за това в тази публикация в блога.
Може би създавате ефект на акордеон като UI компонент. Акордеонът прави това, на което всички акордеони, отваря и затваря панелите при щраквания / кранове. Вашият UI компонент прави това много добре. Сега разработчик, който използва този акордеон, може да има специални и уникални неща, които искат да се случат с него. Кажете, че използват акордеона за настройки на акаунта и когато потребителят затвори панел, иска да запази данните от елементите на формуляра в този панел. Традиционен модел може да бъде авторът на този компонент на потребителския интерфейс на акордеон да предлага функции за обратно извикване, когато това действие се случи. Когато инициализирате акордеона, предавате функции за обратно извикване, които искате да бъдат извикани, когато тези неща се случат. Това е един път за слизане. Друг път би бил акордеонът автоматично да изстрелва персонализирани събития за всички съответни действия, които прави.Когато този панел се затвори, той може да изстреля apanelClosedсъбитие на самия елемент на акордеон. Тогава разработчиците, работещи с него, биха могли просто да се обвържат с тези събития. Това е просто още един път, по който можете да тръгнете по организационни причини, който може да бъде доста елегантен.