web-dev-qa-db-fra.com

En utilisant Rails 3.1, où placez-vous votre code JavaScript "spécifique à la page"?

À ma connaissance, tout votre JavaScript est fusionné dans 1 fichier. Rails le fait par défaut lorsqu'il ajoute //= require_tree . au bas de votre fichier manifeste application.js.

Cela ressemble à une vraie bouée de sauvetage, mais je suis un peu préoccupé par le code JavaScript spécifique à la page. Ce code est-il exécuté sur chaque page? La dernière chose que je souhaite, c'est que tous mes objets soient instanciés pour chaque page lorsqu'ils ne sont nécessaires que sur une page.

De même, n'y a-t-il pas un potentiel de conflit de code?

Ou mettez-vous une petite balise script au bas de la page qui appelle simplement une méthode exécutant le code javascript de la page?

Avez-vous plus besoin de require.js alors?

Merci

EDIT: J'apprécie toutes les réponses ... et je ne pense pas qu'ils s'attaquent vraiment au problème. Certains d'entre eux concernent le style et ne semblent pas avoir de rapport ... et d'autres mentionnent simplement javascript_include_tag... que je connais existe (évidemment ...) mais il semblerait que le RailsLa méthode la plus appropriée consiste à envelopper tout votre JavaScript dans un fichier plutôt que de charger du code JavaScript individuel au bas de chaque page.

La meilleure solution que je puisse trouver consiste à envelopper certaines fonctionnalités dans les balises div avec ids ou classes. Dans le code JavaScript, il vous suffit de vérifier si la id ou class se trouve sur la page. Si c'est le cas, vous exécutez le code JavaScript qui lui est associé. Ainsi, si l'élément dynamique n'est pas sur la page, le code JavaScript ne s'exécute pas, même s'il a été inclus dans le fichier massif application.js emballé par Sprockets.

Ma solution ci-dessus présente l'avantage que si un champ de recherche est inclus sur 8 des 100 pages, il ne fonctionnera que sur ces 8 pages. Vous n'aurez pas non plus à inclure le même code sur 8 des pages du site. En fait, vous n’aurez plus jamais besoin d’inclure des balises de script manuelles sur votre site.

Je pense que ceci est la réponse réelle à ma question.

javascriptruby-on-railsruby-on-rails-3.1asset-pipelinesprockets
386
Fire Emblem

J'apprécie toutes les réponses ... et je ne pense pas qu'ils s'attaquent vraiment au problème. Certaines d'entre elles concernent le style et ne semblent pas avoir de rapport ... et d'autres mentionnent simplement javascript_include_tag... que je connais existe (évidemment ...) mais il semblerait que le RailsLa méthode 3.1 consiste à résumer l’ensemble de votre code Javascript dans un fichier au lieu de le charger individuellement au bas de chaque page.

La meilleure solution que je puisse trouver consiste à envelopper certaines fonctionnalités dans les balises div avec ids ou classes. Dans le code javascript. Ensuite, il vous suffit de vérifier si la id ou class se trouve sur la page et, le cas échéant, vous exécutez le code javascript qui lui est associé. Ainsi, si l'élément dynamique ne figure pas sur la page, le code javascript ne s'exécute pas, même s'il a été inclus dans le fichier massif application.js emballé par Sprockets.

Ma solution ci-dessus présente l'avantage que si un champ de recherche est inclus sur 8 des 100 pages, il ne fonctionnera que sur ces 8 pages. Vous n'aurez pas non plus à inclure le même code sur 8 des pages du site. En fait, vous n'aurez plus jamais besoin d'inclure des balises de script manuelles sur votre site, sauf peut-être pour le préchargement des données.

Je pense que ceci est la réponse réelle à ma question.

23
Fire Emblem

La documentation Asset Pipeline suggère comment utiliser JS spécifique au contrôleur:

Par exemple, si un ProjectsController est généré, il y aura un nouveau fichier à app/assets/javascripts/projects.js.coffee et un autre à app/assets/stylesheets/projects.css.scss. Vous devez placer tout code JavaScript ou CSS propre à un contrôleur dans leurs fichiers d'actif respectifs, car ces fichiers peuvent ensuite être chargés uniquement pour ces contrôleurs avec des lignes telles que <%= javascript_include_tag params[:controller] %> ou <%= stylesheet_link_tag params[:controller] %>.

Lien vers: asset_pipeline

157
meleyal

Pour le js spécifique à la page, vous pouvez utiliser solution Garber-Irish .

