대규모 backbone.js 웹 앱 조직

대규모 backbone.js 웹 앱 조직

---

저는 현재 backbone.js를 기반으로 구축 된 대규모 웹 앱을 작업 중이며 조직, "좀비"등과 관련하여 많은 문제를 겪고 있으므로 코드의 주요 리팩터링을 수행하기로 결정했습니다. 나는 이미 "좀비"를 처리하기위한 많은 도우미 함수를 작성했습니다. 그러나 처음부터 시작하여 코드에 대한 멋진 구조 / 조직을 만들고 싶습니다. 대규모 backbone.js 조직에 대한 훌륭한 튜토리얼 / 예제를 많이 찾지 못했기 때문에 처음부터 시작했고 어디에서 시작했는지에 대한 의견을 얻을 수 있는지보고 싶습니다.

분명히 글로벌 네임 스페이스 내에 코드를 설정했습니다. 하지만 그 네임 스페이스를 깔끔하게 유지하고 싶습니다. 내 주 app.js는 클래스 파일 자체를 전역 네임 스페이스와 별도로 유지합니다. reg () 함수를 사용하여 클래스를 등록 할 수 있으며 (인스턴스화 할 수 있도록) inst () 함수는 클래스 배열에서 클래스를 인스턴스화합니다. 따라서 세 가지 메서드 외에 MyApp 네임 스페이스에는 Router, Model 및 View 만 있습니다.

var MyApp = (function () {

    var classes = {
        Routers: {},
        Collections: {},
        Models: {},
        Views: {}
    };

    methods = {

        init: function () {
            MyApp.Router = MyApp.inst('Routers', 'App');
            MyApp.Model = MyApp.inst('Models', 'App');
            MyApp.View = MyApp.inst('Views', 'App');
            Backbone.history.start();
        },

        reg: function (type, name, C) {
            classes[type][name] = C;
        },

        inst: function (type, C, attrs) {
            return new classes[type][C](attrs || {});
        }

    };

    return methods;

}());

$(MyApp.init);

Models, Collections, Routers 및 Views 내에서 평소처럼 작업하지만 파일 끝에 해당 클래스를 등록하여 나중에 (네임 스페이스를 복잡하게하지 않고) 인스턴스화 할 수 있도록해야합니다.

MyApp.reg('Models', 'App', Model);

이것이 코드를 구성하는 불필요한 방법처럼 보입니까? 다른 사람들이 많은 라우터, 컬렉션, 모델 및 뷰로 정말 큰 프로젝트를 구성하는 방법에 대한 더 나은 예를 가지고 있습니까?

---

저는 최근에 GapVis라는 백본 프로젝트에서 작업했습니다 ( 여기 에 코드, 여기 에 콘텐츠 렌더링 ). "정말로 큰지"는 모르겠지만, 크기가 크고 비교적 복잡합니다. 24 개의 뷰 클래스, 5 개의 라우터 등 모든 접근 방식이 다음과 같을지는 모르겠지만 살펴볼 가치가 있습니다. 관련된. 내 주요 app.js 파일 의 긴 소개 주석에서 내 생각 중 일부를 볼 수 있습니다 . 몇 가지 주요 아키텍처 선택 :

• State현재보기, 우리가보고있는 모델 ID 등 모든 현재 상태 정보를 보유 하는 싱글 톤 모델이 있습니다. 애플리케이션 상태를 수정해야하는 모든보기는에 속성을 설정 State하여 수행하고 응답해야하는 모든보기를 수행합니다. 상태는 해당 모델에서 이벤트를 수신합니다. 이는 상태 및 업데이트를 수정하는 뷰의 경우에도 마찬가지입니다. UI 이벤트 핸들러 events는 뷰를 다시 렌더링하지 않으며 대신 렌더링 함수를 상태에 바인딩하여 수행됩니다. 이 패턴은 뷰를 서로 분리하는 데 정말 도움이되었습니다. 뷰는 다른 뷰에서 메소드를 호출하지 않습니다.

• 내 라우터는 특수 뷰처럼 취급됩니다. 상태를 업데이트하여 UI 이벤트 (예 : URL 입력)에 응답하고 UI를 업데이트 (예 : URL 변경)하여 상태 변경에 응답합니다.

