מתי קליק לא נחשב ל-click? למפתחי אינטרנט שעובדים על ממשק משתמש מורכב, זו לא שאלה פילוסופית מופשטת. אם אתם מטמיעים התנהגות מותאמת אישית של קלט מהעכבר, חשוב לזכור את כוונת המשתמש. לדוגמה, אם משתמש לוחץ על קישור באמצעות הלחצן האמצעי של העכבר, סביר להניח שהוא רצה לפתוח כרטיסייה חדשה עם התוכן של הקישור הזה. אם משתמש לוחץ על לחצן הביניים על אלמנט UI אקראי, מומלץ להניח שמדובר בטעות ולהתעלם מהקלט הזה. לעומת זאת, לחיצה על לחצן ראשי אמורה להפעיל תגובה מממשק המשתמש.
אפשר ליצור מודל של האינטראקציות המעודנות האלה באמצעות מאזין אירועים יחיד של click, אבל זה קצת מסורבל. תצטרכו לבדוק באופן מפורש את המאפיין button של MouseEvent כדי לראות אם הוא הוגדר לערך 0, שמייצג את הלחצן הראשי, או לערך אחר. בדרך כלל, הערך 1 מייצג את הלחצן האמצעי וכן הלאה. אבל לא הרבה מפתחים מגיעים עד כדי בדיקה מפורשת של המאפיין button, וכתוצאה מכך הקוד מטפל בכל הערכים של click באופן זהה, ללא קשר ללחצן שנלחץ.
החל מגרסה 55 של Chrome, אירוע מסוג חדש של MouseEvent, שנקרא auxclick, מופעל בתגובה לכל קליקים שמתבצעים באמצעות לחצן לא ראשי. לצד האירוע החדש הזה, יש שינוי תואם בהתנהגות של האירוע click: הוא יופעל רק כשלוחצים על הלחצן הראשי של העכבר. אנחנו מקווים שהשינויים האלה יאפשרו למפתחי אתרים לכתוב בקלות רבה יותר פונקציות טיפול באירועים שתגובה רק לסוג הקליקים שחשוב להם, בלי צורך לבדוק באופן ספציפי את המאפיין MouseEvent.button.
הפחתת מספר התוצאות החיוביות השגויות
כפי שצוין, אחד מהמניעים ליצירת auxclick היה למנוע פריסה של בוררים מותאמים אישית של click שמבטלים בטעות את ההתנהגות 'קליק בלחצן האמצעי פותח כרטיסייה'. לדוגמה, נניח שכתבתם בורר אירועים של click שמשתמש ב-History API כדי לכתוב מחדש את סרגל המיקום, ולהטמיע ניווטים מותאמים אישית בדף יחיד. זה יכול להיראות כך:
document.querySelector('#my-link').addEventListener('click', event => {
event.preventDefault();
// ...call history.pushState(), use client-side rendering, etc....
});
יכול להיות שהלוגיקה בהתאמה אישית תפעל כמצופה כשהיא מופעלת על ידי הלחצן הראשי של העכבר, אבל אם הקוד הזה פועל כשמקישים על הלחצן האמצעי, מדובר למעשה בזיהוי חיובי שגוי. לפני שההתנהגות החדשה תופעל, הפעולה שתתבצע כברירת מחדל תהיה מניעת פתיחת כרטיסייה חדשה, בניגוד לציפיות של המשתמשים.
אפשר לבדוק באופן מפורש אם הערך של event.button === 0 הוא true בתחילת הטיפול בבקשה, ולהריץ את הקוד רק אם זה המצב. עם זאת, קל לשכוח לעשות זאת, או לא להבין בכלל שצריך לעשות זאת.
מריצים רק את הקוד הנדרש
הצד השני של המטבע הוא שכאשר יש פחות תוצאות חיוביות שגויות, פונקציות ה-callbacks של auxclick יפעלו רק כשלוחצים בפועל על לחצן עכבר שאינו ראשי. אם יש לכם קוד שצריך, לדוגמה, לחשב כתובת URL מתאימה ליעד לפני פתיחת כרטיסייה חדשה, תוכלו להאזין ל-auxclick ולכלול את הלוגיקה הזו ב-callback. הוא לא יגרום לעומס העל של הפעלה כשלוחצים על לחצן העכבר הראשי.
תמיכה ותאימות לדפדפנים
בשלב זה, ההתנהגות החדשה הזו מוטמעת רק ב-Chrome 55. כפי שצוין בהצעה הראשונית, אנחנו מקבלים בברכה משוב (חיובי ושלילי) מקהילת מפתחי האינטרנט. הדרך הטובה ביותר לשתף את המשוב הזה עם האנשים שעובדים על תהליך התקינה היא לשלוח בקשה בנושא ב-GitHub.
בינתיים, המפתחים לא צריכים להמתין עד ש-auxclick יהיה זמין באופן נרחב כדי לפעול לפי כמה שיטות מומלצות לטיפול באירועי עכבר. אם תבדקו את הערך של המאפיין MouseEvent.button בתחילת הטיפול באירוע click, תוכלו לוודא שתבצעו את הפעולה המתאימה. התבנית הבאה תעבד קליקים ראשיים וקליקים משניים באופן שונה, גם אם יש תמיכה מובנית ב-auxclick וגם אם לא:
function handlePrimaryClick(event) {
// ...code to handle the primary button click...
}
function handleAuxClick(event) {
// ...code to handle the auxiliary button click….
}
document.querySelector('#my-link').addEventListener('click', event => {
if (event.button === 0) {
return handlePrimaryClick(event);
}
// This provides fallback behavior in browsers without auxclick.
return handleAuxClick(event);
});
// Explicitly listen for auxclick in browsers that support it.
document.querySelector('#my-link').addEventListener('auxclick', handleAuxClick);