javascript - "Pensando em AngularJS" se eu tiver um fundo jQuery?




(10)

Você pode descrever a mudança de paradigma que é necessária?

Imperativo vs Declarativo

Com jQuery, você diz ao DOM o que precisa acontecer, passo a passo. Com o AngularJS você descreve os resultados que deseja, mas não como fazê-lo. Mais sobre isso here . Além disso, confira a resposta de Mark Rajcok.

Como faço para arquitetar e projetar aplicativos da Web do lado do cliente de maneira diferente?

O AngularJS é uma estrutura inteira do lado do cliente que usa o padrão MVC (confira sua representação gráfica ). Foca muito na separação de interesses.

Qual é a maior diferença? O que devo parar de fazer / usar; o que devo começar a fazer / usar em vez disso?

jQuery é uma biblioteca

O AngularJS é um belo framework do lado do cliente, altamente testável, que combina toneladas de coisas legais, como MVC, injeção de dependência , vinculação de dados e muito mais.

Ele se concentra na separação de interesses e testes (testes de unidade e testes de ponta a ponta), o que facilita o desenvolvimento orientado a testes.

A melhor maneira de começar é através do seu incrível tutorial . Você pode percorrer as etapas em algumas horas; no entanto, caso você queira dominar os conceitos nos bastidores, eles incluem uma miríade de referências para leitura adicional.

Há alguma consideração / restrição do lado do servidor?

Você pode usá-lo em aplicativos existentes onde você já está usando o jQuery puro. No entanto, se você quiser aproveitar totalmente os recursos do AngularJS, considere codificar o lado do servidor usando uma abordagem RESTful .

Isso permitirá que você aproveite a fábrica de recursos , que cria uma abstração da API RESTful do lado do servidor e torna as chamadas do servidor (obter, salvar, excluir, etc.) incrivelmente fáceis.

Suponha que eu esteja familiarizado com o desenvolvimento de aplicativos do lado do cliente no jQuery , mas agora gostaria de começar a usar o AngularJS . Você pode descrever a mudança de paradigma que é necessária? Aqui estão algumas perguntas que podem ajudá-lo a formular uma resposta:

  • Como faço para arquitetar e projetar aplicativos da Web do lado do cliente de maneira diferente? Qual é a maior diferença?
  • O que devo parar de fazer / usar; O que devo começar a fazer / usar em vez disso?
  • Há alguma consideração / restrição do lado do servidor?

Eu não estou procurando uma comparação detalhada entre jQuery e AngularJS .


1. Não crie sua página e altere-a com manipulações DOM

No jQuery, você cria uma página e, em seguida, a torna dinâmica. Isso ocorre porque o jQuery foi projetado para aumento e cresceu incrivelmente a partir dessa premissa simples.

Mas no AngularJS, você deve começar do zero com sua arquitetura em mente. Em vez de começar pensando "Eu tenho essa parte do DOM e quero fazer X", você precisa começar com o que deseja realizar, depois projetar seu aplicativo e, finalmente, projetar sua visualização.

2. Não aumente o jQuery com o AngularJS

Da mesma forma, não comece com a idéia de que o jQuery faz X, Y e Z, então adicionarei o AngularJS em cima disso para modelos e controladores. Isso é realmente tentador quando você está apenas começando, e é por isso que eu sempre recomendo que os novos desenvolvedores do AngularJS não usem o jQuery, pelo menos até que eles se acostumem a fazer as coisas como o "Angular Way".

Eu vi muitos desenvolvedores aqui e na lista de discussão criarem essas soluções elaboradas com plugins jQuery de 150 ou 200 linhas de código que eles então colam no AngularJS com uma coleção de callbacks e $apply s que são confusos e complicados; mas eles eventualmente conseguem trabalhar! O problema é que na maioria dos casos o plugin jQuery pode ser reescrito em AngularJS em uma fração do código, onde de repente tudo se torna compreensível e direto.

A linha inferior é esta: ao resolver, primeiro "pense em AngularJS"; se você não consegue pensar em uma solução, pergunte à comunidade; se depois de tudo isso não houver uma solução fácil, sinta-se à vontade para encontrar o jQuery. Mas não deixe o jQuery se tornar uma muleta ou você nunca vai dominar o AngularJS.

