Por que você deve usar $ scope

Componentes do rock AngularJS!

Depois de ler alguns posts sobre como evitar o uso de $ scope, fiquei confuso. Eu li aqui e ali sobre todas as coisas ruins que podem acontecer ao usar $ scope em controladores aninhados, usando ng-controller em seu HTML. Para quem não sabe do que estou falando, aqui está um pequeno exemplo:

<div ng-controller="ParentController">
  ParentController: <input type="text" ng-model="foo" />
  <div ng-controller="ChildController">
    ChildController: <input type="text" ng-model="foo" />
  </div>
</div>

O problema aqui tem a ver com a maneira como as propriedades são vinculadas a objetos em Javascript. Eu poderia entender muito bem esse problema, mas por que nunca havia encontrado problemas antes? Porque usar controladores aninhados não é o caminho a seguir.

Componentes

Para entender o problema, recomendo a leitura da postagem do blog que criei um link antes. Vou me limitar a explicar por que nunca tive problemas: componentes. Com o MVC em mente, trabalhar com componentes é muito intuitivo, cria uma base de código compreensível e oferece muita capacidade de reutilização. Como o AngularJS ainda não tem um padrão de codificação, todo mundo meio que faz suas próprias coisas.

Dê uma olhada na seguinte estrutura de pastas, com base em um projeto em que trabalhei.

app
├── app.module.js
├── app.routes.js
├── components
│  ├── auth
│  │   ├── auth.controllers.js
│  │   └── views
│  │       ├── login.view.html
│  │       └── logout.view.html
│  └── categories
│  │   ├── category.controllers.js
│  │   └── views
│  │       ├── form.view.html
│  │       └── list.view.html
│  └── materials
│      ├── material.controllers.js
│      └── views
│          ├── form.view.html
│          ├── detail.view.html
│          └── list.view.html
└── shared
   ├── directives
   │  ├── list
   │  │    ├── list.directives.js
   │  │    └── views
   │  │        ├── tableList.view.html
   │  │        └── sortableList.view.html
   ├── filters
   │  ├── html.filters.js
   │  └── date.filters.js
   └── services
      ├── api.services.js
      └── auth.services.js

Usando uma abordagem baseada em componentes, você só precisa de um controlador em todos os momentos. Um para cada componente. Como você pode ver no exemplo acima, eu divido os componentes com base na funcionalidade principal. Cada subpasta de componentes possui, na verdade, vários componentes: os arquivos controllers.js contêm vários controladores (portanto, controllers.js). Cada controlador é vinculado por meio do arquivo app.routes.js a uma visualização. Esta visualização realmente representa um único componente. Você pode querer dividir seu código ainda mais, criando um único arquivo para cada controlador, o que é realmente incentivado pela equipe do AngularJS.

app
├── app.module.js
├── app.routes.js
└── components
   └── auth
       ├── login
       │   ├── controller.js
       │   └── view.html
       └── logout
           ├── controller.js
           └── view.html

Pode-se debater qual é a melhor maneira de nomear arquivos. Por exemplo. no primeiro exemplo, eu sempre sufixo meus arquivos como login.view.html ou material.controllers.js. No segundo exemplo, eu apenas os nomeio controller.js e view.html, porque você pode determinar a funcionalidade exata com base no caminho: auth / login / controller.js. Eu prefiro a primeira forma, mas acho que não há uma convenção real sobre isso. Uma coisa é certa: usando componentes, você usa apenas um controlador, combinado com uma visualização. Eles são combinados em app.routes.js assim.

.when('/auth/login', {
    controller: 'AuthLoginController',
    templateUrl: 'app/components/auth/login/view.html',
})

Eu acho o argumento sobre não usar $ scope um sinal de codificação bastante ruim, não por causa do argumento de herança, mas por causa da maneira como alguém teria que estruturar seu código antes que isso pudesse se tornar um problema.

Links

Uma estrutura AngularJS baseada em componentes

Mais sobre componentes

Leia este artigo no Medium