Backbone: Пользовательские сборки Backbone

Было бы здорово.

Если вас интересует, как я сделал модульную базу кода Backbone.js, посмотрите папку customBuild внутри моей магистральной вилки. Имейте в виду, что все модульные тесты Backbone по-прежнему проходят успешно.
https://github.com/gfranko/backbone/tree/modularBuilds

Кроме того, вот пример того, как будет работать пользовательский интерфейс сборки:
http://gregfranko.com/backbone/customBuild/

Наконец, вот сообщение в блоге, которое я написал, чтобы обсудить возможное использование только некоторых частей Backbone:
http://gregfranko.com/blog/backbone-dot-js-convincing-the-boss-guide/

Я очень ценю идею, особенно ту часть, где рубиновые зависимости исчезли, и в игру вступает ворчание.

Также бывают ситуации, когда мне не нужен Backbone.Router (потому что у меня нет чего-л. Для маршрутизации, но я все же предпочитаю использовать Backbone для организации своего JavaScript).

Кроме того, это очень хорошо сочетается с кастомными сборками LoDash (ну, надеюсь, никто не злится).

@asciidisco Я еще не сделал работы по интеграции пользовательских сборок с Grunt. У вас есть идеи, как бы вы к этому подойти?

@gfranko Хотел бы видеть реализацию, подобную jQuery (с версии 1.8 у них тоже есть собственные сборки),
может быть, я раскрою ваш проект и опробую его на этих выходных, но я не совсем уверен, хватит ли у меня времени :(

@asciidisco Не беспокойтесь об этом. На этих выходных я посмотрю файл jQuery grunt, чтобы узнать, как они это делают.

: +1: для модуляции кодовой базы

Хотя часто бывает полезно несколько файлов, я не думаю, что Backbone выиграет от разделения источника. Библиотека довольно мала, поэтому пользовательские сборки сэкономят в лучшем случае всего несколько килобайт, в то время как добавленная сложность будет значительной.

Как бы то ни было, это уже обсуждалось ранее, по крайней мере, однажды в # 65.

Как насчет вариантов использования, например, когда пользователь использует jQuery Mobile с Backbone.js и не хочет включать магистральные маршруты?

Я согласен с тем, что исходный код Backbone по умолчанию должен оставаться в виде одного файла, но я предлагал также добавить разделение источника на несколько файлов (я понимаю, что это требует дополнительной работы), если пользователю не нужна конкретная функция.

Кроме того, я предположил в своем сообщении в

И просто любопытно, что будет дополнительной сложности?

Как насчет вариантов использования, например, когда пользователь использует jQuery Mobile с Backbone.js и не хочет включать магистральные маршруты?

Просто удалите его из источника. Это довольно четко обозначено и довольно легко сделать.

И просто любопытно, что будет дополнительной сложности?

Я имею в виду сложность для новых и существующих участников. Написание кода для нового проекта всегда непросто, и мы хотим его как можно больше поощрять. В настоящее время Backbone требует только браузера, который будет обслуживать локальные файлы, и текстового редактора. Требование системы / инструмента сборки - большой шаг вперед.

Тем не менее, я не против пользовательских сборок в целом, и мне скорее нравится инструмент, который вы представили в своем сообщении в блоге. :)

Вы правы, каждый объект класса Backbone четко помечен (поэтому мне было так легко разделить базу кода). При этом я не думаю, что большинство разработчиков хотят касаться источника библиотеки, которую они используют.

В качестве примера рассмотрим Require.js и скрипты, несовместимые с AMD. Достаточно легко обернуть библиотеку внутри метода определения, но кому это нужно?

Но да, я слышу, что вы говорите о том, чтобы не пытаться вводить слишком много зависимостей / сложностей. Думаю, я просто сохраню это как отдельный проект и буду поддерживать код в актуальном состоянии с исходным кодом магистрали.

Ага, я думаю, что это действительно изящный проект ... но Backbone выигрывает от того, что он простой, единый скрипт. Если у вас установлена ​​Backbone, значит, она у вас установлена, и вы можете рассчитывать на то, что все, что она предоставляет, доступно.

braddunbar: Просто удалите его из источника. Это довольно четко обозначено и довольно легко сделать.

Ага, это ловушка! Наличие официальной системы сборки для обеспечения качества, совместимости и функциональности лучше.

jashkenas: Ага - я думаю, что это действительно отличный проект ... но Backbone выигрывает от того, что он простой, единый скрипт.

Да, я тоже копаю отдельные файлы, поэтому Lo-Dash - это один файл, но по-прежнему поддерживает пользовательские сборки (хотя jQuery позволяет ему работать с отдельными файлами в своем репо).

Пользовательские сборки великолепны и дают разработчикам больше контроля. Поскольку Lo-Dash и jQuery поддерживают пользовательские сборки, единственное, чего не хватает, - это Backbone; D

Привет,
если кому-то из вас интересно, я сделал плагин grunt для создания пользовательских сборок Backbone из
"нормальные" исходные файлы магистрали: https://github.com/asciidisco/grunt-backbonebuilder

На данный момент не очень протестирован (хотя я использую магистральную версию, в которой не учитываются все маршрутизаторы и история), которая работает
хорошо. Обратная связь приветствуется.

@asciidisco Спасибо, ты

Было бы неплохо, если бы мы переключились на просмотр или веб-пакет, чтобы мы могли легко получить лучшее из обоих миров (несколько файлов и один файл).

Было бы неплохо иметь Events как отдельный модуль. Очень полезно при сборке пользовательских модулей с необязательными зависимостями Model s и Collection s.

Я использую Backbone Model and Collection в своих проектах Angular и AngularJS. Мне нужна только модель и коллекция, потому что концепция потрясающая. Я использую это как уровень доступа к данным. Angular предоставляет слой пользовательского интерфейса.

Недавно я написал статью о том, как можно извлечь выгоду из использования BackboneJS в приложении Angular: https://docs.google.com/document/d/1ptYmQzjq8EWLKyqFENqyXwzz67VNWzh_-clhy4W5R40

Было бы здорово разделить BackboneJS на несколько компонентов, чтобы вы могли включать только то, что вам нужно.

@jashkenas А как насчет разделения файлов src на несколько файлов и позволить задаче сборки объединить их в один файл, чтобы у вас были оба:

• простой одиночный файл
• и разделить исходные файлы
  ?