impJS / impAprendaJS

Grupo de estudos para pessoas que querem aprender JavaScript.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Semana 6 - Dúvidas

vitorbritto opened this issue · comments

Inicio: 23/03/2014 ~ Fim: 29/03/2014

Este tópico é dedicado para postagem de dúvidas referentes a Semana 6.

Instruções: https://github.com/impJS/impAprendaJS/wiki/Semana-6

Fala pessoal, tudo bem?

Será que vocês poderiam indicar materiais de qualidade (artigos, livros, ou compartilhar experiências próprias mesmo) falando sobre módulos de software? Tipo, vou iniciar uma aplicação, como pensar nos módulos? Como estruturar esses módulos de maneira correta, visando escalabilidade e fácil manutenção?

Sei que temos N padrões para criar módulos, entre eles um que gosto bastante é o Revealing Module Pattern. Também sei que existe AMD, require.js etc. Mas gostaria de dicas sobre como pensar na arquitetura do sistema mesmo, entendem?

Estou pesquisando aqui também enquanto isso. Por enquanto me deparei com este artigo e estou lendo pra ver se é bom: http://www.cs.cornell.edu/courses/cs3110/2012sp/lectures/lec07-modules/lec07.html.

Exemplo de módulo que comecei a fazer para o Quiz: http://pastebin.com/xdprv3WQ.

Cc: @vitorbritto @fdaciuk.

Fala @HenriqueSilverio! Bom, o formato de modularização vai depender do seu projeto. Vou mostrar como eu costumo fazer:

Dentro do workflow que postei no meu blog, normalmente para sites, eu separo os módulos por página, pois cada página normalmente tem uma funcionalidade diferente. Se houver algo que apareça em mais de uma página, então eu crio um módulo para isso também (carousel, slider, accordion, etc), mas faço a chamada deste somente para a página específica.

A minha ideia de separar em models e controllers é:
Em models, eu faço toda a parte de regra de negócio: consultas Ajax, validações, e métodos que retornam apenas valores puros (sem manipulação de DOM), etc.
Em controllers, eu consulto o model correspondente, faço o tratamento dos dados e tratamento de DOM, quando necessário.

No arquivo principal app.js, eu faço a centralização de todos os arquivos. Conforme a página que o usuário está, eu chamo os models e controllers necessários.

Todo controller tem um método "init()" que faz as chamadas de outros métodos necessários a inicialização desse módulo.

Estou escrevendo outro artigo deixando isso mais detalhado e exemplificado, pois não é algo que dá pra escrever em poucas linhas. Mas se tiver alguma dúvida, podemos trocar umas ideias para saná-las :)

O @vitorbritto comentou uma vez que estava usando o Browserify nos projetos dele. Com esse cara você consegue escrever usando o padrão CommonJS (mesmo do NodeJS), mas no client-side.

Não sei se ele usa algum outro formato, vamos aguardar o comentário dele xD

Então @HenriqueSilverio, tentarei cobrir todos os aspectos dos meus aplicativos web de maneira bem objetiva.

Eu trabalho de forma muito parecida com o modelo do @fdaciuk, uso o (Revealing) Module Pattern e Singleton na maioria dos projetos com algumas convenções para a nomenclatura diferenciadas.

Além disso, possuo 3 (três) níveis de modularização com JavaScript:

Nível 1

Composto por módulos presentes no diretório ./modules (ex.: ./modules/foo/foo.js, ./modules/bar/bar.js). Específico para projetos pequenos, onde o jQuery é opcional e integro em casos onde quero maior praticidade.

Nível 2

Utilizo um modelo MV* para projetos médios, onde a componentização/modularização é tratada com models e controllers (ex.: models/fooModel.js, controllers/fooController.js). As vezes, com o Backbone. Depende do tipo de projeto também.

Nível 3:

Para projetos em larga escala, os quais envolvem um escopo mais extenso, integro o Backbone. Estou montando um Stack com o Angular para futuros estudos e projetos também.

Nota:

Em termos de ferramentas, geralmente, uso estes 6 caras:

  • jQuery - Para projetos, os quais quero aliar a praticidade desse cara
  • Backbone - Para projetos de porte médio e grande
  • Undescore - Em todos os projetos, salvo quando utilizo jQuery).
  • Marionette - Dependendo da complexidade do MV*
  • Browserify - Aos poucos estou migrando para este cara
  • Requirejs - em 95% dos casos eu integro o esse cara, somente quando não há a necessidade em projetos de Nível 1.

Lembrando que, cada caso é um caso. A injeção de dependências vai muito de como será o comportamento de cada componente e da comunicação desses caras no escopo geral do projeto.

Muito interessante as ideias, obrigado @fdaciuk e @vitorbritto, vocês são feras! :-)

@fdaciuk estarei aguardando seu novo artigo com mais detalhes. xD Vai ser muito bom ver como você organiza todos esses detalhes para trabalhar no dia a dia.

@vitorbritto, pelo que vi, o design que estou pensando para o Quiz proposto no roteiro, está se encaminhando mais ou menos no rumo do "Nível 1" que você descreveu.


Acho que isso daria assunto pra um bom hangout/série de artigos não? :-)

Tipo, o pensamento que estava seguindo seria mais ou menos assim:

Analisar a aplicação como um todo, e quebrar em módulos pequenos, em arquivos separados.

Exemplo de módulos:

  • Usuários
  • Barra de progresso
  • Mensagens de alerta

Aí alguns módulos talvez teriam Sub-Módulos, exemplo:

  • Usuários
    • Login/Logout
    • Funções utilitárias:
      • Checar se usuário já existe
      • Buscar usuário por email

E assim vai...

Mas algumas coisas ainda são bem confusas em minha mente.

Será que estou indo no caminho certo? xD

Encontrei uma apresentação muito massa feito pelo Nicolas Zakas:
http://pt.slideshare.net/nzakas/scalable-javascript-application-architecture-2012.