构建动态AngularJS指令：提升单页应用的交互与模块化

需积分: 9 72 浏览量更新于2024-07-20 收藏 3.37MB PDF 举报

《AngularJS Directives (PACKT, 2013)》是一本深入探讨AngularJS核心特性的专业指南，由Google推动的AngularJS迅速成为最受欢迎的JavaScript MVC框架之一。它旨在通过数据驱动的模块化，逆转开发范式，提升前端Web应用的动态性。本书主要关注AngularJS指令（Directives），这些是构建AngularJS应用的基础组件，允许开发者创建可重用的模型，以适应数据结构，并将HTML与JavaScript无缝融合。书中首先介绍了单页应用开发的最佳实践，然后逐步讲解AngularJS指令如何实现这些目标。作者Alex Vanston带领读者从零开始构建指令，并分享了最佳的设计原则。读者将不仅掌握创建指令的基本技能，还能学会如何合理组织和组合它们，以构建出响应实时数据变化的完整动态Web应用。作者强调以数据模型为基础进行应用开发的重要性，教导读者如何设计能相互交流的新模块，以及如何创建可嵌入第三方网站的部件。此外，书中的内容还包括如何制作用户友好的定制输入，以便用户能够直观地与数据交互。通过学习本书，读者将获得构建自定义指令所需的工具，以及如何在构建更动态的Web应用中有效地运用它们。版权方面，所有内容未经Packt Publishing事先书面许可，不得复制、存储或以任何形式传播，除非用于学术引用。尽管出版社已尽力确保信息的准确性，但书籍销售不提供任何明示或默示的保修，作者和Packt Publishing及其经销商不对因本书内容导致的直接或间接损失负责。关于商标信息，尽管书中尽可能正确使用大写字母以标识提及的公司和产品，但Packt Publishing并不担保其准确性。《AngularJS Directives (PACKT, 2013)》是一本实用的教程，适合希望深入了解AngularJS指令并提升Web开发技能的开发者，无论是初级开发者还是经验丰富的专业人士，都能从中获益匪浅。通过阅读本书，读者将能够在实际项目中灵活运用AngularJS的强大功能，打造高效、用户友好的现代Web应用程序。

Designing Web

Applications in 2013

The goal of this chapter is to provide a quick introduction to some principles that

will help you create high quality code, specically aimed at frontend web application

development. For a fuller study, I strongly recommend the article, Patterns For

Large-Scale JavaScript Application Architecture, by Addy Osmani.

An overview of good code

If you're reading this book, I'm going to assume you've done at least some

programming work yourself, likely more than a little. During that time, I hope

you've had the chance to see some great code. Perhaps it was your own, but more

likely, at least for the rst couple times you glimpsed it, it was someone else's

masterpiece. You probably didn't necessarily know what made it great; you just

knew that it was far better than anything you had ever been able to extract

out of a keyboard.

