항상 내 viewmodel을 수행하는 데 사용하여 Knockout 매핑 플러그인을 과도하게 사용하고 있습니까?

항상 내 viewmodel을 수행하는 데 사용하여 Knockout 매핑 플러그인을 과도하게 사용하고 있습니까?

---

나는 여전히 Knockout의 적절한 사용법을 배우고 있으며 ko.observable내 뷰 모델을 설정할 때 타이핑에서 빨리 벗어나고 대신 객체 리터럴을 정의하고 다음과 같은 매핑 플러그인을 통해 전달하는 것을 발견했습니다.

var viewModel = ko.mapping.fromJS(data);

또는 최소한 내 모든 데이터를 viewModel의 속성에 채우는 라인을 따라

var viewModel = { 
    ... events etc ... , 
    "data": ko.mapping.fromJS(data)
}

솔직히 제가이 일을해온 주된 이유는 타이핑 ko.observable하고 ko.observableArray반복적으로 돌아 다니는 것 입니다. 나는 이것이 좋은 접근 방식인지 그리고 특정 var x = ko.observable()선언을 모두 함께 삭제하는 데 단점이 있는지 알아 내려고 노력하고 있습니다. 또한이 모든 작업을로드시 수행하고 있으며, 아약스 호출 등에 대한 응답이 아닌 매핑 ​​플러그인이 설계된 용도입니다.

녹아웃 작업에서 여전히 Observable을 하나씩 수동으로 선언합니까, 아니면 내가 사용하는 mapping.fromJS 메서드를 사용 했습니까? 이와 같이 자주 매핑 플러그인을 사용하는 데 특별한 단점이 있습니까?

편집하다:

구체적인 예

이 기사 에서 Steve는 다음을 수행하여 viewModel을 설정합니다.

var initialData = [ { ... } , { ... } ]; // json from the serializer
var viewModel = {
    gifts : ko.observableArray(initialData)
};

일반적으로 저는 ko.mapping.fromJS이 상황에서도 사용합니다. 특히 배열 내의 객체가 관찰 가능 항목으로 전환되는지 확인하기 위해 사용합니다. 그가 한 일을 살펴보면 내 접근 방식은 과도한 것처럼 보이며 약간의 불필요한 오버 헤드를 추가합니다.

---

내 제안은 방금 https://stackoverflow.com/questions/7499133/mapping-deeply-hierarchical-objects-to-custom-classes-using-knockout-mapping-plug 에서 답변 한 다른 질문과 동일 합니다.

매핑 플러그인을 사용하는 이유는 합리적이고 내가 사용하는 이유입니다. 필요한 것보다 더 많은 코드를 입력하는 이유는 무엇입니까?

녹아웃 (4 개월 모두)에 대한 경험상, 수동으로하는 작업을 줄이고 녹아웃 루틴이 작업을 수행하도록할수록 내 앱이 더 잘 실행되는 것처럼 보입니다. 내 제안은 가장 간단한 방법을 먼저 시도하는 것입니다. 요구 사항을 충족하지 못하는 경우 간단한 접근 방식이 "사건"인지 살펴보고 요구 사항을 충족하기 위해 변경해야 할 사항을 결정합니다.

---

Knockout을 조금 더 사용한 후, 매핑 플러그인에 매핑 프로세스를 훨씬 더 세밀하게 제어 할 수있는 몇 가지 추가 옵션이 있음을 알게되었습니다.

생성되는 속성의 유형 및 양을 제어합니다.

이를 수행하는 방법에는 여러 가지가 있으며 몇 가지를 살펴 보 겠지만 최종 결과는 모든 것이 관찰되지 않기 때문에 매핑 플러그인에서 더 가벼운 결과를 얻게되는 것입니다.

기본적으로 변경되지 않을 것이라고 생각하는 모든 것을 정상적인 속성으로 남겨두고 관찰하려는 특정 항목에서만 관찰 가능 항목을 만듭니다.

확인 mapping을 생략 특정 속성을