Ainsi, votre dossier javascripts Rails pourrait ressembler à ceci pour deux contrôleurs - voitures et utilisateurs:

javascripts/
├── application.js
├── init.js
├── markup_based_js_execution
├── cars
│   ├── init .js
│   ├── index.js
│   └── ...
└── users
    └── ...

Et javascripts ressemblera à ceci:

// application.js

//= 
//= require init.js
//= require_tree cars
//= require_tree users

// init.js

SITENAME = new Object();
SITENAME.cars = new Object;
SITENAME.users = new Object;

SITENAME.common.init = function (){
  // Your js code for all pages here
}

// cars/init.js

SITENAME.cars.init = function (){
  // Your js code for the cars controller here
}

// cars/index.js

SITENAME.cars.index = function (){
  // Your js code for the index method of the cars controller
}

et markup_based_js_execution contiendra le code de l’objet UTIL et de l’exécution UTIL.init prête pour le DOM.

Et n'oubliez pas de mettre ceci dans votre fichier de layout:

<body data-controller="<%= controller_name %>" data-action="<%= action_name %>">

Je pense aussi qu'il est préférable d'utiliser des classes plutôt que des attributs data-*, pour un meilleur CSS spécifique à la page. Comme Jason Garber l'a mentionné: les sélecteurs CSS spécifiques à une page peuvent devenir vraiment gênants (lorsque vous utilisez data-*attributes)

J'espère que cela t'aidera.

77
welldan97

Je vois que vous avez répondu à votre propre question, mais voici une autre option:

Fondamentalement, vous faites l'hypothèse que

//= require_tree .

est requis. Ce n'est pas. N'hésitez pas à l'enlever. Dans mon application actuelle, la première que je fais avec 3.1.x honnêtement, j’ai créé trois fichiers JS de niveau supérieur différents. Mon fichier application.js contient uniquement

//= require jquery
//= require jquery_ujs
//= require_directory .
//= require_directory ./api
//= require_directory ./admin

De cette façon, je peux créer des sous-répertoires, avec leurs propres fichiers JS de niveau supérieur, qui incluent uniquement ce dont j'ai besoin.

Les clés sont:

  1. Vous pouvez supprimer require_tree - Rails vous permet de modifier les hypothèses qu'il émet
  2. Le nom application.js n'a rien de spécial - tout fichier du sous-répertoire assets/javascript peut inclure des directives de pré-traitement avec //=

J'espère que cela aide et ajoute quelques détails à la réponse de ClosureCowboy.

Sujal

65
sujal

Une autre option: pour créer des fichiers spécifiques à une page ou à un modèle, vous pouvez créer des répertoires dans votre dossier assets/javascripts/.

assets/javascripts/global/
assets/javascripts/cupcakes
assets/javascripts/something_else_specific

Votre fichier manifeste principal application.js peut être configuré pour charger ses fichiers à partir de global/. Des pages spécifiques ou des groupes de pages peuvent avoir leur propre manifeste qui charge des fichiers à partir de leurs propres répertoires spécifiques. Sprockets combinera automatiquement les fichiers chargés par application.js avec vos fichiers spécifiques à la page, ce qui permettra à cette solution de fonctionner.

Cette technique peut également être utilisée pour style_sheets/.

40
ClosureCowboy

Je me rends compte que j'arrive un peu tard à la fête, mais je voulais proposer une solution que j'utilisais depuis peu. Cependant, laissez-moi d'abord mentionner ...