3. Sempre pense em termos de arquitetura

Primeiro, saiba que aplicativos de uma única página são aplicativos . Eles não são páginas da web. Portanto, precisamos pensar como um desenvolvedor do lado do servidor, além de pensar como um desenvolvedor do lado do cliente. Temos que pensar em como dividir nosso aplicativo em componentes individuais, extensíveis e testáveis.

Então, como você faz isso? Como você "pensa em AngularJS"? Aqui estão alguns princípios gerais, contrastados com jQuery.

A visão é o "registro oficial"

No jQuery, nós programaticamente alteramos a exibição. Poderíamos ter um menu suspenso definido como ul assim:

<ul class="main-menu">
    <li class="active">
        <a href="#/home">Home</a>
    </li>
    <li>
        <a href="#/menu1">Menu 1</a>
        <ul>
            <li><a href="#/sm1">Submenu 1</a></li>
            <li><a href="#/sm2">Submenu 2</a></li>
            <li><a href="#/sm3">Submenu 3</a></li>
        </ul>
    </li>
    <li>
        <a href="#/home">Menu 2</a>
    </li>
</ul>

Em jQuery, em nossa lógica de aplicativo, nós o ativamos com algo como:

$('.main-menu').dropdownMenu();

Quando olhamos apenas para a visão, não é imediatamente óbvio que haja alguma funcionalidade aqui. Para pequenas aplicações, tudo bem. Mas, para aplicativos não triviais, as coisas ficam confusas e difíceis de manter.

No AngularJS, no entanto, a visão é o registro oficial da funcionalidade baseada em visão. Nossa declaração ul seria assim:

<ul class="main-menu" dropdown-menu>
    ...
</ul>

Esses dois fazem a mesma coisa, mas na versão do AngularJS qualquer um que olhar o modelo sabe o que deve acontecer. Sempre que um novo membro da equipe de desenvolvimento entra em cena, ela pode ver isso e saber que existe uma diretiva chamada dropdownMenu operando nele; ela não precisa intuir a resposta certa ou filtrar qualquer código. A visão nos dizia o que deveria acontecer. Muito mais limpo.

Desenvolvedores novatos no AngularJS muitas vezes fazem uma pergunta como: como eu encontro todos os links de um tipo específico e adiciono uma diretiva a eles. O desenvolvedor está sempre espantado quando respondemos: você não. Mas a razão pela qual você não faz isso é que isso é meio jQuery, meio AngularJS e não é bom. O problema aqui é que o desenvolvedor está tentando "fazer jQuery" no contexto do AngularJS. Isso nunca vai funcionar bem. A visão é o registro oficial. Fora de uma diretiva (mais sobre isso abaixo), você nunca, nunca, nunca muda o DOM. E diretivas são aplicadas na visão , então a intenção é clara.

Lembre-se: não projete e marque. Você deve arquitetar e depois projetar.

Ligação de dados

Esta é de longe uma das características mais impressionantes do AngularJS e elimina a necessidade de fazer os tipos de manipulações de DOM que mencionei na seção anterior. O AngularJS atualizará automaticamente sua visualização para que você não precise! No jQuery, respondemos a eventos e, em seguida, atualizamos o conteúdo. Algo como:

$.ajax({
  url: '/myEndpoint.json',
  success: function ( data, status ) {
    $('ul#log').append('<li>Data Received!</li>');
  }
});

Para uma visão assim:

<ul class="messages" id="log">
</ul>

Além de misturar preocupações, também temos os mesmos problemas de intenção significativa que mencionei antes. Mas, mais importante, tivemos que fazer referência e atualizar manualmente um nó DOM. E se quisermos excluir uma entrada de log, temos que codificar o DOM para isso também. Como podemos testar a lógica para além do DOM? E se quisermos mudar a apresentação?

Isso é um pouco confuso e um pouco frágil. Mas no AngularJS, podemos fazer isso:

$http( '/myEndpoint.json' ).then( function ( response ) {
    $scope.log.push( { msg: 'Data Received!' } );
});

E nossa visão pode ser assim:

