перегрузочный маршрут одного и того же сайта в плавающем фрейме

Question

Часть кода была разработана для нас, а основная (и упрощенный) дизайн выглядит следующим образом:

Страница посадки имеет две секции с примером раздела 1, как показано ниже

который довольно прост: нажмите на ссылку 1-1 к 1-N и направит вас к странице, например, http://testpage.com/link1-1

Сейчас в разделе 2 вещи работают подобно тому, как показано ниже:

С той разницей, что любая ссылка на раздел 2, который направляет на странице есть информация (не важно для этого вопроса) и IFRAME. Этот iFrame, в зависимости от того, какая ссылка нажата, загружает ссылки из раздела 1.

Моя первая проблема здесь в использовании iFrame. Многое происходит здесь: он перезагружает весь сайт (это означает, что вы загружаете все с нуля). Некоторая часть информации является проводной, не перезагруженной с помощью оператора if, который проверяет, загружается ли сайт в iFrame. Для меня все это немного грязно. Некоторые команды перекрестно передают из iFrame в родительское окно, а некоторые нет. Отследить все невозможно.

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

Я упомянул следующие проблемы им:

• это неуправляемый
• это память неэффективна
• это влияет на время загрузки

Причина они говорят, что они сделали это :

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

я не согласен довольно сильно с первыми двумя утверждениями, потому что iFrame загружает новую версию CSS, и код может быть повторно использован без использования iFrame. Я немного в темноте с 3'rd.

Теперь на мой вопрос. Это единственный способ сделать это? Система работает на Backbone.js, и я почти полностью убежден, что это может быть сделано более чистым, более эффективным способом. Насколько сложно очистить все ресурсы, которые будут загружены, если ссылка будет введена в div, а не в iFrame?

Answer 1

Ну, одна из основных причин, по которой мы имеем mv * framework, - это использование кода.

У нас есть компоненты вида, чтобы мы могли легко создать экземпляр и ввести его в любом месте.Загрузка всего приложения в по определенному маршруту для отображения определенного вида не имеет смысла и теряет смысл иметь одну страницу приложение. Одно из их главных преимуществ заключается в том, что браузеру не нужно создавать совершенно новые документы и загружать (и обрабатывать - компилировать скрипты, вычислять стили CSS для рисования и т. Д.) Одни и те же ресурсы снова и снова.

• "Песочница: Нет необходимости переделывать CSS"

Может быть действительны в зависимости от способа CSS написано. Например, когда загружается свободно в testpage.com:link, представление может быть непосредственно под div с классом container, но при загрузке в маленьком ящике в разделе два оно может быть глубоко вложено внутри него (или в худшем случае, возможно, оно даже не будет).

Так селектор CSS, как .container > .linkView не будет работать во втором случае, и это должно быть изменено в .container .linkView

The изменения CSS, которые могут потребоваться полностью зависят от структуры DOM, сложности и способ его написано в настоящее время.

• код повторно

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

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

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

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

Если пользователь случайно посетить link 1-1 в разделе 1, когда мы навещаем же в разделе 2, в одном приложении страницы у нас есть преимущество, что необходимые средства уже загружены (и обработанный) в браузере, и если он не позволял браузеру загружать дополнительные необходимых активов. На мой взгляд, это намного лучше, чем загрузка браузера и компиляция из underscore и jquery для документа .

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

---

Что касается первого пункта:

• это неуправляемый

Это зависит от того, кто управляет кодом, если это те, кто пришел с , может быть, это проще их для управления: D

Я полностью согласен с остальными 2 очками.