당신은 같은 일을 지정하여 완전히 최종 결과에서 생략 속성 플러그인 매핑을 만들 수 있습니다 ignore또는 include. 이 두 가지 모두 반대 방식으로 동일한 작업을 수행합니다.

참고 : 샘플은 knockout.js 매핑 플러그인 문서 에서 가져온 것입니다.

매핑 플러그인 인수 : include

다음 스 니펫은 인수 를 통해 전달 된 속성 을 제외한 소스 개체의 모든 속성 을 생략합니다include .

// specify the specific properties to include as observables in the end result 
var mapping = {
    // only include these two properties
    'include': ["propertyToInclude", "alsoIncludeThis"]
}

// viewModel will now only contain the two properties listed above, 
//    and they will be observable
var viewModel = ko.mapping.fromJS(data, mapping);

매핑 플러그인 인수 : ignore

소스 객체에서 특정 속성 만 생략 하려면 ignore아래와 같이 인수를 사용하십시오 . 지정된 속성을 제외하고 소스 개체의 모든 속성에서 관찰 가능 항목을 만듭니다.

// specify the specific properties to omit from the result, 
//    all others will be made observable
var mapping = {
    // only ignore these two properties
    'ignore': ["propertyToIgnore", "alsoIgnoreThis"]
}

// viewModel will now omit the two properties listed above, 
//    everything else will be included and they will be an observable
var viewModel = ko.mapping.fromJS(data, mapping);

어떤 속성이 관찰 가능한지 여부를 제어

속성을 포함해야하지만 (어떤 이유로 든) 관찰 가능하게 만들 필요가 없다고 생각하는 경우 매핑 플러그인에 도움이 될 수있는 것이 있습니다.

매핑 플러그인 인수 : copy

매핑 플러그인이 일반 속성을 단순히 복사하고 관찰 할 수 없게하려면이 인수를 사용하십시오.

// tell the mapping plugin to handle all other properties normally, 
//    but to simply copy this property instead of making it observable
var mapping = {
    'copy': ["propertyToCopy"]
}
var viewModel = ko.mapping.fromJS(data, mapping);

매핑 프로세스를 완벽하게 제어

객체에 클로저 및 구독을 넣는 기능을 포함 하여 매핑 프로세스에서 생성되는 내용을 100 % 제어 하려면 "만들기"옵션을 사용합니다.

계산 된 속성이있는 일반 결과

다음은 results속성이 있는 객체로 ajax 호출의 데이터를 매핑하는 예 입니다. 나는 관찰 할 수있는 어떤 것도 원하지 않았고 객체의 다른 간단한 속성으로 만들어지는 단순한 생성 속성을 원했습니다. 가장 매력적인 예는 아닐 수도 있지만 기능을 보여줍니다.

var searchMappingConfig = {
    // specific configuration for mapping the results property
    "results": {
                    // specific function to use to create the items in the results array
        "create": function (options) {
            // return a new function so we can have the proper scope/value for "this", below
            return new function () {

                // instead of mapping like we normally would: ko.mapping.fromJS(options.data, {}, this);
                // map via extend, this will just copy the properties from the returned json element to "this"
                // we'll do this for a more light weight vm since every last property will just be a plain old property instead of observable
                $.extend(this, options.data);

                // all this to add a vehicle title to each item
                this.vehicleTitle = this.Year + "<br />" + this.Make + " " + this.Model;
                }, this);
            };
        }
    }
}

구독 및 폐쇄 및 매핑, 오 마이

또 다른 상황은 결과에서 폐쇄 및 구독을 원하는 경우입니다. 이 예제는 전체에 포함하기에는 너무 길지만 차량 제조업체 / 모델 계층 구조에는 해당되지 않습니다. 모델이 활성화되지 않은 경우 특정 제조업체 (부모)의 모든 모델 (하위)이 활성화되지 않기를 원했고 구독을 통해이 작업을 수행하기를 원했습니다.

