Angular-styleguide: Namespacing de componentes

Um componente é apenas um wrapper de diretiva sem funções de compilação ou link. Portanto, apenas use a mesma convenção que está usando para as diretivas.

Eles não são os mesmos .. por exemplo. componentes têm escopo isolado por padrão, eles usam o controlador Como por padrão, o controlador substitui a função de link e bindToController é verdadeiro por padrão.

Tudo o que você pode fazer com o componente pode ser obtido com uma diretiva, mas o motivo da existência do componente é para tornar a transição para o angular 2 mais fácil.

Você pode ler sobre mais recursos aqui: http://www.codelord.net/2015/12/17/angulars-component-what-is-it-good-for/

Então, isso será adicionado?

Alguma sugestão ou dica sobre isso?

@samithaf usando separadores de ponto limita você quando se trata de seletores css.

Usar pontos não deve limitar você (por exemplo, você pode escapar deles em seletores CSS), mas é complicado e não convencional.

Há anos que as pessoas usam - para componentes de namespacing e não vejo razão para usar qualquer outro separador.

@mackelito @blowsie @gkalpak Estou usando o seguinte padrão em um aplicativo financeiro de grande escala (100K + LOC) e até agora está tudo bem. Como você pode ver, estou usando separadores de pontos para que tudo seja consistente. Porém, exceto para filtros. Com os estilos, você pode escapar do ponto.

const loginModule = angular.module('app.core.login', [])
.component('app.core.login', loginComponent)
.service('app.core.login.loginService', loginService);

@samithaf como você injeta serviços em seu controlador? Presumo que você tenha que usar a abordagem ['app.core.login.loginService' , function(loginService) {}] ?

@blowsie mostra o uso do serviço de login da seguinte forma.

class LoginController {
  constructor($q, loginService) {
    this.loginService = loginService;
  }

  /**
   * <strong i="7">@method</strong> $onInit
   * This lifecycle hook will be executed when all controllers on an element have been constructed and after their bindings are initialized
   */
  $onInit() {
    this.loginService.invalidateSession();
  }

}

LoginController.$inject = ['$q', 'nw.core.login.loginService'];

export default LoginController;

É muito bom para serviços, mas para componentes é muito estranho:

<div><app.core.login></app.core.login></div>

E é inconsistente com o mundo ao redor (todos estão usando - como @gkalpak disse).

Tenho certeza de que o aplicativo @samithaf é bom com isso, mas há uma diferença entre uma convenção de nomenclatura estranha que funciona bem em um projeto e o que deve ser definido em um guia de estilo global.

A questão central aqui é: o injetor AngularJS é plano, então precisamos pensar globalmente ao nomear os componentes do módulo. Esta é uma falha de projeto corrigida no Angular. Mudar uma convenção central ( - para namespacing) usada desde o início por quase todos não é uma maneira de ir IMHO.

Olá @MarcLoupias, como você mencionou, já que o DI angular é plano, não podemos fazer muito. Mas, ao definir nomes de módulo sem um namespace, pode facilmente introduzir efeitos colaterais. Especialmente em um projeto de grande escala, onde você tem mais de 10 times scrum trabalhando. Mesmo a solução que encontrei não está alinhada com a convenção, não consigo pensar em outra boa maneira de resolver esse problema. Teria sido bom se a equipe Angular atribuísse nomes aos módulos automaticamente. Mas eu não acho que isso vá acontecer com o angular 1.X;)

Mas, ao definir nomes de módulo sem um namespace, pode facilmente introduzir efeitos colaterais.

Sim, na fase de inicialização do injetor, o comportamento do injetor é ignorar silenciosamente o serviço já declarado no injetor com o último a declarar.

Especialmente em um projeto de grande escala, onde você tem mais de 10 times scrum trabalhando.

É algo como 50+ desenvolvedores!

Não consigo pensar em outra boa maneira de resolver esse problema.

Dividir sua empresa em vários aplicativos? O AngularJS não é realmente adequado para projetos enormes devido a essa falha de design do namespace do injetor.