<ul class="messages">
    <li ng-repeat="entry in log">{{ entry.msg }}</li>
</ul>

Mas, para essa questão, nossa visão poderia ser assim:

<div class="messages">
    <div class="alert" ng-repeat="entry in log">
        {{ entry.msg }}
    </div>
</div>

E agora, em vez de usar uma lista não ordenada, estamos usando caixas de alerta do Bootstrap. E nós nunca tivemos que mudar o código do controlador! Mas o mais importante, não importa onde ou como o log é atualizado, a exibição também será alterada. Automaticamente. Arrumado!

Embora eu não tenha mostrado aqui, a vinculação de dados é bidirecional. Então, essas mensagens de log também podem ser editadas na visualização apenas fazendo isso: <input ng-model="entry.msg" /> . E havia muita alegria.

Camada de modelo distinta

No jQuery, o DOM é como o modelo. Mas no AngularJS, temos uma camada de modelo separada que podemos gerenciar da maneira que quisermos, de forma totalmente independente da exibição. Isso ajuda na vinculação de dados acima, mantém a separação de interesses e introduz testabilidade muito maior. Outras respostas mencionaram esse ponto, então vou deixar por aqui mesmo.

Separação de preocupações

E todos os itens acima se encaixam neste tema abrangente: mantenha suas preocupações separadas. Sua opinião age como o registro oficial do que é suposto acontecer (na maioria das vezes); seu modelo representa seus dados; você tem uma camada de serviço para executar tarefas reutilizáveis; você faz manipulação de DOM e aumenta sua visão com diretivas; e você cola tudo junto com os controladores. Isso também foi mencionado em outras respostas, e a única coisa que gostaria de acrescentar diz respeito à testabilidade, que discuto em outra seção abaixo.

Injeção de dependência

Para nos ajudar com a separação das preocupações, está a injeção de dependência (DI). Se você vem de uma linguagem do lado do servidor (do Java para o PHP ) provavelmente já está familiarizado com esse conceito, mas se você é um cara do lado do cliente vindo da jQuery, esse conceito pode parecer de bobo a supérfluo a moderno . Mas isso não. :-)

De uma perspectiva ampla, DI significa que você pode declarar componentes muito livremente e, em seguida, a partir de qualquer outro componente, basta solicitar uma instância e será concedido. Você não precisa saber sobre a ordem de carregamento, localização de arquivos ou qualquer coisa assim. O poder pode não ser imediatamente visível, mas vou fornecer apenas um exemplo (comum): teste.

Digamos que em nosso aplicativo, exigimos um serviço que implemente o armazenamento no servidor por meio de uma API REST e, dependendo do estado do aplicativo, também do armazenamento local. Ao executar testes em nossos controladores, não queremos ter que nos comunicar com o servidor - afinal, estamos testando o controlador . Podemos apenas adicionar um serviço falso com o mesmo nome do nosso componente original, e o injetor irá garantir que nosso controlador receba o falso automaticamente - nosso controlador não precisa e não precisa saber a diferença.

Falando em testes ...

4. Desenvolvimento orientado a testes - sempre

Isso é realmente parte da seção 3 da arquitetura, mas é tão importante que eu a coloque como sua própria seção de nível superior.

De todos os muitos plugins do jQuery que você viu, usou ou escreveu, quantos deles tinham um conjunto de testes? Não são muitos, porque o jQuery não é muito receptivo a isso. Mas o AngularJS é.

No jQuery, a única maneira de testar é criar o componente independentemente com uma página de amostra / demonstração na qual nossos testes podem executar a manipulação DOM. Então temos que desenvolver um componente separadamente e depois integrá-lo em nossa aplicação. Quão inconveniente! Na maioria das vezes, quando desenvolvemos com jQuery, optamos pelo desenvolvimento iterativo em vez de orientado a testes. E quem poderia nos culpar?

Mas como temos separação de interesses, podemos fazer um desenvolvimento orientado a testes de forma iterativa no AngularJS! Por exemplo, digamos que queremos que uma diretiva super-simples indique em nosso menu qual é a rota atual. Podemos declarar o que queremos na visão de nossa aplicação:

<a href="/hello" when-active>Hello</a>

