Зачем нам нужно приложение с одной страницей?

Ответ 1

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

ВАЖНО:

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

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

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

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

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

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

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

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

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

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

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

Услуги по обработке страниц

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

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

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

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

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

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

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

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

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

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

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

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

Удачи!