 Felly rydw i'n cael ei gael i'r gwahog ar gyfer y brif feddwl hwnnw. Rydw i'n cael ei ddweud y ffordd i'r twf, mae'n iawn i'r Cwmp yn Llyfrgell. Mae'r cyfnod i'r llaw i'r llaw i'r awr hwnnw i'r brif yn gweithio'r cynnig oherwydd rydw i fynd i'r cyfnod am gyfnod, ymlaen i'r cyfnod i'r cyfnod. It's oligopt.com. First you nothing at the moment, but it does happen in the store. I'll just show you very simply on the dev environment, currently which one we use, probably Singh's Bell. He used the most. None of that one. It basically pulls through five records at a time. I scroll, I'll be another few, and then I'll be a few, and I'll make this as that. So okay, it's a pretty straight forward. I should never have resized it. I have to always forget the screen trouble. Okay, so scroll length is pretty simple. First off you need some kind of publication that tells you how many records it's going to pull back. So the way I do that one, like pulling back the discussions, is just to make sure that I, well in this case I'm taking a name of the particular, whatever other kind of filter criteria you're looking for, but also a limit. So the limit is the number of records, and then when you return the cursor, you specify, so this is your kind of filter criteria, then I specify a sort order, and then the limit. The reason for obviously specifying a sort order is that when you're pulling back multiple records and setting a limit, you need to make sure that you're pulling back top five, top 10, top 15, or whatever, rather than just throwing back a bunch of them randomly. So you're kind of controlling your published data set. In the job script, so I've got a template level subscription using Blaze, that's set up within an auto run. So although it's within the created event for the template, by putting it with an auto run it means it'll re-run every time something changes. So I subscribe to that publication here, pass it the name of the particular data provider I'm looking for at the time, and then I pass it how many records I want. Now, how many records has been defined as a reactive variable, which is initialised to five. That's why it pulls back five records initially, when the auto run runs for the first time, and then creates the kind of reactivity. And then all I do is I set up a render function. So when I render, all I do is I say when I've scrolled down a certain level, in this case it's like within sort of 200 pixels at the bottom of the page, if my subscriptions have been loaded, which mostly they will have been, might as well get to that stage, if I've not yet exceeded the number of records I want to get, haven't yet exceeded the number of records that I know I can find, then just increment the number of records I'm looking for by five. And because that's a reactive variable, that will then cause this auto run to rerun, which will basically go back and subscribe with now 10 instead of five to that self saying publication that we know here. And it's now going to pull back top 10 records. So every time you scroll, it just keeps pulling them back. And because it meets your reactivity, it means when I actually display them somewhere down here. So, sorry, that's the wrong one here, down here. So fridge discussion is a comment. Because there's now new discussions, place-to-place reactivity causes those discussions to kind of be extended, loaded, new data floods in, and the new records pop up for as long as their variables keep scrolling. And that's it, that's like, meets your homegrown infinite scroll. So Duncan, when a new discussion has been started, which is obviously then played at the top, what happens to the rest of, so let's say you loaded the last 15 ones, now you get a new one which is making it 16, what is happening there? Is it going to push the last number 16 now, because it's still going to display only 15, or is it because you've loaded already, it will display the 16? It will display 15. So it pushes. It will push down, it will push down. But that said, chances are if you're actually on the bottom records, you're already at the bottom of the screen so that that kind of scroll is going to kick in again, and sort of say, oh, you've got more go. The second question is because I'm no longer in the visible part. So I see, let's say, number 8 to 16 visually on my screen, and there's a new discussion coming out. Is it automatically jumping to the top? Yes, because the publication is going to be ordered. So because I've got a time stamp. Most records you're going to use in this instance have got some kind of time stamp for you. So you can get a lot more sophisticated and try to play around with a Facebook-style equivalent, where actually rather than publishing based on limits, you push all the new stuff to the clients as well. And then you can have reactivity to note it by you that there are new ones. You've got an optional button that pops up to do that. But this is like the most simple way to get started with an infinite scroll. Because I'm not sure if you guys have seen that in the Learn.js properly group. There was a guy in Malaysia who is post a geosentic, and he has done some stuff about the general election. He has very nice application. But what happened because right now everyone has been crazily tweeting about anything there, it's like you're just trying to read an entry, because there are so many new people said you constantly use it, and it pushes you up front. This one would be the same behaviour. So you have to think about to either have a pause button in there, or actually buffer it for a period of time, because otherwise you'll always lose the context. It's very dependent on the context of what it is you're utilizing for infinite scroll. So if you've got things where you have new items, it might be inserted at the top rather than at the bottom. In this instance I'm doing it effectively in a reverse time order. So obviously if you have a situation where it's actually in chronological order, it's much simpler, because as new things appear on the bottom, you just scroll further than they appear. It's when things are coming at the top that you tend to have that issue. I think it has more to do with how much new content is coming in per certain amount of time. You're also assuming that that content is coming in at the top or on the bottom? Even at the bottom, if you would put it at the bottom, it would still automatically scroll there, I think. It would be adding it to the bottom as a case? Yes, but because it then goes out of your window, what happens is the algorithm is pushing it up, and I wasn't finished reading that line. The algorithm has pushed the scrolling. I think it doesn't matter if you push it at the top or at the bottom, it will just walk away. So if things are coming in at the bottom, it's not going to make the screen. Okay, but when we put it at the top, then it's moving the screen. It goes back to the top. It's not moving the screen. It's just new records coming in. It's automatic, we will update the DOM, because within the blaze template. It's not moving the screen, but by adding something at the top it may mean that things are moving. So if new stuff gets pushed in reactively, it will start to fill it out. But again, so this is a simple example of how to get started for gist with some kind of infinite scroll. You do have to think about there are circumstances where you may or may not want to actually automatically use the reactivity of the DOM as new data arrives. And now it requires a little bit more handle for those situations. What I like about Duncan is that, that's why I said I was interested in it, because basically an application we're most likely going to look at maybe sometimes 200 entries are popping up. It's one of the nice things, yeah. You would just load loads. I'm only interested in the top whatever, right? Yes, so with Meteor, because you have that reactivity, what you're doing with your publication and subscription is actually in the background, which is why there are a lot of some of the most popular social apps do, in the background your publication can still be pushing data to your subscription. So it's being catched in the mini-mongo or whatever in the future is used on the client side. But your client side code can still be limiting the subset of the mini-mongo that it's displaying or using your action to say, show me the new stuff. And you can use reactivity to basically be saying, is there new stuff yet or not to maybe put out some kind of, you know, again I used the Facebook example like, you know, when that little sort of new feeds or new posts or whatever the phrase is like appears on screen. So you can have reactivity to say, is there new stuff if so, pop this up. But only when you click the actual action to say, no, fill it out. But again, that's, you can do it. It's more about doing that sort of stuff and depends very much on the use case. When you'll be subscribed again with a new limit, does that mean when you download again all of those data? So if you look at the, no, there's a short answer. So when we look at the behaviour, so because it's a template level subscription, I should be able to go back then forward again. So if you look when you scroll, you can see it's not, it doesn't look like it's sort of refreshing a whole lot. So I think, I may be wrong because it's like the development sort of stuff. It's not production level scalability. But my understanding of Meet Your Wrist, the DB principle on publication of subscription is kind of smart enough to sort of push difference rather than everything. There's some bait wording about it in the documentation. OK. And that's it. Quick one on infant scroll. Does anyone need to go to the bathroom?