Зачем нам нужна одна страница приложения? [закрытый]

---

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

---

Важно:

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

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

---

---

Уменьшить время загрузки и / или вес

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

Некоторые из наиболее сильно влияющих особенностей этого метода включают:

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

Повышенная вероятность чрезмерного усложнения

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

Начните с сильной архитектуры!

Как и любая веб-страница, Обработка данных может быть перенесена непосредственно в обработчики служб вместо страниц , что может привести к архитектуре, использующей следующие слои:

• База Данных (Хранилище Данных)
• BL (обработка и транспортировка данных)
• пользовательский интерфейс (отображение данных и взаимодействие с пользователем)

Услуги над обработкой страниц

На мой взгляд Использование сервисов-это в значительной степени требование для организованного и модулированного кода на веб-сайте. Стандартные методы get и post, используемые на веб-сайте с обратной совместимостью, также могут использовать эти службы для поиска служб, представляющих бизнес-объекты, а не страницы. это позволяет коду быть более обобщенным между модулями, относящимися к одним и тем же объектам.

Обновление до одностраничного приложения затем становится упрощенным в что вы можете инициализировать любой пользовательский интерфейс, чтобы подобрать методы get или post и выполнить их с помощью методов AJAX вместо того, чтобы вызывать обратную передачу событий, таким образом, один экземпляр страницы.

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

Отложенная Загрузка!

Любой сложный сайт будет оснащен сложными модулями и множеством уникальных компонентов.

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

Мой список лучших практик

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

• хранение информации по мере ее поступления, стирание, когда она больше не актуальна
• загрузка в script, html и JS файлы через ajax только при необходимости
• использование данных, загруженных на одной странице в другой, если это может быть вместо перезагрузки для каждая новая "страница"
• минималистская структура данных для пользовательского интерфейса, так как это средство для отображения, а не для обработки.
• не зацикливайтесь на проверке пользовательского интерфейса, потому что ваши сервисы уже должны быть построены для проверки любой информации, представленной в него

Эти оптимизации полезны для времени загрузки, обработки данных и ассоциаций объектов. Очевидно, что это не полный список, но это отличная фора, чтобы построить вам одну страницу приложение. Наконец, я бы предложил исследовать концепции дляпроектирования для одного веба , чтобы помочь построить прочный фундамент. После этого все остальное-относительно простые усовершенствования. (Совет: одно из этих усовершенствований состоит в том, чтобы перехватывать все действия, приводящие к обратному вызову, и использовать информацию для создания асинхронного вызова вместо этого).

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

Удачи!