Auteur : Matthieu

Il existe de nombreuses pseudo-classes en CSS. Le site developer.mozilla.org en a d’ailleurs fait une liste. Celles qui peuvent le plus nous intéresser sont :

• :visited et :link qui permettent de cibler les liens déjà visités ou pas encore visités.
• :hover, :active et :focus, qui ciblent un élément survolé, activé (au moment du clic) ou ayant le focus.
• :target qui sélectionne l’élément ayant l’id passé dans l’url. Thomas avait expérimenté cette pseudo-classe dans un précédent article.
• :checked qui cible les éléments cochés (radio bouton ou checkbox) ou sélectionné (select liste)
• :valid, :invalid ou :required, bien pratique pour différencier les éléments de formulaire obligatoire et mal remplis.
• :first-child, :first-of-type, :nth-child() pour cibler précisément les éléments du DOM
• :not() cible les éléments qui n’ont pas la classe passée en paramètre par exemple

J’ai utilisé ces propriétés sur l’exemple suivant : codepen.io/maattt/pen/ZpvQXd

À noter que la pseudo-classe :hover est activée au moment du clic sur certains mobiles (Android, iPhone) mais pas sur tous (Windows Phone). Il est donc conseillé de la coupler avec la pseudo-classe :focus (source).

Avant sa sortie, nous avions fait le point sur les principales nouveautés de Rails 5 : quoi de neuf sur Rails 5 avant sa sortie finale ?.

Après avoir développé avec pendant quelques semaines, voici nos premiers retours concernant les nouveautés de syntaxes impliquées par Rails 5.

Nous avions également relevé quelques nouveautés lors de l’écriture de tests : Rails 5 & tests : nouveautés et astuces.

Deprecated

Plusieurs méthodes sont dépréciées :

• before_filter est deprécié et remplacé par before_action. Il sera supprimé en Rails 5.1.
• render text: "hello world" est remplacé par render plain: "hello world".
• render mon_path est remplacé par render file: mon_path.
• render nothing: true doit être remplacé par autre chose selon le contexte (render plain: "ok" pour les crons ou une des deux alternatives)
• Les fichiers SASS sont suffixés .scss et plus .css.scss.

belongs_to requis par défaut

Par défaut, un belongs_to posséde un attribut required à true. Cela implique que l’objet associé doit obligatoirement exister pour que l’objet courant soit créé.

Par exemple :

class Question < ApplicationRecord
  belongs_to :questionnaire #, required: true par défaut en Rails 5
end

implique que le questionnaire est persistant quand on instancie une question. Cela peut poser problème lorsqu’on utilise les nested_attributes et qu’on enregistre en même temps le questionnaire et les questions associées. Il faut alors passer l’attribut required à false (ou optional à true)

where.or

Les ActiveRecord::Relation possèdent une méthode or :

@articles = Article.where(actif: true).or(Article.where(titre: "Article principal"))

Sources :

• What’s new in Rails 5
• Rails 5 : what’s new
• What’s new in Rails 5?

En Rails, quand on crée les templates d’emails, il peut être intéressant d’utiliser les « URL Helpers » plutôt que d’écrire manuellement ces URL dans la vue (surtout que les URL en production diffèrent de celles de développement).

Par exemple, si on a un contrôleur articles avec une action index, il existe un helper articles_url qui permet d’accéder à cette action. Ainsi, si on veut faire une ancre vers cette action, on écrira :

link_to "Liste des articles", articles_url

plutôt que :

link_to "Liste des articles", "https://mon-url.com/articles"

pour ne pas avoir à modifier l’url https://mon-url.com à chaque fois qu’on passe de développement à production.

Pour utiliser ces URL Helpers dans les vues des emails, l’application doit connaitre le nom de domaine qui l’héberge. Pour cela, il faut ajouter aux fichiers de config d’environnements :

# dans config/environments/*.rb
config.action_mailer.default_url_options = { host: "https://mon-url.com" }

Nouveautés

Test des contrôleurs

En Rails 5, la méthode qu’on utilisait pour tester les contrôleurs est dépréciée en faveur de l’utilisation de « hash parameters ».

# Rails 4
post :create, { article: { actif: @article.actif, auteur: @article.auteur, contenu: @article.contenu, titre: @article.titre } }, { utilisateur_id: 1234 }

# Rails 5
post articles_url, params: { article: { actif: @article.actif, auteur: @article.auteur, contenu: @article.contenu, titre: @article.titre } }, session: { utilisateur_id: 1234 }, hearders: { "HTTP_REFERER" => "http://example.com/home" }
# ou
process articles_url, method: :post, params: { article: { actif: @article.actif, auteur: @article.auteur, contenu: @article.contenu, titre: @article.titre } }, session: { utilisateur_id: 1234 }

Utilisation de assigns

La fonction assigns qui permet de récupérer une variable @variable du contrôleur a été retirée de la gem ‘rails’ en version 5. Pour pouvoir l’utiliser, il faut inclure la gem ‘rails-controller-testing’ dans le Gemfile.

Astuces

Changer le message d’une failure

assert_not article.save, "Sauvegarde d'un article sans titre possible"

Récupérer plusieurs fixtures dans un tableau

articles(:one, :two)

Test des flash notice

assert_equal 'Article créé !', flash[:notice]

Recharger un objet après qu’il ait été mis à jour

@article.reload

Doc : guides.rubyonrails.org

Exécuter tous les tests

rails test

Exécuter les tests d’un répertoire

rails test test/controllers

Exécuter les tests d’un fichier

rails test test/models/article_test.rb

Exécuter un test en fonction de son nom

rails test test/models/article_test.rb -n test_save_article_sans_titre_impossible

Exécuter le test d’une ligne

rails test test/models/article_test.rb:7

Doc : guides.rubyonrails.org

En rails, depuis quelques versions et notamment en rails 5, lorsqu’on génère une nouvelle application, on a vu apparaître l’appel à ce type de variable : ENV['APPLI_DATABASE_PASSWORD'], ENV['DATABASE_URL'], ENV["SECRET_KEY_BASE"]. Ces variables de configuration sont des variables privées qu’il ne faut pas partager, notamment dans un projet github.

On peut alors se demander où et comment définir ces variables.

Solution 1 : définir des variables d’environnement UNIX

Pour cela, il suffit d’ajouter au fichier ~/.bashrc (ou ~/zshrc si on utilise zsh) :

export MA_VARIABLE='VALEUR' # ENV['MA_VARIABLE']

Cette variable d’environnement sera alors accessible dans l’application Rails : ENV['MA_VARIABLE'].

Solution 2 : utiliser la gem Figaro

Utiliser les variables UNIX peut vite devenir contraignant. C’est la gem Figaro est intéressante. Elle génère un fichier config/application.yml dans lequel on stockera nos variables d’environnement.

Exemple :

test:
  ma_variable: "toto" # ENV['ma_variable']
development:
  ma_variable: "tata" # ENV['ma_variable']
production:
  ma_variable: "titi" # ENV['ma_variable']

Source : http://railsapps.github.io/rails-environment-variables.html

Dans le Gemfile d’un projet Rails, la source est précisée en haut du fichier :

source 'https://rubygems.org'

Il est également possible de préciser une source différente pour une gem :

gem 'la-gem', source: 'http://url-de-la-gem'

Mais on peut aussi spécifier un chemin local :

gem 'ma-gem', path: "chemin/vers/ma-gem"

Ainsi, on peut tester une gem en cours de développement sans la publier.

Plus d’infos sur le Gemfile : bundler.io