Ok, agora podemos escrever um teste para a diretiva inexistente when-active :

it( 'should add "active" when the route changes', inject(function() {
    var elm = $compile( '<a href="/hello" when-active>Hello</a>' )( $scope );

    $location.path('/not-matching');
    expect( elm.hasClass('active') ).toBeFalsey();

    $location.path( '/hello' );
    expect( elm.hasClass('active') ).toBeTruthy();
}));

E quando executamos nosso teste, podemos confirmar que ele falha. Só agora devemos criar nossa diretiva:

.directive( 'whenActive', function ( $location ) {
    return {
        scope: true,
        link: function ( scope, element, attrs ) {
            scope.$on( '$routeChangeSuccess', function () {
                if ( $location.path() == element.attr( 'href' ) ) {
                    element.addClass( 'active' );
                }
                else {
                    element.removeClass( 'active' );
                }
            });
        }
    };
});

Nosso teste agora é aprovado e nosso menu é executado conforme solicitado. Nosso desenvolvimento é interativo e orientado a testes. Mau-legal.

5. Conceitualmente, diretivas não são empacotadas jQuery

Você frequentemente ouvirá "somente manipulação DOM em uma diretiva". Isso é uma necessidade. Trate-o com a devida deferência!

Mas vamos mergulhar um pouco mais fundo ...

Algumas diretivas apenas decoram o que já está na view (pense ngClass ) e, portanto, às vezes, manipulam o DOM imediatamente e depois são feitas basicamente. Mas se uma diretiva é como um "widget" e tem um modelo, também deve respeitar a separação de interesses. Ou seja, o modelo também deve permanecer amplamente independente de sua implementação nas funções de link e controlador.

O AngularJS vem com um conjunto completo de ferramentas para tornar isso muito fácil; com ngClass podemos atualizar dinamicamente a classe; ngModel permite vinculação de dados bidirecional; ngShow e ngHide programaticamente mostram ou ocultam um elemento; e muito mais - incluindo os que nós mesmos escrevemos. Em outras palavras, podemos fazer todos os tipos de grandeza sem manipulação de DOM. Quanto menos manipulação de DOM, mais fáceis são as diretivas para testar, mais fáceis são para estilizar, mais fáceis de alterar no futuro e mais reutilizáveis ​​e distribuíveis.

Eu vejo muitos desenvolvedores novos no AngularJS usando diretivas como o lugar para jogar um monte de jQuery. Em outras palavras, eles pensam "desde que eu não posso fazer manipulação DOM no controlador, eu vou tomar esse código colocá-lo em uma diretiva". Enquanto isso certamente é muito melhor, muitas vezes ainda está errado .

Pense no logger que nós programamos na seção 3. Mesmo se colocarmos isso em uma diretiva, nós ainda queremos fazer o "Angular Way". Ainda não há manipulação de DOM! Há muitas ocasiões em que a manipulação do DOM é necessária, mas é muito mais rara do que você pensa! Antes de manipular o DOM em qualquer lugar da sua aplicação, pergunte-se se realmente precisa. Pode haver um caminho melhor.

Aqui está um exemplo rápido que mostra o padrão que vejo com mais frequência. Nós queremos um botão de toggle. (Nota: este exemplo é um pouco artificial e um texto detalhado para representar casos mais complicados que são resolvidos exatamente da mesma maneira.)

.directive( 'myDirective', function () {
    return {
        template: '<a class="btn">Toggle me!</a>',
        link: function ( scope, element, attrs ) {
            var on = false;

            $(element).click( function () {
                on = !on;
                $(element).toggleClass('active', on);
            });
        }
    };
});

Há algumas coisas erradas com isso:

  1. Primeiro, o jQuery nunca foi necessário. Não há nada que fizemos aqui que precisasse de jQuery!
  2. Segundo, mesmo que já tenhamos jQuery em nossa página, não há razão para usá-lo aqui; podemos simplesmente usar o angular.element e o nosso componente ainda funcionará quando inserido em um projeto que não tenha o jQuery.
  3. Em terceiro lugar, mesmo supondo que o jQuery foi necessário para esta diretiva funcionar, jqLite ( angular.element ) sempre usará o jQuery se ele foi carregado! Então, não precisamos usar o $ - podemos usar apenas angular.element .
  4. Quarto, intimamente relacionado ao terceiro, é que os elementos jqLite não precisam ser agrupados em $ - o element que é passado para a função link já seria um elemento jQuery!
  5. E quinto, que mencionamos nas seções anteriores, por que estamos misturando material de modelo em nossa lógica?