On the other hand, almost anyone can identify bad code (unless it's their own, but

that's a whole different book). The logical holes, the ignored errors, the horrifyingly

inconsistent indentation; we've seen it all, often with our own name attached to the

le, but somehow transforming that spaghetti mess into anything resembling those

works of art that we'd previously marveled at continues to escape us. This book

isn't about beautiful code, but it is about a framework which exes its muscles

most effectively when wielded in a manner optimized for frontend applications,

and as such it's worthwhile for us to spend a chapter discussing some of the best

practices for modern frontend web development.

Designing Web Applications in 2013

[ 6 ]

For the purposes of our overview, we'll look at two basic tenets: modularity and

data driven development. Before we examine those, however, I want to use the next

section to address a common misunderstanding about frontend web development:

adding more APIs is not always the answer.

We're not just talking about a lot of APIs

Often, when a backend developer rst begins working on a frontend project, they

believe that they can simply create an awesome API in the backend, call it with the

frontend code, and have a complete frontend web application. When I rst started

developing frontend web applications, I wrote a lot of code that looked like the

following:

$('#nextLink').click(function () {

$.get('api/next', function (nextPage) {

displayPage(nextPage);

})

});

While the frontend technically handles both the user interaction ($('#nextLink').

click()), and the display (displayPage(nextPage)), the real driver here is the

backend API. The API handles the logic, the state, and makes nearly all the decisions

about how the application should actually function.

In contrast, the frontend applications built on top of data modeling frameworks

allow us to move away from that paradigm and instead position the client-side

code as the primary driver. This is awesome for two reasons:

1. It allows modern web developers to do 90 percent of the coding in the same

language. This creates the potential for more code reuse, easier debugging,

and all-round more efcient development, since even developers who speak

both client and server-side languages uently will lose some momentum

when they have to switch between them.

2. The user experience vastly improves when everything we need to run the

application is already downloaded and available. Because the majority of

the logic and application processing is done client side, we are no longer

dependent upon network requests or additional downloads before moving

the user forward. And as the JavaScript engines in all modern browsers get

continually faster with each release, even computationally intense processes

are becoming less and less of a limiting factor.

Chapter 1

[ 7 ]

These reasons can make a signicant difference in even the smallest of applications,

even if it's only in your own peace of mind while developing. As you begin to tackle

larger projects, however, especially if you're working on a distributed team, modular

code that all builds on top of the same data-model becomes mission-critical; without

it, each bit of functionality might expect a different property, ag, or (brace yourself)

classname to represent the appropriate state for your application. In contrast, when

your code is data-driven, everyone can work off the same built-in value map,

allowing different pieces to connect far more seamlessly.

Now that we've claried what frontend development isn't, let's gets back to the

key principles that lead to great frontend application code.

Modularity

The principle of modularity is hardly specic to frontend web applications, and most

developers these days recognize its usefulness, so I won't spend a lot of time here,

but it's worth a quick overview.

The primary goal of modularity is to ensure that the code you write can be reused

in different parts of the same application, or even in different applications entirely,

without requiring extensive re-architecting. This also helps ensure that a change to

the internal logic of one feature doesn't negatively impact the functionality of any

other. In his article, Patterns For Large-Scale JavaScript Application Architecture, Addy

Osmani describes it as:

Decouple app. architecture w/module,facade & mediator patterns. Mods publish

msgs, mediator acts as pub/sub mgr & facade handles security.

In non-twitter speak, the basic goal is to make sure each feature/module keeps

track of its own data/state/existence, is not dependent on the behavior of any other

module to perform its own functionality, and uses messages to alert other modules

to its own changes and appropriately respond to the changes of others.

We'll dive into modularity in great detail in the coming chapters, as it's one of the

core principles of Angular Directives, so for now we'll leave this summary here,

and continue to the next key principle for frontend web applications.

Chapter 1

[ 9 ]

And nally the JavaScript:

function WidgetController ($scope) {

$scope.tweets = [];//loaded from JSON data above

}

While the preceding example does operate within the Angular framework, the basic

structure here is representative of all good frontend architectures.

Let's rst take a high-level view of what's happening here. The rst thing to note is

that the data itself is most important. I listed it rst not because it was shortest, but

to illustrate that the data is the foundation from which the rest of the code evolves.

After the data, we move onto the HTML. This is most applicable in Angular, though

it applies to other frameworks as well. In this model, once we have the data, we use

the HTML to describe the view, how we want to display the data, and also (jQuery

acionados, brace yourselves) how we want the user to interact with that data. Only

then, at the end, do we write the little JavaScript code needed to glue it all together

as the controller. From here, let's walk through it stepwise to see how everything

works together.

Loading the data

When we rst initialize our application, the rst thing we need to do is load our data.

In Angular, this is most commonly done through a service, which, while a vital part

of Angular development, is outside the scope of this book. For now, let's just assume

that we've already loaded our data into $scope.tweets. We'll dissect $scope in great

detail later in Chapter 5, Keeping it Clean with Scope, so for the purpose of this example,

just know that it serves as the link between the view and our data.

Structuring our HTML

Let's revisit the main element of our widget, the tweet paragraph tag:

@{{tweet.author}}: {{tweet.text}}

</p>

The rst part of the HTML code uses the ng-repeat attribute to declare (again,

remember we're building our HTML on top of the data-model, not receiving a

model and remolding the HTML to reect it) that we want to iterate through the

array of tweets and print out for each the author's handle and their tweets in a

paragraph tag.

www.allitebooks.com

剩余109页未读，继续阅读

vanridin

粉丝: 108
资源: 1188

构建动态AngularJS指令：提升单页应用的交互与模块化

Mastering angularJS Directives

AngularJS Directives

Matering AngularJS Directives

angularjs学习路线图

angularjs教程

angularjs ui-view

vue中局部引入外部directives的指令

angularjs select

vue-property-decorator的directives

directives

最新资源