-
Notifications
You must be signed in to change notification settings - Fork 33
/
05s-the-session.md.erb
172 lines (116 loc) · 9.36 KB
/
05s-the-session.md.erb
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
---
title: La Session
slug: the-session
date: 0005/01/02
number: 5.5
points: 5
sidebar: true
photoUrl: http://www.flickr.com/photos/philmosby/11372421963/
photoAuthor: Phil Mosby
contents: Apprendre à utiliser la Session Meteor|Découvrir la fonction Autorun|Comprendre le Hot Code Reload (rechargement à chaud du code)
paragraphs: 33
---
Meteor est un framework réactif. Ce qui veut dire que comme les données changent, les choses dans votre application changent sans que vous ayez explicitement besoin de faire quoi que ce soit.
Nous avons déjà vu ça en action lors des changements de template à la modification de données et de routes.
Nous irons un peu plus loin dans le fonctionnement plus tard dans les chapitres, mais pour le moment, nous aimerions présenter quelques fonctionnalités réactives de base qui sont extrêmement utiles dans les applications en général.
### La Session Meteor
Actuellement dans Microscope, l'état courant de l'application utilisateur est complètement contenu dans l'URL qu'il regarde (et la base de données).
Mais dans de nombreux cas, vous allez avoir besoin de stocker des états éphémères qui sont seulement pertinants pour la version courante de l'utilisateur de l'application (par exemple, qu'un élément soit affiché ou caché). La session est un moyen idéal pour faire ça.
La session est une zone de stockage de données réactive. C'est global dans le sens d'un objet singleton global : il y a une session, et c'est accessible partout. Les variables globales sont habituellement vues comme des mauvaises choses, mais dans ce cas la session peut être utilisée comme un bus de communications central entre les différentes parties de l'application.
### Changer la Session
La Session est disponible partout sur le client en tant que l'objet `Session`. Pour insérer une valeur de sessions, vous pouvez appeler :
~~~js
❯ Session.set('pageTitle', 'A different title');
~~~
<%= caption "Console du navigateur" %>
Vous pouvez ensuite lire les données avec `Session.get('mySessionProperty');`. C'est une source de données réactive, et ça signifie que si vous la mettez dans un helper, vous pouvez changer ce qu'affiche le helper de manière réactive en changeant la valeur de Session.
Pour essayer ça, ajoutez le code qui suit au template layout :
~~~html
<header class="navbar navbar-default" role="navigation">
<div class="navbar-header">
<a class="navbar-brand" href="{{pathFor 'postsList'}}">{{pageTitle}}</a>
</div>
</header>
~~~
<%= caption "client/templates/application/layout.html"%>
~~~js
Template.layout.helpers({
pageTitle: function() { return Session.get('pageTitle'); }
});
~~~
<%= caption "client/templates/application/layout.js"%>
<% note do %>
### Une note sur le code des apartés
Notez que le code présenté dans les chapitres apartés ne fait pas partie du cours principal du livre. Vous pouvez donc soit créer une nouvelle branche maintenant (si vous utilisez Git), soit vous assurez d'annuler les changements à la fin de ce chapitre.
<% end %>
Le rechargement automatique de Meteor (connu comme “hot code reload” ou HCR) préserve les variables de Session, donc nous devrions voir maintenant "A different title" affiché dans la navbar. Sinon, retapez juste la précédente commande `Session.set()` une nouvelle fois.
De plus, si nous changeons la valeur une fois de plus (via la console du navigateur), nous devrions voir le titre affiché changer une nouvelle fois :
~~~js
❯ Session.set('pageTitle', 'A brand new title');
~~~
<%= caption "Console du navigateur" %>
La Session est disponible globalement, donc de tels changements peuvent être fait n'importe où dans l'application. Ça nous donne un peu de pouvoir, mais ça peut également être un piège si c'est trop souvent utilisé.
D'ailleurs il est important d'indiquer que l'objet Session *n'*est *pas* partagé entre les utilisateurs, ou même entre les onglets. C'est pourquoi si vous ouvrez maintenant l'application dans un nouvel onglet, vous serez face à un titre de site vide.
<% note do %>
### Changements Identiques
Si vous modifiez une variable de Session avec `Session.set()` mais que vous l'initialisez à une valeur identique, Meteor est assez intelligent pour passer outre la chaîne réactive, et évitez les appels de fonction non nécessaires.
<% end %>
### Présentation de Autorun
Nous avons regardé un exemple d'une source de données réactive, et nous l'avons observé en action à l'intérieur d'un helper de template. Mais là où les contextes dans Meteor (tels que les template helpers) sont réactifs de manière inhérentes, la majorité du code de l'application Meteor est encore plein de JavaScript non réactif.
Supposons que nous avons le petit bout de code suivant quelque part dans notre application :
~~~js
helloWorld = function() {
alert(Session.get('message'));
}
~~~
Quand bien même nous appelons une variable de Session, le *contexte* dans lequel elle est appelée est non réactif, ce qui signifie que nous n'aurons pas de nouvelle `alerte` à chaque fois que nous changerons la variable.
C'est là que [Autorun](http://docs.meteor.com/#Tracker_autorun) intervient. Comme son nom l'indique, le code à l'intérieur d'un bloc `autorun` s'exécutera et restera en cours d'exécution chaque fois que les sources de données réactives utilisées à l'intérieur changeront.
Essayer de taper ça dans la console de votre navigateur :
~~~js
❯ Tracker.autorun( function() { console.log('Value is : ' + Session.get('pageTitle')); } );
Value is : A brand new title
~~~
<%= caption "Console du navigateur" %>
Comme vous pouviez vous y attendre, le bloc de code fourni à l'intérieur du `autorun` s'éxécute une fois, retournant ses données à la console. Maintenant, essayons de changer le titre :
~~~js
❯ Session.set('pageTitle', 'Yet another value');
Value is : Yet another value
~~~
<%= caption "Console du navigateur" %>
C'est magique ! Comme la valeur de session a changé, `autorun` a su qu'il devait executer son contenu une nouvelle fois, renvoyant la nouvelle valeur à la console.
Revenons à notre précédent exemple, si nous voulons déclencher une nouvelle alerte à chaque fois que la variable change, tout ce dont nous avons besoin est d'envelopper notre code d'un bloc `autorun` :
~~~js
Tracker.autorun(function() {
alert(Session.get('message'));
});
~~~
Comme nous venons de le voir, `autorun` peut être vraiment utile pour traquer les sources de données réactives et réagir.
### Hot Code Reload
Durant notre développement de Microscope, nous avons profité d'une fonctionnalité de Meteor qui fait gagner du temps : hot code reload (HCR). Quand nous sauvegardons un de nos fichiers de code, Meteor détecte les changements et redémarre de façon transparente le serveur meteor en cours d'exécution, en informant chaque client de recharger la page.
C'est identique à un rechargement automatique de la page, mais avec une différence importante.
Pour trouver ce que c'est, commencer par réinitialiser la variable de session que nous avons utilisée :
~~~js
❯ Session.set('pageTitle', 'A brand new title');
❯ Session.get('pageTitle');
'A brand new title'
~~~
<%= caption "Console du navigateur" %>
Si nous devions recharger la fenêtre de notre navigateur manuellement, nos variables de session seraient naturellement perdues (vu que nous créerions une nouvelle session). D'un autre côté, si nous déclenchons un hot code reload (par exemple, en sauvegardant un de nos fichiers source) la page se rechargera, mais la variable de session sera encore initialisée. Essayez ça maintenant !
~~~js
❯ Session.get('pageTitle');
'A brand new title'
~~~
<%= caption "Console du navigateur" %>
Donc si nous utilisons des variables de session pour tracer exactement ce que l'utilisateur est en train de faire, le HCR devrait être transparent pour l'utilisateur, comme ça préserve la valeur de toutes les variables de session. Ceci nous permet de déployer en production des nouvelles versions de notre application Meteor avec l'assurance que nos utilisateurs seront dérangés de façon minimale.
Considérez ceci pour le moment. Si nous pouvons gérer de garder tous les états dans l'URL et la session, nous pouvons changer le code source en cours d'exécution de chaque client de l'application de manière transparente et avec un impact minimal.
Vérifions maintenant ce qu'il se passe quand nous rafraîchissons la page manuellement :
~~~js
❯ Session.get('pageTitle');
null
~~~
<%= caption "Console du navigateur" %>
Quand nous rechargeons la page, nous perdons la session. Dans un HCR, Meteor sauvegarde la session en local dans le navigateur et la recharge après le rechargement de la page. Cependant, le comportement alternatif d'un rechargement a du sens : si un utilisateur recharge la page, c'est comme s'il avait encore exploré la même URL, et il devrait être réinitialisé à l'état de départ que n'importe quel utilisateur devrait voir en visitant l'URL.
Les leçons importantes dans tout ça sont :
1. Toujours stocker l'état utilisateur dans la Session ou dans l'URL afin que les utilisateurs ne soient pas dérangés lors du Hot Code Reload.
2. Stockez chaque état que vous souhaitez mettre en commun entre les utilisateurs *à l'intérieur de l'URL elle-même*.
Cela conclut notre exploration de Session, une des fonctions les plus utiles de Meteor. N'oubliez pas d'annuler tous les changements de votre code avant de passer au chapitre suivant.