Organização de JavaScript em uma aplicação Rails

[Felipe Munhoz]

Olá galera!

Gostaria da opinião de vocês neste tópico.

Acredito que é melhor eu não me repetir, pois o blog post está descrevendo bem a situação, e também mostra caminhos a seguir.

Gostaria de saber se vocês concordam com a estratégia, ou como vocês preferem fazer isso.

Segue o link.

http://brandonhilkert.com/blog/organizing-javascript-in-rails-application-with-turbolinks/

Obrigado!

--

Felipe Munhoz

[Leonardo Saraiva]

Pirando um pouco sobre isso, tenho um gist que algum dia vai virar um post... (:

Mas é algo parecido com o post!

https://gist.github.com/vyper/4dddc8632340be845766

--
Você recebeu essa mensagem porque está inscrito no grupo "GURU-SC" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para guru-sc+u...@googlegroups.com.
Para mais opções, acesse https://groups.google.com/d/optout.

--

Att,
Leonardo Saraiva

........__Ô                 "chuva-ou-sol,
....._ \ >_                 peda-lã-moi-gual"
....(_) / (_)                (Tássia Arouche)

[G. Sobrinho]

Não consigo gostar do turbolinks porque normalmente lido com features JS-heavy que precisam do backbone ou react.

O que eu faço normalmente é criar mini apps JS para cada tela, tipo assim:

+ app/assets/javascript

++ people

+++ actions

+++ components

+++ stores

++ users

+++ actions

+++ components

+++ stores

++ people.js

++ users.js

Daí eu tenho o bootstrap da "mini-app" e a app dentro do seu próprio diretório. E faço assim na view:

  def controller_asset?

    Rails.application.assets.find_asset "#{controller_name}.js"

  end

  <%= javascript_include_tag controller_name if controller_asset? %>

E meu bootstrap fica mais ou menos assim:

//= require_tree ./people/actions

//= require_tree ./people/components

//= require_tree ./people/stores

$(document).ready(function () {

  var people = new PeopleStore(window.people);

  var PeopleComponent =

    FluxoReactConnectStores(PeopleComponent, { people: people });

  React.render(

    React.createElement(PeopleComponent),

    document.getElementById("app-container")

  );

});

Widgets e bibliotecas que são compartilhados ficam em outro diretório comum da aplicação, obviamente, mas sempre seguindo o mesmo conceito de mini-app JS.

2015-08-13 11:22 GMT-03:00 Felipe Munhoz <mun...@gmail.com>:

--

Você recebeu essa mensagem porque está inscrito no grupo "GURU-SC" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para guru-sc+u...@googlegroups.com.
Para mais opções, acesse https://groups.google.com/d/optout.

--

Cheers,

Gabriel Sobrinho

http://gabrielsobrinho.com/

[Felipe Munhoz]

Leonardo, bora publicar esse post ai :)

Sobrinho, achei bem interessante este formato, e também curti o uso do React com Rails.

Neste formato que você mostrou, são preciso quantas requests de JS? Duas?

Uma para o `application.js` digamos e outra para o asset específico de cada controller/view ?

Felipe Munhoz

[G. Sobrinho]

Exatamente, o application.js que tem o que é comum sempre é feito request.

Cada feature que possuir sua mini-app vai ter um request adicional mas acaba sendo mais performático no meu caso porque lido com aplicações monolíticas gigantes, então carregar tudo em todas as telas é tipo no pé! xD

[Cezinha - ASSEINFO]

Olá Felipe!

A gente operou bastante tempo com uma abordagem parecida com a do post que você referenciou. A diferença maior é que a gente não usa coffee e nem turbolinks.

A organização de nossas pastas era muito parecida com a apresentada pelo Leonardo. O javascript de cada view era executado por uma chamada em um Single Entry Point.

Eu não sou muito fã de ficar fazendo muitos request. Prefiro ter arquivos javascript minificados maiores. O peso de servir isso zipado, para o nosso caso, não é tão alto.

Tenho o costume de criar pelo menos dois manifestos: um para o "application" e outro para o "third-party". O application é o que tende a mudar mais e também ser menor (no nosso caso).

Atualmente nossos aplicativos estão caminhando para serem totalmente independente do Rails sob o ponto de vista de front-end  - e estamos muito perto.

Segue abaixo os slides da minha palestra no TDC. Farei uma parecida na próxima Rubyconf.

http://pt.slideshare.net/CezinhaAnjos/tdc-2015-rails-javascript-faa-isso-direito

Estou à disposição se precisar de algo (cezinh...@gmail.com).

Um abraço.

César Luiz dos Anjos Júnior

Diretor

(48) 3263-7137
http://www.asseinfo.com.br

 

"A curiosidade é um dos maiores sinais de vitalidade de um profissional.”

Jim Collins

 

“Keep learning like a crazy...”

Uncle Bob

[Ismael Stahelin]

Ótima abordagem Cezinha. Front-end independente é o que há!!!

Parabéns!

Ismael Stahelin

[Lucas Brito Arruda]

Cezinha,

Isso de separar em gem e bower é bem interessante. Sem isso, fica um pouco difícil de gerenciar as libs JS.

Sobrinho,

Quanto a JS que executa só numa View: acho que não seria overhead fazer igual ao autor do artigo (que joga a definição no application.js), mas ao invés de por a execução lá e chavear por classe, por a chamada na própria view:

# app/views/.../index.html.slim
...

javascript:
  App.init()

Comentei isso no artigo e ele disse que prefere manter as views limpas, sem JS. Não acho que isso seja realmente sujar, já que a lib ta toda na assets pipeline. O que acha disso?

[]s

Lucas Arruda

lucasarruda.com

[G. Sobrinho]

O problema de inserir todos os javascripts no application.js é que telas que não utilizam o JS ainda pagaram a banda, parsing e evaluation.

Isso não é um problema em aplicações menores mas aplicações monolíticas pode se tornar um problema.

--

Você recebeu essa mensagem porque está inscrito no grupo "GURU-SC" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para guru-sc+u...@googlegroups.com.
Para mais opções, acesse https://groups.google.com/d/optout.

[G. Sobrinho]

Quanto ao trigger, o meu é automatizado porque o include acontece com o nome do controller automaticamente, que é nosso file de bootstrap ;)

[Lucas Brito Arruda]

Sobrinho,

Entendi. Eu ainda prefiro, pelo menos para a aplicação que estou mexendo, ter tudo no application.js porque não é nada gigantesco, vai ter o cache e no final das contas é 1 request.

Gostei do que o Cezinha fala [na apresentação] sobre usar o Dispatcher e namespaces/modulos, mas com javascript sempre no application pra gerar 1 só request.