Meteor session

Session

Meteor is a responsive framework. This means that as the data changes, the app doesn't need to do anything explicitly.

In fact, we've seen how our templates change based on changes in data and routing rules.

We'll take a closer look at how this works in a later section, but now we'd like to introduce some basic responsive features that are useful for regular apps.

Meteor's Session

Now under Microscope, the user's current state in the app is completely contained in the URL and needs to be looked for from within the URL (or database).

In many cases, however, you need to store some transient states that correspond only to the current user's version of the application (for example, whether an element is displayed or hidden). Session makes it easy to do this.

Session is a global responsive data store. I ts globality means a global case object: this Session object is accessible globally. Global variables are often considered a good thing, but in the case of the previous example, Session could be used as a central communication bus in different parts of the project.

Modify session

Session Session globally accessible. Set the value of a Session that you can call:

❯ Session.set('pageTitle', 'A different title');

Browser console

Through Session.get('mySessionProperty'); You can reread the contents of the data, which is a responsive data source, which means that if you put it in a Helper, you'll see Helper change its output in response to changes in the Session variable.

Let's try adding the following code to the layout template:

<header class="navbar navbar-default" role="navigation"> 
  <div class="navbar-header">
    <a class="navbar-brand" href="{{pathFor 'postsList'}}">{{pageTitle}}</a>
  </div>
</header>

client/templates/application/layout.html

Template.layout.helpers({
  pageTitle: function() { return Session.get('pageTitle'); }
});

client/templates/application/layout.js

Code for the Appendix (Sidebar).

Please note that the code in the Appendix section is not part of the main process of this book. So either create a new branch (if you use Git) or make sure you restore the changes you made at the end of this chapter.

Meteor's auto-overload (that is, automatically refreshing a page using the Dynamic Code Overloading Technology (HCR) that we talk about later) saves Session's variables, so we should now see "different titles" appear in the navigation bar. If not, enter the Session.set() again.

Also, if we go to change its value (again in the browser console), we should see another title display:

❯ Session.set('pageTitle', 'A brand new title');

Browser console

Because of Session's global accessibleness, these changes can work anywhere in the application. This gives us a lot of power, but if you use too much it can also be a trap.

Also, it's important to note that session objects are not shared between users, even between browser tabs. That's why if you open your app now in a new browser tab, you'll see an empty website title.

the same change

If you Session.set() and modify it to the same value, Meteor is very clever at bypassing tedious operations and avoiding unnecessary method calls.

Autorun

We see an example of a responsive data source and see how it works in a template Helper. Although in some cases Meteor, such as template Helper, is responsive, most Meteor Apps are still based on plain non-responsive JavaScript code.

Let's assume that there are the following snippets in our app:

helloWorld = function() {
  alert(Session.get('message'));
}

Although we call a responsive session variable, it is not called in a responsive context, so when we change the Session variable, we do not automatically alert function.

This is the time to introduce the Autorun mechanism. As the name implies, the autorun automatically every time the responsive data source in autorun context changes.

Try entering into the browser console:

❯ Tracker.autorun( function() { console.log('Value is: ' + Session.get('pageTitle')); } );
Value is: A brand new title

Browser console

As you might expect, the code placed in the autorun function will run once, outputing the data to the console. Now, let's try to change the title:

❯ Session.set('pageTitle', 'Yet another value');
Value is: Yet another value

Browser console

It's amazing! As the Session variable changes, autorun it must rerun its code and re-output the new value to the console.

So let's go back to the previous example, if we want to raise a new alert every time the Session variable alert all we need to do is encapsulate autorun function:

Tracker.autorun(function() {
  alert(Session.get('message'));
});

As we saw earlier, autorun tracks responsive data sources and reacts as they change.

Dynamic code overloading technology

During the development of Microscope, we used Meteor's Dynamic Code Overload Technology (HCR) to save time: as soon as we modified and saved a source code file, Meteor detected the change, directly restarted the running Meteor server, and notified each client to reload the page.

This is similar to automatic page refreshes, but with one important difference.

To find out what that is, reset the session variable you changed earlier:

❯ Session.set('pageTitle', 'A brand new title');
❯ Session.get('pageTitle');
'A brand new title'

Browser console

If we manually overload the browser window, we will naturally lose our Session variable (because this will create a new session). O n the other hand, if we were to reload the page by triggering a dynamic code overload (that is, by modifying and saving our source file), the Session variable would still exist. Now give it a try!

❯ Session.get('pageTitle');
'A brand new title'

Browser console

Therefore, if you use the Session variable to save the user state, the user is barely aware of the occurrence of dynamic code overloading. B ecause it preserves the value of all Session variables. This minimizes the chance of user disruption when we deploy a new version.

Think again, this means that as long as we save all the states with URLs and Sessions, the application that the client is running can be dynamically overloaded when the version is updated without losing any data.

Now let's examine what happened when we went to manually refresh the page:

❯ Session.get('pageTitle');
null

Browser console

When we overloaded the page, we lost Session. I n HCR, Meteor Session saves to the browser's local storage and loads it again after overloading. However, the loss behavior that occurs when the page is overloaded makes sense: if the user reloads the page as if they had browsed the same URL again, and other users see the URL they are visiting, they should reset to the initial state.

From this we should learn:

1. User status should be stored in Session or URL. This minimizes the chance of a user interrupt when dynamic code is overloaded.
2. Use the URL as much as possible to store the state you want to share between users.

The above summarizes our exploration of session ——— one of the most useful features of The Meteor. Don't forget to restore your code changes before you go to the next chapter.