WEBVTT
00:00:00.000 --> 00:00:00.880 align:middle line:84%
00:00:00.880 --> 00:00:03.440 align:middle line:90%
We've talked a lot about what
happens when we subscribe
00:00:03.440 --> 00:00:05.700 align:middle line:90%
to a Publish
function like Items,
00:00:05.700 --> 00:00:07.540 align:middle line:90%
and how those
messages get sent down
00:00:07.540 --> 00:00:10.460 align:middle line:90%
to the client as DVP
messages, like the Added
00:00:10.460 --> 00:00:12.150 align:middle line:84%
message and the Ready message.
00:00:12.150 --> 00:00:14.730 align:middle line:84%
00:00:14.730 --> 00:00:16.309 align:middle line:90%
But what happens
to these messages
00:00:16.309 --> 00:00:18.110 align:middle line:84%
when they get to the client?
00:00:18.110 --> 00:00:21.070 align:middle line:90%
In this video, we'll
explore just that.
00:00:21.070 --> 00:00:22.890 align:middle line:90%
For the rest of the
video, on the right,
00:00:22.890 --> 00:00:24.040 align:middle line:84%
I'll have the browser.
00:00:24.040 --> 00:00:26.410 align:middle line:90%
And this will be
the client browser,
00:00:26.410 --> 00:00:28.930 align:middle line:90%
not the one used to
debug the server.
00:00:28.930 --> 00:00:30.660 align:middle line:90%
And on the left,
I'll have my code.
00:00:30.660 --> 00:00:33.850 align:middle line:84%
00:00:33.850 --> 00:00:35.440 align:middle line:90%
Normally, you'll
create a collection
00:00:35.440 --> 00:00:37.880 align:middle line:90%
that will exist on both
the client and the server.
00:00:37.880 --> 00:00:41.600 align:middle line:90%
For example, we might create
a collection called Items.
00:00:41.600 --> 00:00:46.310 align:middle line:90%
And we do that by calling a
New with the Meteor.collection
00:00:46.310 --> 00:00:48.190 align:middle line:84%
and giving it a name.
00:00:48.190 --> 00:00:52.010 align:middle line:90%
What this actually does
under the hood when
00:00:52.010 --> 00:00:53.610 align:middle line:90%
we create this new
collection is it
00:00:53.610 --> 00:00:56.190 align:middle line:90%
registers itself
with the connection.
00:00:56.190 --> 00:00:58.960 align:middle line:90%
In this video, we're just going
to do that directly so you
00:00:58.960 --> 00:01:01.790 align:middle line:84%
can see what's happening.
00:01:01.790 --> 00:01:05.820 align:middle line:90%
In the client, what I can
do is get the DVP connection
00:01:05.820 --> 00:01:09.155 align:middle line:90%
and call a function on
it named Register Store.
00:01:09.155 --> 00:01:11.930 align:middle line:84%
00:01:11.930 --> 00:01:13.340 align:middle line:90%
And then, we give
the store a name.
00:01:13.340 --> 00:01:16.080 align:middle line:90%
In this case, we'll
call it Items.
00:01:16.080 --> 00:01:18.470 align:middle line:90%
And then an object, which
will have some methods
00:01:18.470 --> 00:01:19.280 align:middle line:84%
that we need to define.
00:01:19.280 --> 00:01:21.860 align:middle line:84%
00:01:21.860 --> 00:01:24.750 align:middle line:90%
So a store will be the
minimum API required
00:01:24.750 --> 00:01:27.620 align:middle line:90%
to interface between
a local data cache
00:01:27.620 --> 00:01:30.920 align:middle line:84%
and the Live Data connection.
00:01:30.920 --> 00:01:33.260 align:middle line:90%
So there's a couple of methods
that we'll define in the store.
00:01:33.260 --> 00:01:36.780 align:middle line:90%
And we'll even come back to
this when we talk about RPC.
00:01:36.780 --> 00:01:38.120 align:middle line:90%
But to get us
started, we're just
00:01:38.120 --> 00:01:40.160 align:middle line:84%
going to look at three methods.
00:01:40.160 --> 00:01:43.860 align:middle line:90%
The first is called
Begin Update.
00:01:43.860 --> 00:01:47.380 align:middle line:90%
And it takes a batch
size and a function
00:01:47.380 --> 00:01:50.720 align:middle line:90%
called Reset, in case we're
resetting the whole store.
00:01:50.720 --> 00:01:54.180 align:middle line:90%
And the second
function called Update.
00:01:54.180 --> 00:01:56.910 align:middle line:90%
And the Update function
will get called
00:01:56.910 --> 00:01:59.630 align:middle line:90%
with a message object, which
we'll look at more carefully
00:01:59.630 --> 00:02:00.490 align:middle line:84%
in a second.
00:02:00.490 --> 00:02:02.310 align:middle line:84%
And finally, End Update.
00:02:02.310 --> 00:02:05.310 align:middle line:84%
00:02:05.310 --> 00:02:08.780 align:middle line:90%
So when we get an update off
the wire, what's going to happen
00:02:08.780 --> 00:02:11.060 align:middle line:90%
is what's called a
transactional update.
00:02:11.060 --> 00:02:14.040 align:middle line:90%
And so first, the Begin Update
function will get called.
00:02:14.040 --> 00:02:17.200 align:middle line:90%
And then, the actual Update
function with the message
00:02:17.200 --> 00:02:19.730 align:middle line:84%
off of the DVP wire.
00:02:19.730 --> 00:02:23.290 align:middle line:90%
And then, End Update
when we're done.
00:02:23.290 --> 00:02:24.710 align:middle line:90%
To get a sense of
what's happening,
00:02:24.710 --> 00:02:26.730 align:middle line:84%
let's create some console logs.
00:02:26.730 --> 00:02:29.310 align:middle line:90%
I'm going to say
this is Begin Update.
00:02:29.310 --> 00:02:32.910 align:middle line:84%
00:02:32.910 --> 00:02:36.570 align:middle line:84%
And I'll pass the batch size.
00:02:36.570 --> 00:02:44.790 align:middle line:84%
00:02:44.790 --> 00:02:46.270 align:middle line:90%
And when we get an
update, I'll just
00:02:46.270 --> 00:02:50.960 align:middle line:90%
print to the console "update"
and a stringified version of
00:02:50.960 --> 00:02:55.020 align:middle line:84%
the message so we can see it.
00:02:55.020 --> 00:03:00.680 align:middle line:90%
And then finally, on End Update,
I'll just print "end update."
00:03:00.680 --> 00:03:03.634 align:middle line:90%
And to make this a
little bit easier to see,
00:03:03.634 --> 00:03:04.800 align:middle line:90%
when we're done
with the update I'm
00:03:04.800 --> 00:03:07.040 align:middle line:84%
going to print out some stars.
00:03:07.040 --> 00:03:10.565 align:middle line:90%
And I'll put some stars up here
in the Begin Update as well.
00:03:10.565 --> 00:03:11.365 align:middle line:84%
OK.
00:03:11.365 --> 00:03:12.950 align:middle line:90%
So now we have a
store that we've
00:03:12.950 --> 00:03:14.750 align:middle line:90%
registered with the
Meteor connection,
00:03:14.750 --> 00:03:17.110 align:middle line:84%
or the Live Data DVP connection.
00:03:17.110 --> 00:03:18.530 align:middle line:84%
And the store is called Items.
00:03:18.530 --> 00:03:22.430 align:middle line:90%
And here's the API that lets
it work with DVP messages that
00:03:22.430 --> 00:03:24.530 align:middle line:84%
come off the wire.
00:03:24.530 --> 00:03:26.560 align:middle line:90%
Then, we're subscribing
to the item's publication.
00:03:26.560 --> 00:03:29.630 align:middle line:90%
And on the server, this just
calls the Added function
00:03:29.630 --> 00:03:32.790 align:middle line:90%
once, which is going to send
one Added message to the client.
00:03:32.790 --> 00:03:35.940 align:middle line:90%
Now, when I press Save, we
can go over to the browser
00:03:35.940 --> 00:03:38.320 align:middle line:84%
and take a look.
00:03:38.320 --> 00:03:39.390 align:middle line:84%
I got an error in the browser.
00:03:39.390 --> 00:03:43.730 align:middle line:90%
And that's just because
I misspelled stringify.
00:03:43.730 --> 00:03:48.210 align:middle line:90%
Once I fix that and we subscribe
to the Items publication,
00:03:48.210 --> 00:03:51.460 align:middle line:90%
the server will send the
Added message, which we
00:03:51.460 --> 00:03:53.195 align:middle line:84%
can see in the network console.
00:03:53.195 --> 00:03:56.230 align:middle line:84%
00:03:56.230 --> 00:03:58.250 align:middle line:90%
And once the Live
Data connection
00:03:58.250 --> 00:04:00.690 align:middle line:90%
gets this Added
message, it sees that we
00:04:00.690 --> 00:04:03.120 align:middle line:84%
do have a store in the message.
00:04:03.120 --> 00:04:05.560 align:middle line:90%
It's called a
collection called Items.
00:04:05.560 --> 00:04:07.350 align:middle line:90%
And we've defined
that over here.
00:04:07.350 --> 00:04:10.300 align:middle line:90%
And then, it will begin
a transactional update.
00:04:10.300 --> 00:04:14.010 align:middle line:90%
And so you can see on
the second one here,
00:04:14.010 --> 00:04:15.670 align:middle line:84%
at first, it calls Begin Update.
00:04:15.670 --> 00:04:17.339 align:middle line:90%
And we have a batch
size of one, because we
00:04:17.339 --> 00:04:18.560 align:middle line:84%
just have one document.
00:04:18.560 --> 00:04:20.129 align:middle line:90%
And then, here's
our Update message.
00:04:20.129 --> 00:04:25.500 align:middle line:84%
00:04:25.500 --> 00:04:27.110 align:middle line:90%
And so we can
choose to do what we
00:04:27.110 --> 00:04:29.570 align:middle line:84%
want with that Update message.
00:04:29.570 --> 00:04:32.100 align:middle line:90%
But Mini Mongo, for
example, would update
00:04:32.100 --> 00:04:33.910 align:middle line:84%
the local cache of your data.
00:04:33.910 --> 00:04:37.150 align:middle line:90%
And then, once that's done,
the End Update method is
00:04:37.150 --> 00:04:40.560 align:middle line:84%
called to end the transaction.
00:04:40.560 --> 00:04:42.290 align:middle line:90%
When we get to the
class on Mini Mongo,
00:04:42.290 --> 00:04:44.310 align:middle line:90%
we'll cover how
they implement this,
00:04:44.310 --> 00:04:47.030 align:middle line:90%
or that package implements
this, in more detail.
00:04:47.030 --> 00:04:48.930 align:middle line:90%
Now, let's take a look at
some of the other messages
00:04:48.930 --> 00:04:51.720 align:middle line:84%
that can be sent.
00:04:51.720 --> 00:04:55.910 align:middle line:90%
After we send the initial Added
message, let's set a timeout.
00:04:55.910 --> 00:04:59.280 align:middle line:90%
And we'll just use
JavaScript to send
00:04:59.280 --> 00:05:01.130 align:middle line:84%
another one in three seconds.
00:05:01.130 --> 00:05:03.740 align:middle line:90%
And that will be
a Changed message.
00:05:03.740 --> 00:05:07.890 align:middle line:90%
So we'll change the
document with an ID of 1.
00:05:07.890 --> 00:05:09.390 align:middle line:84%
And we'll just change the title.
00:05:09.390 --> 00:05:13.100 align:middle line:84%
00:05:13.100 --> 00:05:16.530 align:middle line:90%
And then, three seconds
later from that--
00:05:16.530 --> 00:05:20.930 align:middle line:90%
so I'll just say in
6,000 milliseconds--
00:05:20.930 --> 00:05:23.130 align:middle line:84%
we'll send a Removed message.
00:05:23.130 --> 00:05:30.384 align:middle line:84%
00:05:30.384 --> 00:05:31.650 align:middle line:90%
I've gotten rid of
the network for you
00:05:31.650 --> 00:05:37.520 align:middle line:90%
so we can get a better view
of the store console logs.
00:05:37.520 --> 00:05:39.480 align:middle line:90%
So we can see the first
transaction happens
00:05:39.480 --> 00:05:41.410 align:middle line:84%
here for the Added message.
00:05:41.410 --> 00:05:47.010 align:middle line:90%
And then, three seconds later,
we get the second update.
00:05:47.010 --> 00:05:49.220 align:middle line:90%
And this time, the
message is Changed.
00:05:49.220 --> 00:05:50.820 align:middle line:90%
So it's pretty much
the same as what
00:05:50.820 --> 00:05:52.970 align:middle line:84%
comes off of the wire from DVP.
00:05:52.970 --> 00:05:55.370 align:middle line:90%
And then, the third message,
a couple seconds later,
00:05:55.370 --> 00:05:57.905 align:middle line:90%
is to remove the document
from the collection.
00:05:57.905 --> 00:06:02.340 align:middle line:84%
00:06:02.340 --> 00:06:05.280 align:middle line:90%
Now once again, typically we
wouldn't call Register Store
00:06:05.280 --> 00:06:07.330 align:middle line:90%
ourselves unless we
were implementing
00:06:07.330 --> 00:06:11.200 align:middle line:90%
a client-side database
like Mini Mongo.
00:06:11.200 --> 00:06:15.130 align:middle line:90%
But I wanted to show you what
that API looks like, so you can
00:06:15.130 --> 00:06:18.060 align:middle line:90%
get an intuitive sense of
what's happening under the hood
00:06:18.060 --> 00:06:20.900 align:middle line:90%
when one of these messages
comes off the wire.
00:06:20.900 --> 00:06:23.380 align:middle line:90%
Namely, every time we
create a new collection,
00:06:23.380 --> 00:06:28.440 align:middle line:90%
it registers itself as a store
with the Live Data connection.
00:06:28.440 --> 00:06:30.980 align:middle line:90%
And then, Live Data connection
can call these methods--
00:06:30.980 --> 00:06:34.270 align:middle line:90%
Begin Update, Update, and
End Update-- every time
00:06:34.270 --> 00:06:36.538 align:middle line:84%
it wants to update the store.
00:06:36.538 --> 00:06:37.338 align:middle line:84%