Подтвердить что ты не робот

RequireJS: Есть ли способ получить несколько базовых URL-адресов?

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

foo.example.com
    main.js
    lib/foo-specific.js
framework.example.com
    framework.js <-- entry point
    lib/jquery.js
    lib/etc...

Оптимально, я хотел бы иметь возможность требовать "lib/foo-specific" и/или "lib/jquery" и иметь пути, которые просто решаются красиво, но из того, что я нашел, нет способа сделать это, если я не использую конкретный ключ/значение пути для каждого js файла в рамках. На данный момент у меня есть настраиваемый плагин для загрузки заданного пути с другим базовым url (например, fw!lib/jquery), хотя если бы я хотел использовать плагин text!, он не будет работать, поскольку цепочка подключений не поддерживается,

Смотрите https://github.com/jpillora/js-framework для того, что я получил в настоящее время, а также https://github.com/jpillora/prettyprinter для использования.

Есть ли чистый способ решить эту проблему? или для достижения нескольких базовых URL-адресов?

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

4b9b3361

Ответ 1

Ответ Джеймса Берка на странице RequireJS Github Issue: Проблема № 447: Несколько базовых URL-адресов · jrburke/requirejs.

Оказывается, это довольно просто, если data-main - единственная точка входа в ваши скрипты (комментарии для дополнительной информации). Я решил свою конкретную проблему со следующим:

Мое приложение index.html:

<script src="http://framework.jpillora.com/js/lib/require.js" 
  data-main="http://framework.jpillora.com/js/framework" > </script>

имеет точку входа requirejs, установленную на framework.js:

var framework = ... //set using script elements src attribute

require.config({

    baseUrl: 'js/',

    //Framework paths
    paths: {
      'framework': framework,
      'lib'      : framework + 'js/lib',
      'ext'      : framework + 'js/ext',
      'util'     : framework + 'js/util'
    },

    //Shortcuts
    map: {
      '*': {
        ...
      }
    },

    //Non-modularised libraries with deps
    shim: {
      ...
    }
});

require(['main']);

Поэтому вместо обычного index.html->main.js мы добавляем дополнительный шаг index.html->framework.js->main.js, который дает код приложения знанию путей к коду рамки.

Например, в приложении http://prettyprint.jpillora.com/, после того, как потребовалось загрузить framework.js, он установит пути к lib/..., которые будут http://framework.jpillora.com/ и установите baseUrl как ./js/, поэтому требуется один раз main, у него будет установлен базовый url для него домен и lib, указывающие на другой домен.

В результате получается require(['lib/foo', 'view/bar']); разрешение:

http://framework.jpillora.com/js/lib/foo.js и http://prettyprint.jpillora.com/js/view/bar.js

Как показано здесь, приложение представляет собой только main.js все, что происходит от framework:

chrome devtools loaded app

Итак, всякий раз, когда я загружаю приложение main.js через вышеуказанный framework.js, я получаю доступ ко всем моим обычно используемым библиотекам и служебным классам. См. Источник приложения.

Также обратите внимание, что с оптимизатором r.js и хорошей локальной файловой структурой можно также оптимизировать приложение в один файл js, вытягивая только то, что требуется от framework.

Ответ 2

Проблема

У меня была аналогичная проблема при попытке настроить тестовую среду. У меня была такая файловая структура:

myApp/
    src/
        js/
            app.js
            data.js
            lib/underscore.js
    test/
        karma.conf.js
        test-main.js
        matchers.js
        spec/
            data.js

Здесь, где это сложно: сценарии приложений (app.js и data.js) принимают конфигурацию RequireJS, которая разрешает data до src/js/data.js, lib/underscore до src/js/lib/underscore.js и т.д., поэтому мне нужна эта конфигурация в моя тестовая среда:

test/test-main.js
-----------------
require.config({
  // Karma serves files under /base, which is the basePath from your config file
  baseUrl: '/base/src/js',
  // ...
});

Теперь я могу написать свои тесты:

test/spec/data.js
-----------------
define(['data', '../../test/matchers'], function(dataModule) {
    describe('The data module', function() {
        it('should satisfy my custom matcher', function() {
            expect(dataModule).toSatisfyMyCustomMatcher();
        });
    });
});

С помощью некоторых пользовательских совпадений:

test/matchers.js
----------------
define([], function() {
    beforeEach(function() {
        this.addMatchers({
            toSatisfyMyCustomMatcher: function() {
                return this.actual.isGood;
            },
        });
    });
});

Однако эта часть '../../test/matchers' ужасно уродлива. Спецификации теста не должны беспокоиться о знании путей к файлам для других модулей - это требование RequireJS. Вместо этого мы хотим использовать символические имена.

Решение

Конфигурация маршрутов RequireJS также может отображать каталоги.

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

Итак, решение представляет собой простой путь config:

test/test-main.js
-----------------
require.config({
  baseUrl: '/base/src/js',
  paths: {
      test: '../../test',
  },
  // ...
});

Теперь я могу ссылаться на каталог test, как если бы он был дочерним элементом baseUrl:

test/spec/data.js
-----------------
define(['data', 'test/matchers'], function(dataModule) {
    // ...
});

Что в моем случае эффективно выходит примерно так же, как если бы я мог иметь несколько baseUrl s.

Ответ 3

Посмотрите, как мы обработали маршрутизацию и контекст в BoilerplateJS, который является эталонной архитектурой для крупномасштабной разработки продукта. Мы использовали библиотеку crossroads.js для маршрутизации модулей и компонентов пользовательского интерфейса. Все, что нужно сделать, это добавить путь/хэш к множеству маршрутов, и он будет маршрутизироваться через фреймворк.

В качестве пример все пути компонентов пользовательского интерфейса добавляются в объект контроллера URL.

Что касается доступа к информации конфигурации каркаса во всем приложении, конфигурации/настройки могут быть присоединены к объекту глобального контекста, к которому можно получить доступ внутри приложения.

Ответ 4

мультиверсия requirejs

Попробуй это

context: имя, которое нужно дать контексту загрузки. Это позволяет require.js загружать несколько версий модулей на странице, если каждый вызов require верхнего уровня указывает уникальную контекстную строку. Чтобы правильно его использовать, см. Раздел "Поддержка Multiversion".