我在做什麼:使用Ember.js,處理鍵盤事件的一些常見模式是什麼?
想象一下,在瀏覽器中有一個div數組,div可以根據用戶請求進行實例化或刪除。 按下左箭頭或右箭頭鍵時,div應向左或向右移動。
我現在的(製作的很差)解決方案:
事件處理和委託:
function onDocumentKeyDown(event){
switch (event.keyCode){
case 37: App.objectsView.scrollLeft(); break;
case 39: App.objectsView.scrollRight(); break;
}
}
// add event listener to document
function addEventListeners() {
document.addEventListener('keydown', onDocumentKeyDown, false);
}
addEventListeners();
應用程序容器視圖:
App.objectsView = Ember.ContainerView.create({
childViews: [],
// CRUD stuff
createView: function(){ ... },
deleteView: function(){ ... },
updateView: function(){ ... },
// navigation stuff
scrollRight: function(){
this.scroll('right')
},
scrollLeft: function(){
this.scroll('left')
},
scroll: function(direction){
this.get('childViews').forEach(function(key){
var object = key;
object.move(direction);
}, this)
},
});
應用視圖類(完整性,並不是真的那麼相關):
App.ObjectView = Ember.View.extend(Animation, {
...
move: function(param){ ... }
});
*請注意,大多數dom選擇和更改css屬性邏輯通過動畫混入進入視圖。
正如你可以看到,我真的不喜歡這個實現,因爲:
每個鍵事件勢必在容器視圖中的特定功能,如果我想關鍵的37什麼做一件事在某些情況下和其他情況下的其他情況(例如鼠標箭頭所在的位置)?
onDocumentKeyDown函數被添加到文檔中,我不能完全說出原因,但它看起來令人不安。
ObjectsView同時具有管理實例化和事件委派的邏輯。 Ember中的containerView甚至意味着處理導航邏輯嗎? (我可以將它們分成兩個不同的功能,但如果事件的處理方式相同,那麼它們似乎是道德上相同的解決方案)。
是否有灰燼的是通過某種單一實例中樞的處理關鍵事件的任何常用的模式,或只是任何JS MV *框架,然後傳播到每個應用程序狀態的系統的其他部分?而這個Ember路由器的概念,不知何故在這裏適合嗎?
謝謝!