• 나는 당신이 제안하는 것과 비슷한 몇 가지를합니다. 내 네임 스페이스에는 init당신과 비슷한 기능과 settings상수를 위한 객체가 있습니다. 그러나 여러 파일에서 참조해야했기 때문에 대부분의 모델과 뷰 클래스를 네임 스페이스에 넣었습니다.

• 라우터에 등록 시스템을 사용하고 "마스터"클래스 ( AppRouter및 AppView)가 모든 뷰를 인식 하지 못하도록하는 좋은 방법으로 내 뷰에 대해 하나를 고려했습니다 . 하지만이 AppView경우에는 자식 뷰의 순서가 중요하다는 것이 밝혀 졌기 때문에 이러한 클래스를 하드 코딩했습니다.

나는 이것이 일을하는 "올바른"방법이라고 거의 말하지 않았지만 그것은 나를 위해 일했다. 도움이 되었기를 바랍니다. Backbone을 사용하는 대규모 프로젝트의 가시적 소스 예제를 찾는 데 어려움이 있었으며 진행하면서이 대부분을 해결해야했습니다.

---

이 두 가지 리소스는 견고한 지하실에 백본 앱을 설정하는 데 도움이되었습니다.

• https://github.com/tbranyen/backbone-boilerplate
• http://ricostacruz.com/backbone-patterns/#namespace_convention

---

나는 당신이하고있는 일과 비슷한 네임 스페이스 (적어도 클래스 부분의 경우)와 내 모든 모델, 뷰 및 컨트롤러는 다음과 같습니다.

views / blocks.js :

(function(cn){
    cn.classes.views.blocks = cn.classes.views.base.extend({

        events: {},

        blocksTemplate: cn.helpers.loadTemplate('tmpl_page_blocks'),

        initialize: function(){
        },

        render: function(){
            $(this.el).html(this.blocksTemplate());
        },

        registerEvents: function(){},
        unregisterEvents: function(){}
    });
})(companyname);

내 JavaScript 네임 스페이스는 다음과 같지만 새 앱을 빌드 할 때마다 개선합니다.

 companyname:{                                                                                                                                                                                 
   $: function(){},      <== Shortcut reference to document.getElementById                                                                                                                      
   appView: {},          <== Reference to instantiated AppView class.                                                                                                                           
   classes = {           <== Namespace for all custom Backbone classes.                                                                                                                         
     views : {},                                                                                                                                                                                
     models : {},                                                                                                                                                                               
     collections: {},                                                                                                                                                                           
     controllers : {},                                                                                                                                                                          
     Router: null                                                                                                                                                                               
   },                                                                                                                                                                                           
   models: {},          <== Instantiated models.                                                                                                                                                
   controllers: {},     <== Instantiated controllers.                                                                                                                                           
   router: {},          <== Instantiated routers.                                                                                                                                               
   helpers: {},         <== Reusable helper platform methods.                                                                                                                                   
   currentView: {},     <== A reference to the current view so that we can destroy it.                                                                                                          
   init: function(){}   <== Bootstrap code, starts the app.                                                                                                                           
 } 

Anything I want all my views to have, I put in the base view. My controller will call registerEvents on any new view it creates (after render) and unregisterEvents on a view right before it kills it. Not all views have these two extra methods so it first checks for the existence.

Don't forget that all views come with a this.el.remove(); built in. Which not only kills the views container element but unbinds all events attached to it. Depending on how you are creating your views through your controller you may not actually want to kill the element and do this.el.unbind() instead to unbind all events.

---

In fact, in different ways have advantages and disadvantages of different ways.The most important thing is to find a suitable way of organizing files.The following is the organization of the project I am currently doing. This way the focus will be the same module-related files are placed in a folder. For example: the people module, this module all files are placed in modules / base / people directory. After updating and maintenance of this module, only need to focus on the files in this directory on the line, will not affect files outside the directory, and improved maintainability.

I hope my answer can give you some help, I hope you some valuable advice.

참고URL : https://stackoverflow.com/questions/8002828/large-backbone-js-web-app-organization