Крупномасштабная архитектура приложений KnockoutJS

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

Сейчас я обрабатываю код, создавая модель с корневым представлением, которая обычно начинается с уровня главной страницы, а затем расширяется. Я только ko.applyBindings() на главном экране. Вот пример кода, который у меня есть:

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

Я знаю, что вы можете применять привязки к отдельным элементам, чтобы изменить область привязок, но что, если у меня есть вложенные модели представлений?

Ответы

Ответ 1

Мне нравится настраивать свои модели просмотра, используя прототипное наследование. Как и у вас, у меня есть модель "мастера". Эта модель просмотра содержит экземпляры других моделей представлений или наблюдаемых массивов моделей взглядов, из которых вы можете использовать привязки "foreach" и "with" в своей разметке. В ваших привязках "foreach" и "with" вы можете использовать $data, $parent, $parents и $root привязки для ссылки на модели родительского представления.

Вот соответствующие статьи в документации KO.

привязка foreach

со связыванием

контекст привязки

Если ты хочешь, я могу собрать скрипку. Дайте мне знать.

Ответ 2

У меня довольно крупное одностраничное приложение knockout.js. (20K + строк кода в настоящее время), что очень легко для любого, чтобы поддерживать и добавлять дополнительные разделы. У меня есть сотни наблюдаемых, и производительность по-прежнему велика, даже на мобильных устройствах, таких как старый iPod touch. Это приложение, в котором размещен набор инструментов. Вот некоторые сведения о приложении, которое я использую:

1. Только одна модель. Это держит вещи просто ИМХО.

Модель представления обрабатывает основы любого приложения с одной страницей, такие как видимость каждой страницы (приложения), навигации, ошибок, загрузок и диалогов тостов и т.д. Пример фрагмента модели просмотра: (я отделяю его еще дальше js файлы, но это даст вам обзор того, как это выглядит)

var vm = {

    error:
    {
        handle: function (error, status)
        {
           //Handle error for user here
        }
    },
    visibility:
    {
        set: function (page)
        {
            //sets visibility for given page
        }
    },
    permissions:
    {
        permission1: ko.observable(false),
        permission2: ko.observable(false)
        //if you had page specific permissions, you may consider this global permissions and have a separate permissions section under each app
    },
    loadDialog:
    {
        message: ko.observable(''),
        show: function (message)
        {
            //shows a loading dialog to user (set when page starts loading)
        },
        hide: function()
        {
            //hides the loading dialog from user (set when page finished loading)
        }
    },

    app1:
    {
        visible: ko.observable(false),
        load: function () 
        {
          //load html content, set visibility, app specific stuff here
        }
    },
    app2: 
    {
        visible: ko.observable(false),
        load: function () 
        {
          //load html content, set visibility, app specific stuff here
        }
    }

}

2. Все модели входят в отдельный файл .js.

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

    //Message Class
    function Message {
        var self = this;

        self.id = ko.observable(data.id);
        self.subject = ko.observable(data.subject);
        self.body = ko.observable(data.body);
        self.from = ko.observable(data.from);

    }

3. Сохранять вызовы базы данных AJAX в своих файлах js.

Предпочтительно разделяется разделом или "приложением". Например, дерево папок может быть js/database/с app1.js и app2.js в виде js файлов, содержащих ваши базовые функции создания, обновления и удаления. Пример вызова базы данных:

vm.getMessagesByUserId = function ()
{

    $.ajax({
        type: "POST",
        url: vm.serviceUrl + "GetMessagesByUserId", //Just a default WCF url
        data: {}, //userId is stored on server side, no need to pass in one as that could open up a security vulnerability
        contentType: "application/json; charset=utf-8",
        dataType: "json",
        cache: false,
        success: function (data, success, xhr)
        {
            vm.messaging.sent.messagesLoaded(true);

            for (var i = 0; i < data.messages.length; i++)
            {
                var message = new Message({
                    id: data.messages[i].id,
                    subject: data.messages[i].subject,
                    from: data.messages[i].from,
                    body: data.messages[i].body
                });
                vm.messaging.sent.messages.push(message);
            }
        },
        error: function (jqXHR)
        {
            vm.error.handle(jqXHR.getResponseHeader("error"), jqXHR.status);
        }
    });
    return true;
};

