Backbone: 백본 커스텀 빌드

그것은 좋은 것입니다.

Backbone.js 코드베이스를 모듈화한 방법에 관심이 있다면 백본 포크 내부의 customBuild 폴더를 확인하십시오. 모든 백본 단위 테스트는 여전히 성공적으로 통과한다는 점을 명심하십시오.
https://github.com/gfranko/backbone/tree/modularBuilds

또한 다음은 사용자 정의 빌드 UI가 작동하는 방식의 예입니다.
http://gregfranko.com/backbone/customBuild/

마지막으로 다음은 백본의 일부만 잠재적으로 사용하는 것에 대해 논의하기 위해 작성한 블로그 게시물입니다.
http://gregfranko.com/blog/backbone-dot-js-convincing-the-boss-guide/

저는 Idea, 특히 루비 의존성이 사라지고 꿀꿀거리는 소리가 작동하는 부분에 감사드립니다.

또한 Backbone.Router가 필요하지 않은 상황이 있습니다.

게다가 이것은 LoDash(어, 아무도 화를 내지 않기를 바랍니다) 커스텀 빌드와 정말 잘 어울립니다.

@asciidisco 아직 사용자 정의 빌드를 Grunt와 통합하는 작업을 수행하지 않았습니다. 당신이 그것에 접근하는 방법에 대한 아이디어가 있습니까?

@gfranko 구현과 같은 jQuery를 보고 싶습니다(1.8부터 사용자 정의 빌드도 있음).
이번 주말에 프로젝트를 분기하고 스핀을 줄 수도 있지만 충분한 시간이 있는지 확실하지 않습니다.(

@asciidisco 걱정하지 마세요. 이번 주말에 jQuery grunt 파일을 살펴보고 어떻게 하고 있는지 알아볼 것입니다.

:+1: 코드베이스를 모듈화하기 위해

여러 파일이 유용한 경우가 많지만 소스를 분할하는 것이 Backbone에 도움이 될 것이라고 생각하지 않습니다. 라이브러리는 다소 작기 때문에 사용자 정의 빌드는 기껏해야 몇 킬로바이트만 절약할 수 있지만 추가된 복잡성은 상당할 것입니다.

가치가 있기 때문에 이것은 이전에 #65에서 한 번 이상 논의되었습니다.

예를 들어 사용자가 Backbone.js와 함께 jQuery Mobile을 사용하고 있고 Backbone Routes를 포함하고 싶지 않은 경우의 사용 사례는 어떻습니까?

기본 Backbone 소스가 하나의 파일로 유지되어야 한다는 데 동의하지만 사용자가 특정 기능을 원하지 않는 경우를 대비하여 소스를 여러 파일로 분할(이것이 더 많은 유지 관리 작업이라는 것을 알고 있음)도 추가할 수 있다고 제안했습니다.

또한 내 블로그 게시물 에서 사용자가 Backbone의 모든 기능을 포함하지 않도록 하면 기업 환경에서 Backbone을 훨씬 더 쉽게 사용할 수 있다고 제안했습니다.

그리고 추가된 복잡성은 무엇인지 궁금합니다.

예를 들어 사용자가 Backbone.js와 함께 jQuery Mobile을 사용하고 있고 Backbone Routes를 포함하고 싶지 않은 경우의 사용 사례는 어떻습니까?

소스에서 삭제하면 됩니다. 라벨이 명확하고 수행하기 쉽습니다.

그리고 추가된 복잡성은 무엇인지 궁금합니다.

저는 신규 및 기존 기고자의 복잡성을 언급하고 있습니다. 새 프로젝트를 위한 코드를 작성하는 것은 항상 벅찬 일이며 가능한 한 권장하고 싶습니다. 현재 Backbone에는 로컬 파일과 텍스트 편집기를 제공하는 브라우저만 필요합니다. 빌드 시스템/도구가 필요한 것은 큰 발전입니다.

즉, 나는 일반적으로 사용자 정의 빌드에 반대하지 않으며 블로그 게시물에서 소개하는 도구를 선호합니다. :)