Esta diretiva pode ser reescrita (mesmo para casos muito complicados!) Muito mais simplesmente assim:

.directive( 'myDirective', function () {
    return {
        scope: true,
        template: '<a class="btn" ng-class="{active: on}" ng-click="toggle()">Toggle me!</a>',
        link: function ( scope, element, attrs ) {
            scope.on = false;

            scope.toggle = function () {
                scope.on = !scope.on;
            };
        }
    };
});

Novamente, o material do template está no template, então você (ou seus usuários) podem facilmente trocá-lo por um que atenda a qualquer estilo necessário, e a lógica nunca precisou ser tocada. Reutilização - boom!

E ainda existem todos esses outros benefícios, como teste - é fácil! Não importa o que está no modelo, a API interna da diretiva nunca é tocada, portanto, a refatoração é fácil. Você pode alterar o modelo o quanto quiser sem tocar na diretiva. E não importa o que você mude, seus testes ainda passam.

w00t!

Portanto, se diretivas não são apenas coleções de funções semelhantes à jQuery, o que são elas? Diretivas são, na verdade, extensões de HTML . Se o HTML não faz algo que você precisa fazer, você escreve uma diretiva para fazer isso para você, e então usa como se fosse parte do HTML.

Dito de outra maneira, se o AngularJS não fizer algo ngClick , pense em como a equipe conseguiria se encaixar bem com ngClick , ngClass , et al.

Resumo

Nem use jQuery. Nem inclua isso. Ele vai te segurar de volta. E quando você chegar a um problema que você acha que já sabe como resolver em jQuery, antes de pegar o $ , tente pensar em como fazê-lo dentro dos limites do AngularJS. Se você não sabe, pergunte! 19 vezes em 20, a melhor maneira de fazer isso não precisa do jQuery e tentar resolvê-lo com o jQuery resulta em mais trabalho para você.


jQuery

O jQuery faz comandos JavaScript ridiculamente longos, como getElementByHerpDerpnavegadores curtos e cross-browser.

AngularJS

O AngularJS permite que você crie suas próprias tags / atributos HTML que fazem coisas que funcionam bem com aplicativos da Web dinâmicos (já que o HTML foi projetado para páginas estáticas).

Editar:

Dizendo "Eu tenho um fundo jQuery como eu penso em AngularJS?" é como dizer "eu tenho um fundo HTML como eu penso em JavaScript?" O fato de você estar fazendo a pergunta mostra que você provavelmente não entende os propósitos fundamentais desses dois recursos. É por isso que escolhi responder à pergunta simplesmente apontando a diferença fundamental em vez de ler a lista dizendo "O AngularJS faz uso de diretivas enquanto o jQuery usa seletores CSS para fazer um objeto jQuery que faz isto e aquilo etc ..." . Esta questão não requer uma resposta demorada.

O jQuery é uma maneira de facilitar a programação de JavaScript no navegador. Comandos mais curtos, entre navegadores, etc.

O AngularJS estende o HTML, então você não precisa colocar <div>todo o lugar apenas para criar um aplicativo. Isso faz com que o HTML realmente funcione para aplicativos, e não para o que foi projetado, que é páginas da Web estáticas e educacionais. Isso é feito de maneira indireta usando JavaScript, mas fundamentalmente é uma extensão do HTML, não do JavaScript.


Imperativo → declarativo

No jQuery, os seletores são usados ​​para localizar elementos DOM e, em seguida, vincular / registrar manipuladores de eventos a eles. Quando um evento é acionado, esse código (imperativo) é executado para atualizar / alterar o DOM.