4. Объедините и сверните всю модель, модель модели и файлы js базы данных в один.

Я использую расширение Visual Studio "Веб-Essentials", которое позволяет создавать "связанные" js файлы. (Выберите js файлы, щелкните их правой кнопкой мыши и перейдите в веб-Essentials → Создать файл Javascript Bundle). Мой файл Bundle настроен так:

<?xml version="1.0" encoding="utf-8"?>
<bundle minify="true" runOnBuild="true">
  <!--The order of the <file> elements determines the order of them when bundled.-->

  <!-- Begin JS Bundling-->
  <file>js/header.js</file>


  <!-- Models -->

  <!-- App1 -->
  <file>js/models/app1/class1.js</file>
  <file>js/models/app1/class2.js</file>

  <!-- App2 -->
  <file>js/models/app2/class1.js</file>
  <file>js/models/app2/class2.js</file>

  <!-- View Models -->
  <file>js/viewModel.js</file>

  <!-- Database -->
  <file>js/database/app1.js</file>
  <file>js/database/app2.js</file>

  <!-- End JS Bundling -->
  <file>js/footer.js</file>

</bundle>

header.js и footer.js являются всего лишь оболочкой для функции готовности документа:

header.js:

//put all views and view models in this
$(document).ready(function()
{

footer.js:

//ends the jquery on document ready function
});

5. Разделите свой HTML-контент.

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

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

<!-- Begin Messaging -->    
    <!--#include virtual="Content/messaging.html" -->
<!-- End Messaging -->

Вы не хотите использовать серверную часть слишком много, иначе количество HTML, которое пользователь будет загружать при каждом посещении страницы, станет довольно большим. С учетом сказанного, это, безусловно, самое простое решение для разделения вашего html, но сохраняйте привязку к нокауту.

Загрузить HTML-контент async: (я использую это, если данный фрагмент приложения используется пользователями менее часто)

Я использую функцию загрузки jQuery для выполнения этого:

        // #messaging is a div that wraps all the html of the messaging section of the app
        $('#messaging').load('Content/messaging.html', function ()
        {
            ko.applyBindings(vm, $(this)[0]); //grabs any ko bindings from that html page and applies it to our current view model
        });

6. Сохраняйте видимость ваших страниц и приложений

Отображение и скрытие различных разделов вашего приложения knockout.js может сходить с ума из-за множества строк кода, которые трудно контролировать и запоминать, потому что вам приходится устанавливать так много разных переключателей. Во-первых, я сохраняю каждую страницу или приложение в своем собственном "div" (и в собственном html файле для разделения). Пример HTML:

<!-- Begin App 1 -->

<div data-bind="visible: app1.visible()">
<!-- Main app functionality here (perhaps splash screen, load, or whatever -->
</div>

<div data-bind="visible: app1.section1.visible()">
<!-- A branch off of app1 -->
</div>

<div data-bind="visible: app1.section2.visible()">
<!-- Another branch off of app1 -->
</div>

<!-- End App 1 -->


<!-- Begin App 2 -->
<div data-bind="visible: app2.visible()">
<!-- Main app functionality here (perhaps splash screen, load, or whatever -->
</div>
<!-- End App 2 -->

Во-вторых, у меня была бы функция видимости, подобная этой, которая устанавливает видимость для всего контента на вашем сайте: (он также обрабатывает мою навигацию также в подфункции)

vm.visibility:
{
    set: function (page)
    {
      vm.app1.visible(page === "app1");
      vm.app1.section1.visible(page === "app1section1");
      vm.app1.section2.visible(page === "app1section2");
      vm.app2.visible(page === "app2");     
    }
};

Затем просто вызовите функцию загрузки приложения или страницы:

<button data-bind="click: app1.load">Load App 1</button>

Что бы в нем была эта функция:

vm.visibility.set("app1");

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