-
Notifications
You must be signed in to change notification settings - Fork 6
/
Copy path05s-the-session.md.erb
157 lines (107 loc) · 11.8 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
---
title: Сесія
slug: the-session
date: 0005/01/02
number: 5.5
sidebar: true
contents: Познайомимося з Meteor сесіями|Вивчимо функцію autorun|Познайомимось з гарячим перезавантаженням коду - Hot Code Reload
paragraphs: 36
---
Meteor -- це реактивний фреймворк. Це значить, що якщо змінюються дані, то змінюються речі в вашому додатку без необхідності вам що небудь робити.
Ми вже бачили це в роботі, коли наші шаблони змінювались при зміні даних і маршрутів.
В наступних розділах ми розберемося глибше в тому, як це працює, але на разі нам би хотілося представити лише деякі базові реактивні функції, які є надзвичайно корисними в загальних додатках.
### Сесії Meteor
Прямо зараз в Microscope, поточний стан додатку користувача повністю міститься в URL, на який вони дивляться (і базі).
Але у багатьох випадках, вам треба зберігати деякий ефемерний стан, який пов’язаний тільки з поточною версією додатку (наприклад, якщо елемент показано або скрито). Сесія -- це зручний спосіб для цього.
Сесія -- це глобальний хранитель реактивних даних. Глобальний у сенсі глобального одиничного об’єкту: існує одна сесія і вона доступна звідусіль. Глобальні змінні звичайно є поганою практикою, але в цьому випадку сесія використовується як центральний комунікативний провід для різних частин додатку.
### Зміна сесії
Сесія всюди доступна як `Session`. Для встановлення значення сесії дати виклик:
~~~js
❯ Session.set('pageTitle', 'A different title');
~~~
<%= caption "Консоль браузера" %>
Ви можете зчитати дані знову за допомогою `Session.get('mySessionProperty');`. Це реактивне джерело даних, що значить, що якщо ви поклали щось в помічник, то ви побачите, що вихід з помічника зміниться реактивно як змінюється змінна Session.
Щоб це перевірити, добавте наступний код до шаблону макету:
~~~html
<header class="navbar">
<div class="navbar-inner">
<a class="brand" href="{{pathFor 'postsList'}}">{{pageTitle}}</a>
</div>
</header>
~~~
<%= caption "client/views/application/layout.html"%>
~~~js
Template.layout.helpers({
pageTitle: function() { return Session.get('pageTitle'); }
});
~~~
<%= caption "client/views/application/layout.js"%>
Автоматичне перезавантаження Meteor (также відомий як гаряче перезавантаження коду - “hot code reload” або HCR) консервує змінні сесії, тому ми побачимо тепер "A different title" в навігаційному барі. Якщо ні, просто наберіть знову попередню команду `Session.set()`.
Більш того, якщо ми змінимо значення ще раз (знову в консолі браузера), то ми побачимо вже інший заголовок:
~~~js
❯ Session.set('pageTitle', 'A brand new title');
~~~
<%= caption "Консоль браузера" %>
Сесія доступна глобально, тому такі зміни можуть бути зроблені з любого місця додатку. Це дає нам великі можливості, але і часто може слугувати пасткою,якщо використовується занадто часто.
<% note do %>
### Ідентичні зміни
Якщо ви змінюєте змінну Сесії через `Session.set()`, але встановлюєте її в те ж саме значення, то Meteor достатньо розумний, щоб обійти реактивну ланку і уникнути зайвого виклику методу.
<% end %>
### Ознайомлення з автозапуском
Ми поглянули на приклад реактивного джерела данних і побачили його у дії всередині помічника шаблону. Але деякі хоча контексти в Meteor (такі як помічники шаблонів) являються реактивними, більшість коду додатку Meteor являється простим старим нереактивним JavaScript кодом.
Давайте уявімо, що маємо наступний код сніппету десь у нашому додатку:
~~~js
helloWorld = function() {
alert(Session.get('message'));
}
~~~
Навіть коли ми викликаємо змінну сесії, *контекст*, в якому він викликається не є реактивним, значить, що ми не будемо отримувати кожен раз нове сповіщення після виклику змінної.
Ось де стає в нагоді [автозапуск](http://docs.meteor.com/#deps_autorun). Коли використовується ім’я, то код всередині `autorun` блок буде автоматично запускатись і виконуватись кожен раз, коли змінюються джерела реактивних даних всередині нього.
Спробуйте набрати це у консолі браузера:
~~~js
❯ Deps.autorun( function() { console.log('Value is: ' + Session.get('pageTitle')); } );
Value is: A brand new title
~~~
<%= caption "Консоль браузера" %>
Як ви і очікуєте блок коду всередині `autorun` запуститься раз, виведе свої дані у консоль. Тепер давайте змінимо заголовок:
~~~js
❯ Session.set('pageTitle', 'Yet another value');
Value is: Yet another value
~~~
<%= caption "Консоль браузера" %>
Магія! Так як змінилося значення сесії, то `автозапуск` знав, що він має запустити свої дані знову і перевивести нові значення у консоль.
Повертаючись назад до попереднього прикладу. якщо ми хочемо запустити нове сповіщення кожен раз при зміні значення сесії, то нам достатньо обгорнути наш код в блок `autorun`:
~~~js
Deps.autorun(function() {
alert(Session.get('message'));
});
~~~
Як ми тільки що побачили, автозапуск може знадобитись для відслідковування реактивних даних і реагувати миттєво на них.
### Гаряче перезавантаження коду -- Hot Code Reload
Під час нашої розробки Microscope, ми користувались перевагами однієї з Meteor функцій, що економлять час: гарячого перезавантаження коду -- hot code reload (HCR). Де б ми не зберігали файли нашого коду, Meteor виявляв зміни і прозоро рестартував Meteor сервер, інформуючи кожного клієнта про перезавантаження сторінки.
Це щось схоже на автоматичне перезавантаження сторінки, але є важлива відмінність.
Для з’ясування що це таке, почнемо з переназначення змінної сесії, яку ми тільки що використовували:
~~~js
❯ Session.set('pageTitle', 'A brand new title');
❯ Session.get('pageTitle');
'A brand new title'
~~~
<%= caption "Консоль браузера" %>
Якщо б ми перезавантажували вручну наше вікно браузера, то наші змінні сесії природньо були б втрачені (так як це б просто створювало нову сесію). З іншого боку, якщо ми запустимо гаряче перезавантаження коду (наприклад, зберігання наших вихідних файлів), то сторінка перезавантажиться, але змінна сесії як і раніше буде стала. Спробуйте це зараз!
~~~js
❯ Session.get('pageTitle');
'A brand new title'
~~~
<%= caption "Консоль браузера" %>
Тому якщо ми використовуємо змінні сесії для відслідковування того, що робить користувач, то HCR буде майже прозорим для користувача, так як воно буде зберігати значення всіх змінних сесії. Це дозволяє нам розміщувати нові продуктові версії наших Метеор-додатків з впевненністю у тому, що наші користувачі будуть потривожені мінімально.
Уявіть на хвильку. Якщо ми зможемо тримати все з нашого стану в URL і сесії, то ми можемо прозоро змінювати _виконуємий вихідний код_ кожного клієнтського додатку під ними з мінімальними втратами.
Давайте перевіримо, що відбувається, коли ми оновлюємо вручну сторінку:
~~~js
❯ Session.get('pageTitle');
null
~~~
<%= caption "Консоль браузера" %>
Коли ми перезавантажуємо сторінку, ми втрачаємо сесію. При гарячому перезавантаженні Метеор зберігає сесію в локальному сховищі вашого браузеру і завантажує її знову після перезавантаження. Однак, альтертативна поведінка в запобіганні перезавантаження має сенс: якщо користувач перезавантажує сторінку, це ніби він йде на ту саму сторінку знову і дані повинні обнулитись до початкового стану, такого яким він має бути для користувача, що вперше зайшов на цей URL.
Важливі висновки з усього цього:
1. Завжди зберігайте стан користувача в сесії чи в URL, щоб користувачі мінімально втрачали.
2. Будь-який стан, яким ви хочете поділитись між користувачами, зберігайте *всередині самого URL*.