No AngularJS, você quer pensar em views em vez de elementos DOM. As visualizações são HTML (declarativo) que contêm diretivas AngularJS. As diretivas definem os manipuladores de eventos nos bastidores para nós e nos dão uma ligação de dados dinâmica. Os seletores raramente são usados, então a necessidade de IDs (e alguns tipos de classes) é muito reduzida. As visualizações estão vinculadas aos modelos (via escopos). Visualizações são uma projeção do modelo. Os modelos de mudança de eventos (isto é, dados, propriedades do escopo) e as exibições que projetam esses modelos são atualizados "automaticamente".

No AngularJS, pense em modelos, em vez de elementos DOM selecionados por jQuery que armazenam seus dados. Pense nas exibições como projeções desses modelos, em vez de registrar retornos de chamada para manipular o que o usuário vê.

Separação de preocupações

jQuery emprega JavaScript discreto - comportamento (JavaScript) é separado da estrutura (HTML).

O AngularJS usa controladores e diretivas (cada qual pode ter seu próprio controlador, e / ou compilar e vincular funções) para remover o comportamento da view / structure (HTML). Angular também tem serviços e filtros para ajudar a separar / organizar seu aplicativo.

Veja também https://.com/a/14346528/215945

Design da aplicação

Uma abordagem para projetar um aplicativo AngularJS:

  1. Pense nos seus modelos. Crie serviços ou seus próprios objetos JavaScript para esses modelos.
  2. Pense em como você deseja apresentar seus modelos - seus pontos de vista. Crie modelos HTML para cada visualização, usando as diretivas necessárias para obter a ligação de dados dinâmica.
  3. Anexe um controlador a cada visualização (usando ng-view e routing ou ng-controller). Peça ao controlador para localizar / obter apenas os dados do modelo que a visão precisa para fazer seu trabalho. Faça controladores o mais fino possível.

Herança Prototypal

Você pode fazer muito com o jQuery sem saber como funciona a herança prototípica do JavaScript. Ao desenvolver aplicativos AngularJS, você evitará algumas armadilhas comuns se tiver uma boa compreensão da herança do JavaScript. Leitura recomendada: Quais são as nuances do escopo protótipo / herança prototípica em AngularJS?


Essas são algumas respostas muito agradáveis, mas longas.

Para resumir minhas experiências:

  1. Controladores e provedores (serviços, fábricas, etc.) são para modificar o modelo de dados, NÃO HTML.
  2. HTML e diretivas definem o layout e a vinculação ao modelo.
  3. Se você precisar compartilhar dados entre controladores, crie um serviço ou uma fábrica - eles são singletons que são compartilhados pelo aplicativo.
  4. Se você precisar de um widget HTML, crie uma diretiva.
  5. Se você tem alguns dados e agora está tentando atualizar o HTML ... PARE! atualize o modelo e verifique se o HTML está vinculado ao modelo.

Para descrever a "mudança de paradigma", acho que uma resposta curta pode ser suficiente.

AngularJS muda a maneira de encontrar elementos

No jQuery , você normalmente usa seletores para encontrar elementos e, em seguida, conecta-os:
$('#id .class').click(doStuff);

No AngularJS , você usa diretivas para marcar os elementos diretamente, para conectá-los:
<a ng-click="doStuff()">

Não AngularJS não precisa (ou quer)-lo a encontrar elementos usando seletores - a principal diferença entre das AngularJS jqLite contra full-blown jQuery é que jqLite não suporta seletores .

Então, quando as pessoas dizem "não inclua jQuery", é principalmente porque elas não querem que você use seletores; eles querem que você aprenda a usar diretivas. Direto, não selecione!


Acho essa questão interessante, porque minha primeira exposição séria à programação de JavaScript foi Node.js e AngularJS. Eu nunca aprendi o jQuery, e acho que isso é bom, porque não tenho que desaprender nada. Na verdade, eu evito ativamente as soluções da jQuery para os meus problemas e, em vez disso, procuro apenas uma "maneira AngularJS" para resolvê-los. Então, eu acho que minha resposta a essa pergunta essencialmente se resumiria a: "pense como alguém que nunca aprendeu jQuery" e evite qualquer tentação de incorporar o jQuery diretamente (obviamente, o AngularJS o usa até certo ponto nos bastidores).


