-
Notifications
You must be signed in to change notification settings - Fork 30
/
05s-the-session.md.erb
172 lines (116 loc) · 8.79 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 sesión
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: Aprenderemos cómo funciona la Sesión en Meteor.|Comprenderemos la función autorun.|Veremos la recarga automática de código o Hot Code Reload.
paragraphs: 33
---
Meteor es un framework reactivo. Esto significa que cuando cambian los datos, cambian cosas de la aplicación sin tener que hacer nada de forma explícita.
Ya lo hemos visto en acción viendo cómo cambian nuestras plantillas cuando cambian los datos y las rutas.
En capítulos posteriores veremos más en profundidad cómo funciona todo esto, pero ahora, nos gustaría introducir algunas características básicas de la reactividad, que son muy útiles en todas las aplicaciones.
### La sesión en Meteor
Ahora mismo, en Microscope, el estado actual de la aplicación está contenido en su totalidad en la URL que se está mostrando (y en la base de datos).
Pero en muchos casos, necesitarás almacenar valores de estado que solo son relevantes en la versión de la aplicación para usuario actual (por ejemplo, si algún elemento se muestra o está oculto). Usar la Sesión es una forma conveniente de hacerlo.
La sesión es un almacén global de datos reactivo. Es global en el sentido de que es un objeto global: solo hay una sesión, y esta es accesible desde todas partes. Las variables globales se suelen ver como algo malo, pero en este caso la sesión se utiliza como un bus de comunicación central para diferentes partes de la aplicación.
### Modificando la Sesión
La sesión está disponible en todas partes en el cliente como el objeto `Session`. Para establecer un valor en la sesión, puedes llamar a:
~~~js
❯ Session.set('pageTitle', 'A different title');
~~~
<%= caption "Consola del navegador" %>
Puedes leer los datos de nuevo con `Session.get('mySessionProperty');`. Hemos dicho que la Sesión es una fuente de datos reactiva, lo que significa que si lo pones en un ayudante, verías un cambio en el navegador cuando cambia la variable de sesión.
Para probarlo, añade el siguiente código a la plantilla 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 %>
### Una nota sobre el código de las barras laterales
Ten en cuenta que el código mostrado en las barras laterales no forma parte del flujo principal del libro. Por lo que debería crear una nueva rama (si estás usando Git), o si no, asegurarte de deshacer los cambios al final del capítulo.
<% end %>
La recarga automática de Meteor ("recarga de código en caliente" o HCR, de Hot Code Reload) preserva las variables de sesión, por lo que ahora debes ver "A different title" en la barra de navegación. Si no es así, solo tienes que escribir el comando `Session.set()` de nuevo.
Si lo cambiamos de nuevo (desde la consola del navegador), debemos ver que se visualiza otro título:
~~~js
❯ Session.set('pageTitle', 'A brand new title');
~~~
<%= caption "Consola del navegador" %>
La sesión está disponible a nivel global, por lo que los cambios se pueden hacer desde cualquier lugar de la aplicación. Esto nos da una gran cantidad de potencia y flexibilidad, pero también puede ser una trampa si se usa demasiado.
De todas formas, es importante apuntar que el objeto de Session *no* es compartido entre distintos usuarios, ni siquiera entre distintas pestañas del navegador. Esto es por lo que si abres tu aplicación en una nueva pestaña, te encontrarás con una página en blanco.
<% note do %>
### Cambios idénticos
Si modificas una variable de sesión con `Session.set()` pero la estableces al mismo valor, Meteor es lo suficientemente inteligente como para eludir la cadena reactiva, y evitar las llamadas a métodos innecesarios.
<% end %>
### Presentamos a Autorun
Hemos visto un ejemplo de una fuente de datos reactiva, y la hemos visto en acción dentro de un ayudante de plantilla. Pero mientras que algunos contextos en Meteor (como ayudantes de plantilla) son inherentemente reactivos, la mayoría de código de la aplicación sigue siendo el viejo y simple JavaScript.
Supongamos que tenemos el siguiente fragmento de código en algún lugar de nuestra aplicación:
~~~js
helloWorld = function() {
alert(Session.get('message'));
}
~~~
A pesar de que llamamos a una variable de sesión, el *contexto* en el que se hace no es reactivo, lo que significa que no vamos a ver `alerts` cada vez que cambia su valor.
Aquí es dónde entra en juego [Autorun](http://docs.meteor.com/#Tracker_autorun). Como su nombre indica, el código dentro de un bloque `autorun` se ejecutará automáticamente cada vez que cambien las fuentes de datos reactivas utilizadas dentro.
Prueba a escribir esto en la consola del navegador:
~~~js
❯ Tracker.autorun( function() { console.log('Value is: ' + Session.get('pageTitle')); } );
Value is: A brand new title
~~~
<%= caption "Consola del navegador" %>
Como era de esperar, el bloque de código situado en el interior de `autorun` se ejecuta una vez, mostrando los datos por la consola. Ahora, vamos a intentar cambiar el título:
~~~js
❯ Session.set('pageTitle', 'Yet another value');
Value is: Yet another value
~~~
<%= caption "Consola del navegador" %>
¡Magia! Al cambiar el valor, `autorun` sabe que tiene que ejecutar su contenido de nuevo, volviendo a mostrar el nuevo valor por la consola.
Volviendo a nuestro ejemplo anterior, si queremos activar una nueva alerta cada vez que cambien variables de sesión, lo único que tenemos que hacer es envolver nuestro código en un bloque `autorun`:
~~~js
Tracker.autorun(function() {
alert(Session.get('message'));
});
~~~
Como acabamos de ver, los `autorun` pueden ser muy útiles para rastrear fuentes de datos reactivas y reaccionar inmediatamente ante ellos.
### Recarga automática de código
Durante el desarrollo de Microscope, hemos estado aprovechando una de las características de ahorro de tiempo que proporciona Meteor: La recarga de código en caliente (HCR). Cada vez que guardamos uno de nuestros archivos fuente, Meteor detecta los cambios y reinicia el servidor de forma trasparente, informando a todos los clientes para que recarguen la página.
Es similar a una recarga automática de página, pero con una diferencia importante.
Para entenderlo, vamos a restablecer la variable de sesión que hemos estado utilizando:
~~~js
❯ Session.set('pageTitle', 'A brand new title');
❯ Session.get('pageTitle');
'A brand new title'
~~~
<%= caption "Consola del navegador" %>
Si recargáramos la página manualmente se perderían las variables de sesión (porque que estaríamos creando una nueva). Pero si provocamos una recarga en caliente (por ejemplo, guardando uno de nuestros archivos de código), la página volverá a cargar, pero todavía tendremos el valor de la variable de sesión. ¡Pruébalo!
~~~js
❯ Session.get('pageTitle');
'A brand new title'
~~~
<%= caption "Consola del navegador" %>
Así que si utilizamos variables de sesión para hacer un seguimiento de lo que está haciendo el usuario, el HCR debe ser prácticamente trasparente para el usuario, ya que preserva el valor de todas las variables de sesión. Esto nos permite desplegar nuevas versiones de nuestra aplicación, ya en producción, con la seguridad de que no molestaremos mucho a nuestros usuarios.
Considera esto un momento. Si podemos llegar a mantener el estado entre la URL y la sesión, podemos cambiar de forma trasparente el _código que está corriendo_ por debajo con una mínima interrupción.
Ahora vamos a comprobar lo que pasa cuando refrescamos la página de forma manual:
~~~js
❯ Session.get('pageTitle');
null
~~~
<%= caption "Browser console" %>
Hemos perdido la sesión. En un HCR, Meteor guarda la sesión en el almacenamiento local del navegador y lo carga de nuevo tras la recarga. Esto no significa que el comportamiento de recarga explícita no tenga sentido: si un usuario recarga la página, es como si navega de nuevo a la misma URL, y el estado, debe restablecerse al que vería cualquier usuario que visita esa URL.
Las lecciones más importantes en todo esto son:
1. Guarda siempre el estado en la sesión o en la URL para no molestar mucho a los usuarios cuando ocurre una recarga en caliente.
2. Almacena cualquier estado que deba estar compartido entre usuarios *dentro de la propia URL*.
Con esto concluye nuestra exploración de la sesión, uno de las características más útiles de Meteor. No olvides deshacer cualquier cambio en el código antes de pasar al siguiente capítulo.