La Rails 3.1/3.2 Way (Non, monsieur. Je n'aime pas ça.)

Voir: http://guides.rubyonrails.org/asset_pipeline.html#how-to-use-the-asset-pipeline

J'inclus ce qui suit par souci d'exhaustivité dans cette réponse, et parce que ce n'est pas une solution non viable ... bien que cela ne me dérange pas beaucoup.

"Rails Way" est une solution orientée contrôleur, plutôt que d'être orientée vue comme le demandait l'auteur original de cette question. Il existe des fichiers JS spécifiques au contrôleur, nommés d'après leurs contrôleurs respectifs. Tous ces fichiers sont placés dans une arborescence de dossiers qui n'est PAS incluse par défaut dans l'une des directives requises application.js.

Pour inclure le code spécifique au contrôleur, les éléments suivants sont ajoutés à une vue.

<%= javascript_include_tag params[:controller] %>

Je déteste cette solution, mais c'est là et c'est rapide. Vraisemblablement, vous pourriez plutôt appeler ces fichiers quelque chose comme "people-index.js" et "people-show.js", puis utiliser quelque chose comme "#{params[:controller]}-index" pour obtenir une solution orientée vue. Encore une fois, solution miracle, mais ça ne me convient pas.

Mon chemin d'attribut de données

Appelez-moi fou, mais je veux que TOUS mes JS soient compilés et minifiés dans application.js lors de mon déploiement. Je ne veux pas avoir à oublier d'inclure ces petits fichiers de retardement un peu partout.

Je charge tous mes fichiers JS dans un fichier compact, bientôt mis en cache par le navigateur. Si un certain élément de mon application.js doit être déclenché sur une page, je laisse le code HTML me le signaler, et non pas Rails.

Plutôt que de verrouiller mon JS avec des identifiants d'élément spécifiques ou de surcharger mon HTML avec des classes de marqueurs, j'utilise un attribut de données personnalisé appelé data-jstags.

<input name="search" data-jstag="auto-suggest hint" />

Sur chaque page, j'utilise - j'insère ici la méthode de bibliothèque JS préférée - pour exécuter le code lorsque le chargement du DOM est terminé. Ce code d'amorçage effectue les actions suivantes:

  1. Itérer sur tous les éléments du DOM marqués par data-jstag
  2. Pour chaque élément, divisez la valeur d'attribut sur l'espace en créant un tableau de chaînes de balises.
  3. Pour chaque chaîne de balises, effectuez une recherche dans un hachage pour cette balise.
  4. Si une clé correspondante est trouvée, exécutez la fonction qui lui est associée en transmettant l'élément en tant que paramètre.

Donc, disons que j'ai les éléments suivants définis quelque part dans mon application.js:

function my_autosuggest_init(element) {
  /* Add events to watch input and make suggestions... */
}

function my_hint_init(element) {
  /* Add events to show a hint on change/blur when blank... */
  /* Yes, I know HTML 5 can do this natively with attributes. */
}

var JSTags = {
  'auto-suggest': my_autosuggest_init,
  'hint': my_hint_init
};

L'événement d'amorçage va appliquer les fonctions my_autosuggest_init et my_hint_init à la saisie de la recherche, en la transformant en une entrée affichant une liste de suggestions pendant la saisie de l'utilisateur, tout en fournissant un indice de saisie. lorsque l'entrée est laissée vide et floue.

Sauf si un élément est marqué avec data-jstag="auto-suggest", le code de suggestion automatique ne se déclenche jamais. Cependant, il est toujours là, minifié et éventuellement mis en cache dans mon application.js pour les moments où j'en ai besoin sur une page.

Si vous devez transmettre des paramètres supplémentaires aux fonctions JS balisées, vous devrez faire preuve de créativité. Ajoutez des attributs de paramètres de données, créez une sorte de syntaxe de paramètre ou utilisez même une approche hybride.

Même si certains flux de travail compliqués semblent spécifiques à un contrôleur, je créerai simplement un fichier correspondant dans mon dossier lib, le placerai dans application.js et le baliser avec quelque chose comme 'new-thing-wizard'. Lorsque mon bootstrap frappe sur cette balise, mon assistant de Nice sera créé et exécuté. Il fonctionne pour la ou les vues de ce contrôleur lorsque cela est nécessaire, mais n'est pas couplé d'une autre manière au contrôleur. En fait, si je code correctement mon assistant, je pourrai peut-être fournir toutes les données de configuration dans les vues et donc pouvoir réutiliser mon assistant ultérieurement pour tout autre contrôleur qui en aura besoin.

En tout cas, c’est ainsi que j’ai mis en œuvre JS depuis une certaine période et cela m’a bien servi à la fois pour la conception de sites simples et pour des applications plus complexes/riches. J'espère que l'une des deux solutions que j'ai présentées ici, mon chemin ou le cheminRails, est utile à quiconque se heurte à cette question à l'avenir.

16
Ryan

Cela a été répondu et accepté il y a longtemps, mais j'ai proposé ma propre solution basée sur certaines de ces réponses et mon expérience avec Rails 3+.

Le portefeuille d'actifs est doux. Utilise le.

Tout d’abord, dans votre fichier application.js, supprimez //= require_tree.

Ensuite, dans votre application_controller.rb créez une méthode d'assistance:

helper_method :javascript_include_view_js //Or something similar

def javascript_include_view_js
    if FileTest.exists? "app/assets/javascripts/"+params[:controller]+"/"+params[:action]+".js.erb"
        return '<script src="/assets/'+params[:controller]+'/'+params[:action]+'.js.erb" type="text/javascript"></script>'
    end
end

Ensuite, dans votre fichier de mise en page application.html.erb, ajoutez votre nouvel assistant parmi les inclusions javascript existantes, précédé du préfixe raw:

<head>
    <title>Your Application</title>
    <%= stylesheet_link_tag "application", :media => "all" %>
    <%= javascript_include_tag "application" %>
    <%= raw javascript_include_view_js %>
</head>

Voilà, vous pouvez désormais créer facilement du code javascript spécifique à une vue à l'aide de la même structure de fichiers que celle utilisée partout ailleurs dans Rails. Il suffit de coller vos fichiers dans app/assets/:namespace/:controller/action.js.erb!

J'espère que ça aide quelqu'un d'autre!

7
Mike A
<%= javascript_include_tag params[:controller] %>
6
Mr Bohr

Vous pouvez ajouter cette ligne dans votre fichier de présentation (par exemple, application.html.erb) pour charger automatiquement le fichier javascript spécifique au contrôleur (celui qui a été créé lors de la génération du contrôleur):

<%= javascript_include_tag params[:controller] %>

Vous pouvez également ajouter une ligne pour charger automatiquement un fichier de script action par action.

<%= javascript_include_tag params[:controller] + "/" + params[:action] %>

Il suffit de placer vos scripts de page dans un sous-répertoire nommé d'après le nom du contrôleur. Dans ces fichiers, vous pouvez inclure d'autres scripts utilisant = require. Il serait bien de créer un assistant pour inclure le fichier uniquement s'il existe, afin d'éviter une défaillance 404 du navigateur.

6
mcubik

Peut-être trouverez-vous pluggable_js gem comme solution appropriée.

6
peresleguine

Le LoadJS gem est une autre option:

LoadJS fournit un moyen de charger du code Javascript spécifique à une page dans une application Rails sans perdre la magie fournie par Sprockets. Tout votre code Javascript continuera d'être minifié dans un fichier Javascript mais certaines parties ne seront exécutées que pour certaines pages.

https://github.com/guidomb/loadjs

5
meleyal

La réponse de Philip est assez bonne. Voici le code pour le faire fonctionner:

Dans application.html.erb:

<body class="<%=params[:controller].parameterize%>">

En supposant que votre contrôleur s'appelle Projets, cela générera:

<body class="projects">

Puis dans projects.js.coffee:

jQuery ->
  if $('body.projects').length > 0  
     $('h1').click ->
       alert 'you clicked on an h1 in Projects'
3
Rahil Sondhi

Vous pouvez également regrouper les fichiers js dans des dossiers et continuer à utiliser le pipeline d’actifs pour charger votre code javascript sélectivement en fonction de la page.

2
Kenny Grant

Les scripts Java ne sont fusionnés que lorsque vous indiquez à Rails (Sprockets plutôt) de les fusionner.

2
yfeldblum

Je suis d'accord avec votre réponse, pour vérifier si ce sélecteur est là, utilisez:

if ($(selector).length) {
    // Put the function that does not need to be executed every page
}

(n'a vu personne ajouter la solution réelle)

2
Kyle C

Voici comment j'ai résolu le problème de style: (excusez le Haml)

%div{:id => "#{params[:controller].parameterize} #{params[:view]}"}
    = yield

De cette façon, je lance tous les fichiers spécifiques à la page . Css.sass avec:

#post
  /* Controller specific code here */
  &#index
    /* View specific code here */
  &#new
  &#edit
  &#show

De cette façon, vous pouvez facilement éviter les affrontements. En ce qui concerne les fichiers . Js.coffee, vous pouvez simplement initialiser des éléments tels que;

$('#post > #edit') ->
  $('form > h1').css('float', 'right')

J'espère que cela a aidé certains.

2
zeeraw

Je ne vois pas de réponse qui rassemble vraiment tout et qui vous le présente. Donc, je vais essayer de mettre meleyal , sujal (à la ClosureCowboy ), la première partie de la réponse de Ryan , et même Déclaration audacieuse de Gal à propos de Backbone.js ... de manière concise et claire. Et, qui sait, je pourrais même répondre aux exigences de Marnen Laibow-Koser .

Exemple de modifications

assets/javascripts/application.js

//= require jquery
//= require jquery_ujs
//= require lodash.underscore.min
...


vues/layouts/application.html.erb

  ...
  </footer>

  <!-- Javascripts ================================================== -->
  <!-- Placed at the end of the document so the pages load faster -->
  <%= javascript_include_tag "application" %>
  <%= yield :javascript %>

</body>
</html>


views/foo/index.html.erb

...
<% content_for :javascript do %>
  <%= javascript_include_tag params[:controller] %>
<% end %>


assets/javascripts/foo.js

//= require moment
//= require_tree ./foostuff


assets/javascripts/foostuff/foothis.js.coffee

alert "Hello world!"


Brève description

  • Supprimez //= require_tree . de application.js et répertoriez uniquement le JS partagé par chaque page.

  • Les deux lignes indiquées ci-dessus dans application.html.erb indiquent à la page où inclure application.js et votre fichier JS spécifique à la page.

  • Les trois lignes indiquées ci-dessus dans index.html.erb indiquent à votre vue de rechercher un JS spécifique à une page et de l'inclure dans une région de rendement nommée appelée ": javascript" (ou le nom que vous souhaitez nommer). ). Dans cet exemple, le contrôleur est "foo", donc Rails tentera d'inclure "foo.js" dans la région: javascript yield de la présentation de l'application.

  • Listez votre JS spécifique à la page dans foo.js (ou quel que soit le nom du contrôleur). Liste des bibliothèques communes, un arbre, des répertoires, peu importe.

  • Conservez votre JS personnalisé spécifique à la page dans un endroit où vous pourrez le référencer facilement, indépendamment de votre autre JS personnalisé. Dans cet exemple, foo.js nécessite l’arborescence des aliments pour animaux, vous devez donc y placer votre JS personnalisé, tel que foothis.js.coffee.

  • Il n'y a pas de règles strictes ici. Sentez-vous libre de déplacer les choses et peut-être même créer plusieurs régions de rendement portant des noms variés dans différentes dispositions si nécessaire. Cela montre juste un premier pas possible. (Je ne le fais pas exactement comme cela compte tenu de notre utilisation de Backbone.js. Je pourrais aussi choisir de déposer foo.js dans un dossier appelé foo au lieu de foostuff mais je ne l'ai pas encore décidé.)

Remarques

Vous pouvez faire la même chose avec CSS et <%= stylesheet_link_tag params[:controller] %>, mais cela dépasse le cadre de la question.

Si j'ai raté une pratique exemplaire flagrante ici, envoyez-moi un message et je me préparerai à l'adapter. Rails est relativement nouveau pour moi et, honnêtement, je ne suis pas vraiment impressionné par le chaos qu’il engendre par défaut pour le développement des entreprises et par tout le trafic généré par le programme Railsmoyen.

2
juanitogan

Paloma le projet offre une approche intéressante pour gérer le code javascript spécifique à la page.

Exemple d'utilisation de leur documentation:

var UsersController = Paloma.controller('Users');

// Executes when Rails User#new is executed.
UsersController.prototype.new = function(){
   alert('Hello Sexy User!' );
};
1
zavg

la réponse de ryguy est une bonne réponse, même si elle a été convertie en points négatifs.

Surtout si vous utilisez quelque chose comme Backbone JS - chaque page a sa propre vue Backbone. Ensuite, le fichier erb ne contient qu'une seule ligne de code javascript en ligne qui déclenche la classe de vue dorsale de droite. Je considère que c'est une simple ligne de "code de collage" et donc le fait que son inline est OK. L'avantage est que vous pouvez conserver votre "require_tree" qui permet au navigateur de mettre en cache tout le javascript.

dans show.html.erb, vous aurez quelque chose comme:

<% provide :javascript do %>
  <%= javascript_include_tag do %>
    (new app.views.ProjectsView({el: 'body'})).render();
  <% end %>
<% end do %>

et dans votre fichier de mise en page, vous aurez besoin de:

<%= yield :javascript %>
1
Gal

Étape 1. supprimez require_tree. dans votre application.js et application.css.

Étape 2. Modifiez votre application.html.erb (par Rails default) dans le dossier de présentation. Ajoutez "params [: controller]" dans les balises suivantes.

<%= stylesheet_link_tag    'application', params[:controller], media: 'all', 'data-turbolinks-track' => true %>

<%= javascript_include_tag 'application', params[:controller], 'data-turbolinks-track' => true %>

Étape 3. Ajouter un fichier dans config/initializers/assets.rb

%w( controller_one controller_two controller_three ).each do |controller|
  Rails.application.config.assets.precompile += ["#{controller}.js", "#{controller}.js.coffee", "#{controller}.css", "#{controller}.scss"]
end

références: http://theflyingdeveloper.com/controller-specific-assets-with-Rails-4/

1
etlds

J'ai une autre solution, qui bien que primitive fonctionne bien pour moi et n'a pas besoin de stratégies de chargement sélectif sophistiquées. Mettez dans votre fonction nornal document ready, mais ensuite testez l’emplacement actuel de Windows pour voir s’il s’agit de la page pour laquelle votre javascript est destiné:

$(document).ready(function() {
   if(window.location.pathname.indexOf('/yourpage') != -1) {
          // the javascript you want to execute
   }
}

Cela permet toujours de charger tous les js par Rails 3.x dans un petit paquet, mais cela ne génère pas beaucoup de temps système ou de conflit avec les pages auxquelles le js n'est pas destiné.

1
Peter Abramowitsch

Bien que vous ayez plusieurs réponses ici, je pense que votre édition est probablement le meilleur choix. Un modèle de conception que nous utilisons dans notre équipe et que nous avons obtenu de Gitlab est le modèle Dispatcher. Il fait quelque chose de similaire à ce dont vous parlez, mais le nom de la page est défini dans la balise body par Rails. Par exemple, dans votre fichier de mise en page, incluez quelque chose comme (en HAML):

%body{'data-page' => "#{controller}:#{action}" }

Ensuite, n’avez qu’une fermeture et une instruction switch dans votre fichier dispatcher.js.coffee dans votre dossier javascripts de la manière suivante:

$ ->
  new Dispatcher()

class Dispatcher
  constructor: ->
    page = $('body').attr('data-page')
    switch page
      when 'products:index'
        new Products() 
      when 'users:login'
        new Login()

Tout ce que vous devez faire dans les fichiers individuels (par exemple, products.js.coffee ou login.js.coffee, par exemple) est de les inclure dans une classe, puis de globaliser ce symbole de classe afin de pouvoir y accéder dans le répartiteur:

class Products
  constructor: ->
    #do stuff
@Products = Products

Gitlab a plusieurs exemples de ce que vous voudrez peut-être explorer en cas de curiosité :)

1
onetwopunch

Déplacez tous vos fichiers JS communs dans un sous-dossier tel que 'app/assets/javascript/global', puis dans le fichier application.js, modifiez la ligne //= require_tree . en //= require_tree ./global.

Maintenant, vous êtes libre de placer votre JS spécifique au contrôleur sur la racine 'app/assets/javascript /' et ils ne seront pas inclus dans le JS compilé, car ils ne sont utilisés que lorsque vous les appelez via = javascript_include_tag sur votre contrôleur/vue. .

1
Gedean Dias

Je l'ai fait précédemment en utilisant cette méthode: http://theflyingdeveloper.com/controller-specific-assets-with-Rails-4/ . Très facile, le contrôleur choisit le bon js à charger.

0
Eddie Prislac

Je n'ai pas essayé cela, mais il semble que ce qui suit soit vrai:

  • si vous avez un content_for qui est javascript (par exemple, avec du javascript réel), les sprockets ne le sauront pas et cela fonctionnerait donc de la même manière qu'aujourd'hui.

  • si vous voulez exclure un fichier du grand paquet de javascript, vous devez aller dans le fichier config/sprockets.yml et modifier les fichiers source en conséquence. Ensuite, vous n'incluez que les fichiers que vous avez exclus, le cas échéant.

0
Bill Eisenhauer

J'ai combiné quelques réponses dans:

Assistant d'application:

module ApplicationHelper
  def js_page_specific_include
    page_specific_js = params[:controller] + '_' + params[:action]
    if Rails.application.assets.find_asset(page_specific_js).nil?
      javascript_include_tag 'application', 'data-turbolinks-track' => true
    else
      javascript_include_tag 'application', page_specific_js, 'data-turbolinks-track' => true
    end
  end
end

layouts/application.html.haml:

 <!DOCTYPE html>
%html{lang: 'uk'}
  %head   
    = stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track' => true
   bla-bla-bla
    = js_page_specific_include   
   bla-bla-bla
0
kapellan

Premièrement: supprimez \\=require_treede application.js Deuxièmement: tout votre code JS doit être attribué à /app/assets/javascritpt et tout votre code CSS à /app/assets/stylesheets

0
Nicollas Matheus