Como um iniciante em JavaScript MV * e puramente focado na arquitetura do aplicativo (não no servidor / cliente), eu certamente recomendaria o seguinte recurso (que me surpreende não ter sido mencionado ainda): JavaScript Design Patterns , por Addy Osmani , como uma introdução a diferentes padrões de design JavaScript . Os termos usados ​​nesta resposta são extraídos do documento vinculado acima. Eu não vou repetir o que foi escrito muito bem na resposta aceita. Em vez disso, esta resposta conecta de volta aos fundamentos teóricos que dão poder ao AngularJS (e outras bibliotecas).

Como eu, você perceberá rapidamente que o AngularJS (ou Ember.js , Durandal e outros frameworks MV *) é uma estrutura complexa que monta muitos dos diferentes padrões de design JavaScript.

Também achei mais fácil testar código JavaScript nativo (1) e (2) bibliotecas menores para cada um desses padrões separadamente antes de mergulhar em uma estrutura global. Isso permitiu que eu compreendesse melhor quais questões cruciais um quadro aborda (porque você está pessoalmente enfrentando o problema).

Por exemplo:

  • Programação orientada a objetos JavaScript (este é um link de pesquisa do Google). Não é uma biblioteca, mas certamente um pré-requisito para qualquer programação de aplicativos. Ensinou-me as implementações nativas dos padrões de protótipo, construtor, singleton & decorator
  • jQuery / Underscore para o padrão de fachada (como o WYSIWYG para manipular o DOM)
  • Prototype.js para o padrão protótipo / construtor / mixin
  • RequireJS / Curl.js para o padrão de módulo / AMD
  • KnockoutJS para o padrão observável de publicação / assinatura

NB: Esta lista não está completa nem "as melhores bibliotecas"; eles simplesmente são as bibliotecas que eu usei. Essas bibliotecas também incluem mais padrões, os mencionados são apenas seus principais focos ou intenções originais. Se você sentir que algo está faltando nessa lista, por favor mencione nos comentários, e terei prazer em adicioná-lo.


Na verdade, se você estiver usando o AngularJS, não precisa mais do jQuery. AngularJS em si tem a ligação e diretiva, que é um bom "substituto" para a maioria das coisas que você pode fazer com jQuery.

Eu costumo desenvolver aplicativos móveis usando AngularJS e Cordova . A única coisa da jQuery que eu precisava era do Seletor.

Ao pesquisar, vejo que há um módulo seletor independente do jQuery por aí. É o Sizzle.

E decidi fazer um pequeno trecho de código que me ajudasse a iniciar rapidamente um site usando o AngularJS com o poder do jQuery Selector (usando o Sizzle).

Eu compartilhei meu código aqui: https://github.com/huytd/Sizzular


Ouça o podcast JavaScript Jabber: Episode # 32, que apresenta os criadores originais do AngularJS: Misko Hevery e Igor Minar. Eles falam muito sobre como é chegar ao AngularJS a partir de outros fundos JavaScript, especialmente o jQuery.

Um dos pontos apresentados no podcast fez muitas coisas clicarem para mim com respeito à sua pergunta:

MISKO : [...] uma das coisas que pensamos muito pouco em Angular é, como nós fornecemos muitas escotilhas de escape para que você possa sair e, basicamente, descobrir uma saída para isso. Então, para nós, a resposta é essa coisa chamada “diretivas”. E com diretivas, você basicamente se torna um pequeno jQuery JavaScript comum, você pode fazer o que quiser.

IGOR : Então pense em diretiva como a instrução para o compilador que informa sempre que você se deparar com este determinado elemento ou este CSS no modelo, e você mantém esse tipo de código e esse código é responsável pelo elemento e tudo abaixo daquele elemento na árvore DOM.

Uma transcrição de todo o episódio está disponível no link fornecido acima.

Então, para responder diretamente a sua pergunta: AngularJS é - muito opinativo e é um verdadeiro framework MV *. No entanto, você ainda pode fazer todas as coisas muito legais que você conhece e adora com jQuery dentro de diretivas. Não é uma questão de "Como faço o que eu costumava fazer no jQuery?" tanto quanto é uma questão de "Como eu complemento o AngularJS com todas as coisas que eu costumava fazer no jQuery?"

São realmente dois estados mentais muito diferentes.





angularjs