맞습니다. 각 Backbone 클래스 객체는 명확하게 레이블이 지정되어 있습니다. 즉, 대부분의 개발자가 사용 중인 라이브러리의 소스를 만지기를 원하지 않는다고 생각합니다.

Require.js 및 비 AMD 호환 스크립트를 예로 살펴보십시오. 정의 메소드 내부에 lib를 래핑하는 것은 충분히 쉽지만 누가 그렇게 하고 싶습니까?

그러나 예, 너무 많은 종속성/복잡성을 도입하지 않는 것에 대해 귀하가 말하는 것을 들었습니다. 나는 이것을 별도의 프로젝트로 유지하고 백본 소스를 사용하여 코드를 최신 상태로 유지할 것이라고 생각합니다.

예 -- 정말 깔끔한 프로젝트라고 생각합니다 ... 그러나 Backbone은 단순하고 단일 스크립트라는 이점이 있습니다. 백본이 설치되어 있다면 백본이 제공되며 사용 가능한 모든 것에 의존할 수 있습니다.

bradunbar: 소스에서 삭제하면 됩니다. 라벨이 명확하고 수행하기 쉽습니다.

가, 함정이다! 품질, 호환성 및 기능을 보장하기 위한 공식 빌드 시스템이 있으면 더 좋습니다.

jashkenas: 예 -- 정말 깔끔한 프로젝트라고 생각합니다... 하지만 Backbone은 단순한 단일 스크립트라는 이점이 있습니다.

예, 저도 단일 파일을 파고 있습니다. 이것이 Lo-Dash가 단일 파일이지만 여전히 사용자 정의 빌드를 지원하는 이유입니다(jQuery는 리포지토리의 개별 파일과 함께 작동하지만).

사용자 정의 빌드는 훌륭하고 개발자에게 더 많은 제어 권한을 제공합니다. Lo-Dash 및 jQuery가 사용자 정의 빌드를 지원하는 경우 누락된 유일한 것은 Backbone ;D

이봐,
관심 있는 분이 있다면 커스텀 백본 빌드를 생성하는 그런트 플러그인을 만들었습니다.
"일반" 백본 소스 파일: https://github.com/asciidisco/grunt-backbonebuilder

지금까지는 실제로 테스트되지 않았습니다(모든 라우터 및 기록 항목을 제외하고 백본 버전을 실행하지만). 작동합니다.
잘. 피드백 환영합니다.

@asciidisco 감사합니다.

Browserify 또는 webpack으로 전환하면 두 세계(여러 파일 및 단일 파일)의 장점을 쉽게 얻을 수 있으면 좋을 것입니다.

Events 를 별도의 모듈로 하는 것이 좋습니다. 선택적 Model 및 Collection 종속성이 있는 사용자 정의 모듈을 빌드할 때 매우 유용합니다.

Angular 및 AngularJS 프로젝트에서 백본 모델 및 컬렉션을 사용하고 있습니다. 컨셉이 굉장하기 때문에 모델과 컬렉션만 있으면 됩니다. 나는 데이터 액세스 계층으로 사용하고 있습니다. Angular는 UI 레이어를 제공합니다.

최근에 Angular 앱에서 BackboneJS를 사용하여 이점을 얻을 수 있는 방법에 대한 기사를 작성했습니다. https://docs.google.com/document/d/1ptYmQzjq8EWLKyqFENqyXwzz67VNWzh_-clhy4W5R40

BackboneJS를 여러 구성 요소로 분할하여 필요한 항목만 포함할 수 있다면 정말 좋을 것입니다.

@jashkenas src 파일을 여러 파일로 분할하고 빌드 작업이 파일을 하나의 파일로 연결하여 두 파일을 모두 어떻습니까 ?

• 간단한 단일 파일
• 소스 파일 분할
  ?