// here we are specifying the way that items in the make array are created, 
//    since makes has a child array (Models), we will specify the way that 
//    items are created for that as well
var makesModelsMappingConfig = {
   // function that has the configuration for creating makes
   "create": function (options) {
      // return a new function so we can have the proper 
      //    scope/value for "this", below
      return new function () {

         // Note: we have a parent / child relationship here, makes have models. In the 
         //    UI we are selecting makes and then using that to allow the user to select 
         //    models. Because of this, there is going to be some special logic in here 
         //    so that all the child models under a given make, will automatically 
         //    unselect if the user unselects the parent make.

         // make the selected property a private variable so it can be closure'd over
         var makeIsSelected = ko.protectedComputed(false);

         // expose our property so we can bind in the UI
         this.isSelected = makeIsSelected;

         // ... misc other properties and events ...

         // now that we've described/configured how to create the makes, 
         //    describe/configure how to create the models under the makes
         ko.mapping.fromJS(options.data, {
            // specific configuration for the "Models" property                  
            "Models": {
               // function that has the configuration for creating items 
               //    under the Models property
               "create": function (model) {

                  // we'll create the isSelected as a local variable so 
                  //    that we can flip it in the subscription below, 
                  //    otherwise we wouldnt have access to flip it
                  var isSelected = ko.protectedComputed(false);

                  // subscribe to the parents "IsSelected" property so 
                  //    the models can select/unselect themselves
                  parentIsSelected.current.subscribe(function (value) {
                     // set the protected computed to the same 
                     //    value as its parent, note that this 
                     //    is just protected, not the actual value
                     isSelected(value);
                  });


                  // this object literal is what makes up each item 
                  //    in the Models observable array 
                  return {
                     // here we're returning our local variable so 
                     //    we can easily modify it in our subscription
                     "isSelected": isSelected,

                     // ... misc properties to expose 
                     //     under the item in the Model array ...

                  };
               }
            }
         }, this);
      };
   }
};

대체로 내가 찾은 것은 플러그인에 전달할 객체의 100 %가 거의 필요하지 않으며 관찰 가능하도록 100 %가 거의 필요하지 않다는 것입니다. 매핑 구성 옵션을 살펴보고 모든 종류의 복잡하고 단순한 개체를 만듭니다. 아이디어는 필요한 모든 것을 얻는 것입니다.

---

Allen, my recent learning experience with Knockout.js has been similar to yours. We work with a deep hierarchical object graph from the server and I have defined explicit instantiable view model functions which preserve the basic structure of it.

I began by defining each property explicitly as an observable on the relevant view model, but that quickly got out of hand. Also, a major reason for switching to using the mapping plugin was that we have to do frequent Ajax posts of the graph back to the server where it is merged with the persisted version, then validated on the server in such a way that numerous properties can change and collections be modified, and a new instance returned as the Ajax result where it has to be re-merged with the client representation. That became seriously difficult, and the mapping plugin helped big time by allowing the specification of identifiers for resolving adds / deletes / updates and to remap an updated graph onto the original.

It also helped in the original graph creation through the use of the "create" option for sub view models. In each view model constructor I receive a reference to the parent view model plus the data with which to construct the child view model, then create further mapping options to create grandchildren from the passed-in child data.

The only (slight) downside I recently found, as detailed in this question, is that when doing ko.mapping.toJSON it doesn't hook into any toJSON overrides you may have defined on the prototypes of your view models in order to exclude properties from serialization. I have been able to get around that by specifying ignore options in the unmapping, as recommended by Ryan Niemeyer in that post.

So in summary, I'll definitely be sticking with the mapping plugin. Knockout.js rules.

---

A simpler but help-full add-on could be knockout-data-projections

Currently, it does not handle js to viewmodel mappings, but it handles quite well view model to JS mappings.

ReferenceURL : https://stackoverflow.com/questions/7488208/am-i-overusing-the-knockout-mapping-plugin-by-always-using-it-to-do-my-viewmodel