Я считаю, что у каждого фронтенд-разработчика есть свой любимый фреймворк JavaScript, будь то эмоции или убеждения. Фреймворк JavaScript приносит не только удобство разработки, но и чистую логическую красоту, будь то изящная простота jquery или волшебство Юи. песочница, все они дают нам безграничное воображение. Однако js-фреймворк не сможет достичь всестороннего совершенства. Например, уступки jquery в объектно-ориентированном дизайне и жертвы yui в производительности — все это передает людям некую несовершенную красоту и идеальный реализм. Сегодня давайте взглянем на эти жертвы и уступки, на которые пошел yui3 при разработке фреймворка, чтобы мы могли глубже понять полную картину yui3 и максимизировать его преимущества.
1. Один этап или грануляция семян.
Так называемое одноэтапное заполнение означает, что вам нужно только ввести тег сценария исходного файла на странице, например, прототип и jquery, и просто ввести прототип.js или jquery.js. Они будут инкапсулировать операции DOM и. события и т. д. в файл и старайтесь сделать его как можно меньшим. Преимущества этого подхода очевидны. Использование фреймворка очень просто. Однако Юи разделил эти функции на уровни и детальные конструкции, концептуально абстрагируя «ядро», «инструменты» и «компоненты». Каждая небольшая функция помещается в файл. При необходимости вы должны указать ее большое количество. Из демо-версий, приведенных в документации yui, этот метод явно не так удобен для новичков, как jquery, и его не так глупо использовать, чтобы реализовать небольшую функцию, даже необходимо ввести три или четыре js. файл. У yui есть две причины: во-первых, yui слишком велик, и помещать все функции в один файл немного ненадежно. Во-вторых, это открывает путь к созданию динамически загружаемой среды.
2. Ручное введение или динамическая загрузка.
Традиционный метод записи js на страницу — это прямая запись js-файла на странице в качестве пути к тегу скрипта. Вы также можете представить страницу таким образом, используя yui, но yui рекомендует использовать загрузчик для динамической загрузки. Происхождение динамически загружаемых скриптов очень сложно. В настоящее время существует три основные причины. Во-первых, рукописные теги js на странице в любом случае будут занимать HTTP-запрос. Даже если запрос имеет код 304, нет необходимости инициировать его. реальный HTTP-запрос после кэширования динамически загружаемого файла. Во-вторых, динамическая загрузка может реализовывать загрузку по требованию и может быть основана на файлах js. Дедупликация и сортировка взаимозависимостей, загрузка js-файлов с рукописными тегами требует от разработчиков повышенного внимания к сортировке, дублированию и т. д. файлов. В-третьих, динамическая загрузка благоприятствует семантике кода страницы, что заставляет разработчиков заботиться только о том «Что». вам нужно», а не «как это получить». Когда проекты становятся все более раздутыми, а затраты на техническое обслуживание становятся все выше и выше, эти малые и средние технологии принесут большую пользу.
3. Единый вход или песочница для логического запуска.
Когда мы запускаем логику js на странице, мы обычно помещаем ее в такой метод, как onDomReady. Что, если на странице несколько логик? Например, a реализует логику A, а код страницы такой:
<script src="logicA.js" />
<скрипт>
$.onDomReady(функция(){
___LogicA.start();
});
</скрипт>
Этот код обычно пишется в конце страницы. HTML-код, сопровождающий эту логику, спрятан где-то на странице. На данный момент b необходимо добавить логику B на страницу. Что делает b, так это сначала находит этот код. конец, а затем измените его, чтобы он выглядел так:
<script src="logicA.js" />
<script src="logicB.js" />
<скрипт>
$.onDomReady(функция(){
___LogicA.start();
___LogicB.start();
});
</скрипт>
Аналогичным образом, HTML-код, сопровождающий логику B, также спрятан где-то на странице. Кажется, что логика js и сопровождающий ее HTML-код настолько разделены, что когда дело доходит до удаления функции, HTML часто удаляется, а js забывается. . или удалить js и забыть удалить html также будет проблемой при повторном использовании кода. Аналогичным образом, при отладке инженерам также приходится открывать два окна, чтобы сосредоточиться на js и html соответственно, даже если эти два фрагмента кода находятся в одном файле. В этом случае лучше написать код так:
Этот метод кодирования — именно тот, который защищает Юи, а именно так называемая «песочница». Каждая логика содержится в «песочнице», и каждая делает свое дело, не мешая друг другу. Когда третья сторона просматривает код, она сразу понимает, что это независимый функциональный блок, включающий типичную структуру HTML и логику запуска js. Если они захотят повторно использовать, они могут просто скопировать весь блок.
<!–Логический сегмент HTML-кода–>
<script src="logicA.js" />
<скрипт>
$.onDomReady(функция(){
___LogicA.start();
});
</скрипт>
…
<!–B логический сегмент HTML-кода–>
<script src="logicB.js" />
<скрипт>
$.onDomReady(функция(){
___LogicB.start();
});
</скрипт>