 I have a freelance gig. Don't send it my way. I'm too busy. So busy that I haven't even made the slides. What I have made is this tutorial, this workshop. I've turned it into instructions. So you can visit this GitHub URL and browse the code with instructions with me using the tags. So you should check out the tag 0 first. So today, we'll try to build a RSS reader. So this will be our end result. Yep, this will be. So it is called yet another RSS reader, YAR. So we'll have this simple entry to read the post, to fetch the post, add new post, and filter by the feed, filter by if we have read it or not. And we'll not use any frameworks. What we will use is RxJS library. Anybody familiar with FRP or RxJS? Anyone? Something with the adapter. Is it readable now? OK. So this is what we are going to build using RxJS. So first of all, we'll get into what RxJS is, what FRP is. First, are you guys going to follow with me or just going to watch? Is it visible now? So I guess you guys are just going to watch. So we'll do a show. So is there nobody following? Really? The URL? This it is. Yeah, github.com slash that. Yeah, that's a Punjabi name, so bear with me. All right, so we'll use ES6. It is awesome, that's why. And we use Webpack to compile everything to ES5. And RxJS, we'll come to that. So if you are following, better just clone this repo. Check out to this tag too. Check out just press 0 and tab. And it will take you to the tag. So I'm already there. So first thing you would do is install the npm dependencies. npm i, it will install stuff from package.json. So what do we have in package.json? These are the dev dependencies for, it is readable? Not at all. Want is good, actually. Adapter is bad. Is it? Well, cool that. So in dev dependencies, we have this Babel core, Babel loader, and all that, the Webpack stuff. Drop it. And in dependencies, we have Babel runtime. We need it for, say, some ES6 features. And it is good to have because it helps optimizing the transpilation. And we have our app divided over several files. And we have this HTML to H script. We'll use virtual DOM. So at the point, we get the HTML feed. So we have to convert that HTML strings to virtual DOM. That is what it is for. And we'll have offline storage because an RSS reader without offline storage is not an RSS reader. I just said that. We are going to build an RSS reader. And we'll not use any framework. We'll use RxJS library. And is this what you were asking? We'll get to Rx. Forget Rx for now. You know virtual DOM? We'll get to all of them. Just listen why these things are here for now. So Dexy is a library over abstraction over indexed dv. We'll use that for offline storage. And there will be jQuery. We will not really use it, but it will be there. And Rx, of course, and virtual DOM. All right then. So let us drop the webpack stuff. This is the webpack config if you would be interested. But let us assume that everything is working like magic. And so what we are going to do is we are going to, we'll write our source code in the source folder. And everything in the source folder will be compiled to one file in the disk folder. And it will be called app.js. So that's what we include in our indexed HTML file. That's it. Next, we just start with the coding. So for testing, we just have a console.hello world. And I'll start the webpack server. No, you can't. If you want to use that, you can't. Then you'll have to run webpack in watch mode so that it will keep watching the changes that we are making. And webpack will provide us this library load. Got any? So and webpack actually don't write. Webpack dev server will not write files to file system. So the library load is very fast. Let's not get into it. So our code is running. Webpack is all set up. Let us start with what is next. The second tag for the first step. So what is RX? RX stands for reactive extensions. So heard of reactive programming? Anyone? OK. So reactive programming is like when we say we have data in our apps, right? So when data changes, we have to monitor it and watch for changes and do the appropriate changes elsewhere in the data or in the UI. So reactive programming is what we shall call that we change the data and the UI should react to it. Or anything that is using the data should react to it. That is what react does, right? React, we have state to change the state, the UI plates. That is what Angular scope does, Angular 1 scope. And Angular 2 does the same thing using observables. So that is what we are going to use here directly. So we know what a promise is, right? So promise is a value which don't have its data at one point of time. When we create a promise, we don't really have the data. We create a promise and then promise resolves sometime in future. Promise resolves once. We get one value. The observable is like an array of promises, a collection of asynchronous data. It will resolve more than once. And it is like a push-based collection. So we have a value in anybody attended the Bottle keynote yesterday? That was on RX, right? She built a game, I think. I wasn't here. So we have value in our usual programming. We create a variable. And its asynchronous version is the promise. And we have an array in our usual programming, a collection of values. And that is what an observable is in asynchronous world. It is a collection of asynchronous values. So we start the Webpack server. And we start the Webpack server. And first thing we do is import that observable. We are using ES6 modules here. Anybody not familiar with them? It is like doing this, like we create a variable and require RX.observable. This is doing the same thing. Now, what is an observable, actually? So observable is like a promise, but a slightly different API. We, to get a value from observable, we have to subscribe to it. So let us take this example. First, we have an array of numbers. And we convert that array to an observable using observable.from. It will convert most of these imperative forms to an observable. And observables, the good thing about observables is that they provide a functional API. Like for our arrays, we can do map, filter, and reduce. We can do same with observables and even more. There are a lot more operators. So like we want events from our numbers collection, our numbers observable, we do a filter operation on it. And we use this fat arrow syntax. What this does is it basically creates an anonymous function, like we would in usual JavaScript. And if we miss the braces around, it will just return the result of this statement. So we get the events. And then we subscribe to it. When we subscribe to it, we pass it a callback. And this callback will be getting the actual values from the observable, like here. So we get the even numbers from our collection. And we can convert promises to observables. We have this array of URLs. And we convert the array to an observable first. And next, we use flat map. So flat map is like a map. Say we map over an array. And the map gives us an array of arrays. So we flatten it. At end, we get a single array, a flattened array. This is what flat map does for observables. Like now, this Ajax request will give us a promise. But we want the value. So what flat map will do is that it will create the promise. And what it will give the subscribe method is the response that we'll get. So we aren't really logging it. Here it is. It is asynchronous. So although we are, sorry, it is actually, you can say, even driven programming on steroids or observer pattern on steroids. So the advantage of this is that it provides a very functional API. Like we have the filter map reduced on arrays, array extras. So we can do the same way for asynchronous programming. We can have multiple asynchronous stuff things. And we can compose them together. Like we have an array of URLs. We can make a request to each URL and get the response in correct order. And pass them through this map and filter and all that to get what we need. So now this is all asynchronous. This is not blocking anywhere. So we have other code running. And the response gets in the end. The response is logged in the end. So in the same way, there are many operators on observables. Like we have this interval operator. The interval takes time in milliseconds. And give us a number every this many seconds. And we can compose asynchronous calls together. This is asynchronous, right? It is like having a set interval. And we have another same thing, like set interval. And now we want to merge them together. So what this will do is say, we are now having this merged thing. So it gives 0, 1 first, like on every second. Because we have a 1,000 callback, 1,000 interval. And then we have another which emits every two seconds. So we are having the other one is running along with it. And we get it at proper time interval. We'll stop it. And we can convert events to observables. So like we have click events or resize events on window. We can convert them to observables. What benefit it gives is that, say, you have a click event. You add a click event to, say, the body. And then you have an event listener. And then you forget that event listener. What we get is a memory leak. Now, what observables does is make us think the events in terms of data stores. Like our event is actually an array which will give us a value whenever user, that event is profound, whenever user clicks, or whenever the window is resized, or whatever. And we can compose them together as well. For example, we have this combined latest operator. It takes two observables. And it will say two observables of clicks, clicks and resize. Now, these observables will get value when user clicks or resize the window. What combined latest does is that when user clicks and then resize, it takes both values and give them to our callback that we provided and then returns what we provide. Complicated? I was told that I have to build on bottle stock. I was expecting some familiarity with the FRP. Never mind. So we have this set now. Now, when I click it, actually, it will not work this way. So whenever I resize the window or I click, I get the notification that this observable has done something, has got something. What it has got is what I returned here. So we are not really doing anything with that. We are just logging it here. And then there is this zip operator. It takes two observables. And whenever each of them, say, responds, it combines them and give us to this callback and return the whatever we return from this callback. So here we have even plus odd. We had two arrays. We combined their values, 0 plus 1, 3 plus 2, 4 plus 5, and likewise. So I don't think you guys are convinced about observables, their power and all. Observables are actually very cool concept. I wanted to convert you guys from promises to observables. It seems hard. Anyway, we'll proceed. I don't want to delay the magic moments. Then on to our next step, to the virtual DOM. So have we used React? How many are familiar with the React? We are all jQuery people. So React is a really awesome framework. It uses virtual DOM. So DOM manipulations are expensive. That is what is said when we start using jQuery that don't do too many of them, combine them together and do them as few as you can. So this virtual DOM is a library which keeps a representation of DOM in memory, not the actual DOM in memory representation. And whenever we want to change something in the DOM, we create the whole view again. Like we create a new DOM. And then this virtual DOM will perform the, say, dipping. It will see what changes it needs to make. And it will change the actual DOM. Only the most optimal changes it will perform. So let us see how we can use it. First, we use our observables as always. And we have to use this edge from virtual DOM. Edge is for hyperscript. So hyperscript is like one level up the virtual DOM. Virtual DOM will interact with the JavaScript objects directly. Hyper level is one level next. And then this is create element. It converts the hyperscript to what virtual DOM actually understands. And then we have dipping and patching algorithms, the functions which will actually dip and patch the changes so that we can only get the optimal updates. And we can actually use this HTML-like syntax in our code because we are using Webpack. And I have added a virtual DOM loader. So what this will do, this will get converted to hyperscript automatically. We don't have to do it. But we have to convert the hyperscript to virtual nodes later. So we have a render function. It takes a count. And it returns us an H1 tag. So then we create a view. So from our, say, call this our hyperscript, from our hyperscript, we created our DOM. You can call it a view or you can call it a DOM tree. So after this, we have to then convert our view to virtual nodes. So the virtual DOM has one condition that all the virtual nodes must be contained in one parent. That is what we call root node. We create root node. This is the root node. In our case, it is only one. We only have H1. And then we append it to our body. What this will do is just this. It will just take this. We started with zero. The count is zero. And it rendered the hello world. Next, what we want to do is that we want to make it like this. So what actually is happening is that only this H1 is updating. Actually, only the one text node is updating. We have the text nodes in the tags. So what we are doing is that we are doing the same observable dot interval thing. What observable dot interval will give us? One people I told you. It will give us a number every 1,000 milliseconds. It will start with zero, then one, then two, then three. Then we map over it. In the map, we keep getting that number which the above observable is returning. For the every time we get a number, we recreate this H1, the whole view. And when it is recreated, we dip it with the previous view that we have, the new view. This map returned us a new view. And we used it in our subscribe method. So we create the dip. Then we patch the dip. Like this root node that we created earlier, we patch it with the dip that we got. And then we replace a previous view with the new view. That's it. We don't tell it how to update. We just tell it what to do. We just tell it that when you get a number, just generate this view. And it will update it pretty optimally. It will update this on text node only. So we are not clear with the virtual DOM either. Yeah, this is the code. I am not getting you what you mean or what you want to see in the network there. Of course, we have in our index.html this slash app.js. So all our JavaScript is getting compiled to ES5 and minified and put it in this app.js file that we include in our index.html. Yeah, I told you know that what Webpack does, what shall I call it, a library load. So for doing library load, it don't put the code on file system. It will keep it in memory so that library load is very fast. We can compile it to, say, with Webpack minus p production. We can create our production or disk code. And it is taking time. Then we can see it. This is how it looks like. It is compiled, minified, and totally unreadable. OK, so let us start our Webpack dev server again off top of the HTML. So this is what we are doing here. We write this, say, JSX-ish syntax in our JavaScript. So in our Webpack config, we have loaded a virtual DOM loader. So this tag will actually get compiled to virtual DOM later, a thing called hyperscript, this edge thing. We gave it as an input. And then we appended it to our body. Then we just update it, and virtual DOM manages itself that how the already rendered DOM shall be updated. Yeah, that's the new trend. We can separate it. So it is just a function. So we can put it in another file and import it, like we are importing other functions. So you resolve promises. What's the guarantee that the promise that you resolved number three will not get resolved before number one? Then they are all resolving at once. And how will you compose them? So you have one set interval. This is a very simple use case. You don't even need promises for that. So the advantage of observable is this map. Now I want to do something else with it. I don't have to mess all my code. It is very composable. So you can just look at it and see there's one map operation. It is doing x. There is second map operation, or something else. We will put it up, because here it is getting. The advantage of observable is first this, say, writing code in a stream-like way. We have these functional operators. We can do whatever we want with the observable, with our value, until it reaches this subscribe. When it reaches subscribe, it all ends. This is where the observable ends. We can change the operation. Second is the, say, predictability. Now this is a very simple use case. Imagine you have an array of, say, 100 URLs, and you create a promise for each one. Now what you have the guarantee that which one will resolve first? You can use the libraries like Q. But after that, it is not really that composable. The composability, this is the composability part. We can compose small operations to generate, say, to manipulate our values in the way we want. We'll see what it can do later, just in a minute. Now that we don't have this clear either, we'll move forward and to the third step. Now you don't really know React. So React has put this very nice idea of programming in terms of components. So all our UI, we compose our widgets like separate components. They are isolated from each other. They don't need to know about each other. And it makes the reusability very, say, intuitive or natural. So we want to create a similar system, but without using React, actually. We want to have a components-like system. And we don't want to use React. And we have virtual DOM, right? So we want to render stuff. We are on third step. React actually has a slightly different implementation of virtual DOM. React first introduced virtual DOM. And then people say that, oh, it is cool. I will make one too. So this is another implementation of this same concept. So then we want to create a renderer. Like in React app, what we see is that things like this. Like we include the root component, the layout. And we just call a render function. And it will render it and our app begins. Whatever changes we make, they are optimally updated and all. We want to achieve the same thing without using React. How do we go about it? So first of all, we were appending to a body. Remember, we were doing document.body.pand. We'll create a span, give it an ID, and append to that span instead. Is it readable? So we create that base node where we will dump all our virtual DOM, and we do it. And then we want to make components. Let us just divide our code into components. We had these two things, hello world, a greeting, and this counter. So we created this components folder and created these two components first, the counter and the greeting. So basically, these two have nothing special. We just divided our, put h1 in one of our elements in one of our components, and we return the render method. The same thing that we had earlier combined. We split it into two files, and we are basically having the same code in both of them. Now this export default thing. This is in ESX, we have to tell what we want to export. Like in Node.js, we do no module.exports. The same thing. What export default does is that it will, if someone do like this, import directly the variable name from our module, then it will, by default, give this render function to it. So then we'll, now that we have two render functions here, we have two views, the two components. We want to render these two components onto our screen. What we do is that we change our index.js to and we import them, like greeting and counter. Now these are two functions which will give us h1 and a counter. Don't worry about it, man. We are using Webpack and we are using Babel. It will transpile your ES6 code to ES5. Just clone this reference, right now. It isn't working, see me after that, after the workshop. It will work, it is, I am using IOJS, but most of the ES6 features are not really implemented in IOJS either. You can run it on Node 9 even, I think, 0.9. We are using Babel. It will take the ES6 code and make it ES5 code. So we imported two of our components and now our render function will look something like this. We have our count. We convert the count to a string. And then, remember I told you virtual DOM needs one root container. It has to have a parent on the top. So we create the parent and then we just put our components in there. So we have components, right, right to it. And then rest of the code is same. We just, we do the same thing. We map it to render method and then patch it, patch the DOM that we have rendered. And this code, this rendering code, actually don't belong in the index.js file, right? Because index.js is responsible only for updating the view, not creating the view. So we'll create it to a root component, call it main.js. So it will import all the subcomponents that it needs and give us a single render function that we need, that we will use in our index.js. So clean code. And the next thing is that this state, this observable.interval creates a count, right? The count is used in the counter component. It don't have anything to do with anything above that. It don't have anything to do with the greeting component or the main component. So we shall put the state where it belongs. So we can do that. We will just take this observable.interval and put it in the counter.js. But then we don't really have the value. What we will have is an observable, right? So counter.js will then return a function which will return an observable with me. So this is a thing I have chosen to use. So any observable is represented by underscore at the end, because it is a stream. And any function which returns an observable shall do the same, just something I came up with. You don't need to use it. So now our render will give us an observable. So we need to update our main, because earlier it was relying on a function which gives it a virtual DOM. Now it is getting an observable. So we update it. What we do is that we take the counter, the counter observable, and map it with this main view, the big view. So what this counter will give us is only the count view, the text node, the one text node. And what we want to do is put that one text node in our div, the container. That's what we do. So the composability for the win. And we can then change our index.js file to look something like this, because now it is consuming an observable. So if we want to use it elsewhere, it has to return an observable. So that it does, it returns a render observable. And in our main.js, what we do is that we import the main as main view, and then we subscribe to that view, instead of creating an observable interval. So this is what we get at the end. Actually, what it will give us in the end is something like this. So it will not render for one second. It will start rendering after one second. And start the count at one. That is because we have done this n plus one thing. So why is it acting like this? So this interval, what it does is that it will wait for one second and then give us a value. And we are using it directly. So this is what it is happening. It is waiting for the value. And when the value comes, it is rendering. But we want to render immediately. We don't want to wait for the observable to give its result. So we start with a default value. We start with 0. And we get immediate rendering. So we have an idea how our components are going to be. The components which need to update will return an observable. And the components which don't need any operation, they just are there to see the show will return the DOM nodes. But that is not good, right? Consistent systems are maintainable systems, right? Because if some component is returning an observable and some is returning a function, another one is turning a DOM node, not very good. So what we do, we change all our components to return only observables. So the component which only have to give a DOM node uses this observable.return. It will create an observable which will finish after returning this one. So why are we doing this? First is consistency. We want a system to be consistent. And second is composability. So after we have all these greeting and counter both as observables, we use combined-lay test. Because we don't want this greeting to be ran every time, right? Because its job is just to return one H1 tag. We don't want to run it every time. So what we do is use this combined-lay test. What it does is that once this greeting has emitted a value, it will cache it. It will cache it until it emits again, which it will never. So we use this cached value. And this counter updates every one second. What we get in the end is the index.htm.js file like this. So we create a render function which takes the main view and the DOM node to which it has to render everything, the base DOM node that we have. And then I just restructured the code to contain all the operations in one function. So this is basically a closure. We can move this to its own file and call it renderer. What renderer will do, it will provide us this render function, and which will take one view, an observable, and the DOM node to which that observable is to be rendered. That's it. So we moved it to its own file. And we then end up with this simpler index.js. We get our main view observable, which is the whole view we need. And we get the render function from the renderer. And we just render the view to the DOM node. And it is updating itself optimally so. It is only updating this span, which it should. Everything else stays static. It has the same interface. That is what we were aiming for. We want components like React, because they are very nice. Isolate components are the most reusable and most scalable. So we want that interface. And I like the React interface a lot. Just have a render method, give it the main view, give it the DOM node that you want to render. And that is what we get here. And without using React, it is not really JSX, but it is like JSX. Oh, no, we can. I just chose this because ES6 just makes the code so much more readable. Now this same code would be written something like this. So we can reduce it to basically one line. So now that we are not clear with this either, we'll move forward. So the events. Now we have a virtual DOM. The DOM is in memory. Before when a script is loaded, nothing is rendered. So how do we listen for events on something which is not even there? Like I want to listen for clicks on a button. I want to listen for clicks on this button. But before, it is actually rendered. Because when a app starts, when a script loads, there is nothing in here. So what we can do, one thing is that we wait for it to rendering. So maybe our only option. Or the other thing is what React does. What React does is that it will have, say, on click equals the function name, the event listeners in that way. So remember, we used to have this in the pre-Jquery days, or maybe in jquery days. We just have a DOM node. So we have this button node. And we want to listen for an event. So we will do it on click equals listener. But that is an approach React has chosen. And I don't really like it for, say, tests. But we are using observables. And observables are good at composability. We can change the operations and get what we want at the end. The difference between promises and observables. So what if we put an event on the whole body? We put a click event on the body. And then we keep filtering it until we filter the target to see if it is this click button. Performance optimization. So you have 100 buttons. If you put 100 listeners on 100 buttons, you have 100 listeners. And now with this, you have one listener. And you are just filtering it. Then you have one click event. The whole body is one line away. It is actually, this approach is called delegated events. It has its pros and it has its cons. jquery use it for your information. If you look at the jquery dot on the function, it actually in a way uses delegated events. So in this console, what I have done is that whenever we click on body, so it logs the event. I clicked on whatever, it logs an event. So what we do is that we check for the target of that event. Where is the target? And now target has class names, this class name. Or it also have a property called class list. So what we do is when we click on it, we create a function that will give us clicks by class. So it takes a class name. When a click happens, we get the event. And then we convert it's a class list to target.classlist. This one, it is native JavaScript. It will most likely not work on the older browser. But we are not spotting the older browser. We should not spot the older browser. So when I click on it on anything, it creates an EV on window. So this is our mouse event. So EV has this property on its target called class list. So I clicked on here, it don't have any classes. When I click on the button, it has a class list. This is not really an array, because when we do operations on DOM, it has its own hierarchy of array. It is not really an array. So we convert it to an array with the simple utility function that we have created, a two array. Of course we can. And what will we do with that? So now we have two buttons. And clicking on this button does nothing. Clicking on this button updates the counter. Why? Because we have different classes on them. So different ways to get the events. One is this. We put in a single event on the body. And then when an event arrives, we check its target. And we filter the target if it is what we need. We can have similar way, clicks by ID or whatever we want, clicks by the DOM node even. And what we do is that we return a new observable. That observable is the clicks on the element that we have. So in case of count click, what we have is we create a new observable, count button clicks. And then we work on the observable. Now we are getting the event, but we don't want the event. What we want is that we want to update this DOM node. We want the view to update it. So for the view to be updated, we need this count. So what we do is we create, start with the count equals 0. And when the click happens on this button, we increment that count. At any point in the chain, we can use this do operator to check what we are doing. The do operator is like, say, you tapped inside it. It will not do anything. It will just do some side effect. I'll start with the observable. I had to get the same value. That was turned by the observable before do. When we click it, we say we are incrementing our count. And we start with 0 so that we don't have to wait for the count, because if we wait for the count, nothing will be rendered, because now it is waiting that someone will click that button, but there is no button. So we start with the 0. It gets up there. And we convert our number that we are getting to a string. And then we return this whole view, this complete view. So then the magic of that renderer comes in. We don't need to go through all the hoops again, because it is all reactive. We just update one observable in the whole chain. And the chain will rerun. So if we look at it, nothing else in the DOM will change when we click. Only this count is changing. That is all thanks to virtual DOM. This is how we are going to have our eventing system. So for two buttons, say second button. For second button, we have a different class. Now we want to listen for the clicks on this class. So we do the same thing. Let second button clicks equals the function that we created, which will return us an observable of clicks, clicks by class, and then the class name. But by itself, it will not do anything. To get a value out of it, we need to subscribe to it. So this button does nothing, just log them event. So yeah, we created another observable for that. That is what we want, right? We want to handle the two buttons separately. We don't want to mess them together. So that is about it for our event system. Event system is very simple, nothing complicated, no need to add event listeners, then remove event listeners. We just have one mother of event listeners. And that's about it. So this approach actually has some side effects, some bad thing. For example, let's say homework. So our next step is to fix the feeds and some styling. We want to end up with a view like this. The internet is slow. I didn't talk about the error handling system. Now we have this whole chain, right? Each view returns an observable. Then when we combine those observables, and it becomes a big whole chain. So what happens if an error occurs anywhere on the chain? We want to handle the error. So we have two ways to handle the error. We can handle the error right where it occurs, or we can have a handler at the end of the chain, where we subscribe to it. So where we subscribe to it, we have this error handler. This is the next handler, which will get the next value, and this is the error handler, which will get the error. So what it does is just log the error. So we have an error here. What it says is that this utils.format date is not a function, because it is expecting a function somewhere in our utils module. And it says it is not there because it is there. Let us see where it is in the post view. That is not waste time on it. OK, now CSS is messed up because of this resolution. Oh, no, it is a zoom. So now we want a view like this. We have a sidebar, and we have a list of our RSS feeds, the post. For getting the post, we have to first fetch them. We have to make network requests. So for that, we create a file called feeds.js, and we will export an observable saying feeds from it. And we will use the feeds in a component called post list. This list, say import these feeds, and then operate on it. It takes the posts, which comes with each feed, because each RSS feed will have 10 to 15 posts, an area of posts. Then it creates views for each post, and then it combines all the posts because if we have three RSS feeds, there will be three arrays of posts. So it has to merge them together. For that, we have reduced. Have we used reduced before? Reduced before? It's an array extra. So we have an array. We want to find a sum of array. Basically, we want to reduce the collection to a single value. That is what reduced does. It takes an accumulator and a new array that we have, and it just combine them, concatenate them, and give us the result. And we pass it to our view. The view we don't need to worry about right now. It's just markup. And then we have this view. But how do we request for those feeds? Say we start with this one. This is taking an array. It is taking that huge DOM that view we create. Say we have this post. This is an array now. This is an array of posts that we will get from the feed. Now we convert the array to an array of views. We map over the array that we got, and we converted them to views with the post view function. Now we have the big array of views. So that is what we pass to our view function. This view function, the post view array. It will render it accordingly. No, no, no. Reduce will do this. Reduce, first we have this post. Post is an array. This post, the first thing, is an array of posts. That we start with. Now the second time this array comes, it goes to reduce. And reduce expects two parameters. First is the accumulator. Second is the value. Now the accumulator, when we don't pass it, it will assume this post as the accumulator. So this is our post is our accumulator, and we get new posts. And then what we do is, accumulator.concat, new posts. Then the third time it is the reduce run, it will have its first element as the combined array. And it will take new posts and combine them as well. We clear with this? This one? It is like we got an array. Then we get another array, two arrays, because we have three feeds there. Now we got two arrays, and we combine them and make one array. Then we get third array. We combine them with the previous big array and return the big array at the end. So for fetching the feeds, we start with an array of URL. So here's an array of the RSS feeds that we want to fetch when we have nothing in the front start. And we create a helper function to fetch the feed. We import Ajax from jQuery. So it is just like doing where Ajax equals the required jQuery.ajax. So what we do is that we change the URL that we have, the RSS feed URL, to this thing, the Ajax.googleAPS.com. This is because if we try to request this feed directly from our JavaScript code, guess what will happen? It's a cross-site request. It will not go through. So few RSS feeds set the proper cross-region header, good for them, the nice people. But few ones like this unison don't. So the request will not go through. For that, we have to use something on the server. So that something on the server will fetch the feed for us and give us the result with proper cross-region header set. That is what this Google API does. It takes the URL of the RSS feed, parses the URL for us, and provides us a JSON feed. And we make the request, and we return a promise from it. So this fetch feed function will take a URL, make the request, and give us a promise. We want to use this promise for making the three requests that we want to do. So what we do is that we first convert this feed URL's array to an observable, because that is how we compose. Observables are composable with observable or promises or generators, only these three things. So we convert the array to observable, and then we flat-map it. Remember the flat-map? So what we do, this fetch feed will take the URL one by one, and it will create a promise and give us the promise. At this point, we have a promise. Now promise will resolve at some time. The promise dot then is called. So what this flat-map do is that it will take the promise and keep this thread on hold till the promise resolves. And the next step will actually get the response whenever it arrives. So when I say it holds it, it doesn't mean it blocks it. It just holds the one request. Say it made the first request, it is waiting for it. It then makes the second request, waits for it, then makes the third request. And as the results come back to us, we'll keep getting them in this map ahead. We get the response, and the response will look something like this. The response objects will look like this. It has a property called response data, which has a property called feed, which actually has the real feed, the feed URL, the link, the title, and the entries. These are the blog posts that we are interested in, that we want to show here. So we do that. We take the response and provide the end result, the post that we want. So then we create a post list view. What this post list view does is, like I showed you, it expects arrays of posts, like we subscribe to feeds, and we get an array of posts here, and we do the processing and render the view. And all we have to do is then at the end is return this render function. And we change the main.js. First import this post list view. It is an observable. And then we have this view setup, just the container stuff, which has this post view that we want. It just take the view and put it somewhere. The returning the view is the responsibility of our post list. So we use the combined latest. Remember what it does is that it will wait for these two observables to return at least one value. When they return at least one value, and after that, it will pass those two values to this view function of ours. This view function now takes two views and put them there. That's it. So that's what we do. Whenever these two return something, we put it in our view, render the whole view, create the whole tree again, and return it, which is then used in index.js without need to change anything, because we have the new view. So we get it. Now about the sidebar. The sidebar is static, right? It is waiting for the views. See, it is waiting for the requests we have made. It won't even render the sidebar till the requests are done. So what do we do about it? Sidebar does simply, it has a static view, just that brand, and we use observable.return. What do observable.return do? It just takes an argument and creates an observable which will just return that view and quit, complete itself. So it is waiting for the request. And how do we, say, avoid that wait? We don't need to wait for all of them for sidebar. We do a start with. Start with view. Tell it to start with the view, and return the view again. It is still waiting for the request, so I have to see. Oh, sorry, we don't have to start with hit this one. We have to start with this one. We start with an empty view. If we start with an empty view, nothing is rendered here. And the sidebar gets rendered. And whenever the requests are all fulfilled, it will render the main view as well. Not clear with this one either. So what we have at the moment, the styles I actually copied from theme, it's called a ghost theme, medium-like theme. I just copied the styles, why do I have to work? So what we have right now is we have a component system. We have our components quite isolated, right? So our component don't need to worry about other components. We have the isolated components. And we have a nice API to propagate the change that whenever components need to change, it will just update the view. We don't have to manually say that, update this li or do this, do that. That's where reactive parts comes in. And then we make these asynchronous calls quite composably using observable. And then we have this event system. The event system is quite simple. All thanks to the observables, we can just deal with the whole eventing model using just one event listener. So actually, let me give it away. This eventing system will actually not really work if we put events directly. Now if we do something like we put a click on this YAR, then our body will not see the click because YAR captured it. The event will not propagate down. So our event listener will not work at that point. So this is one thing we have to take care. If we are using this model, we have to just use this model. Doing something else will break it for wherever we use something else. Second thing is, figure it out. So shall we move to the next step? So our sidebar was empty. We want to fill it with something. And we got an error again. No, notice this error didn't break our app. It should usually because we are actually handling it. And what it says in the format data again, it will just pull it out. Sure. Menu of the main of the heritage. Say this view gets the arguments from here. We are calling the function here in the render. Now this combined latest operator, what it does is that it takes a number of observables and a callback in the end. So these observables, whenever they resolve, this view will get the value. What we are returning is this render function, not the view function. Sidebar is empty. So we want to add these widgets to our sidebar. So first is the filtering widget, that filter feeds by all or unread or read. Then a widget to fetch all the feeds again and to add a new feed, it will show this input field. And the list of feeds that we have subscribed to, to filter by them, not working yet, will work in next step. So how do we do that? So we have to add them all in our sidebar.js. So we create these three widgets as three separate components. There is this filter widget, then fetch and add widget. And then feed list widget. So first of the filter widget. So we'll just do the one widget. We don't have much time either. So the first step to do the widget is, this is readable. So this is how we create the widget. We just have a view which returns an untitled list of the three buttons that we have. And it just returns an observable, which will return our single view. Now we want to listen to clicks on it and change the class. When we use the clicks on the all, we move the active class to all, otherwise to read or to unread, read, then unread. So for that, we import the clicks by class from our events, the eventing model that we have set. And then we create an observable and call it widget clicks. So whenever something clicks on this class, filter posts, any element with this class, this observable will respond. It will give us the event. We are interested in the target so that when we click on the unread button, we put the class on it. So we map it so that we get the right target. When we have the element on the next step, we do a side effect. Remember, this does not return anything. It does a side effect. Because we don't need to return anything here. We are just doing a side effect. Put a class here, put a class there. So what we do, we just select all the filter posts which have active class and remove the active class from them. Say map is like, you get a value. Map and flat map are same. Flat map is actually a combination of two operators. It is map and flatten. It will map it, say we have an observable of URLs. We map it, and we get the URL. Then we make a request. And we make that request in flat map because the request is not giving us a value. The request is giving us a promise. But we are interested in the value in next step. So the flat map will wait till that promise is resolved. And in the next step, we get the value. If we use map there directly, on the next step, we'll get the promise, not a lock. We made a request. We put that request in event loop. It is waiting till it is not finished. The next request gets to come again. And then it is waiting. Whenever they are resolved, the chain will continue. That is what we want, right? And if the request fails, an error will be raised. And we'll receive the error in subscribe. Flat map will make it go further the chain. That's what it does. So we converted the clicks event to this widget clicks. And then we remove, we change the class, basically. That's it. And we log it. Remember, we have to subscribe to it. If we don't subscribe to observable, it is lazy. It will not work until we subscribe to it. Because up to this, this is dead code. This becomes live when we subscribe to it. And we don't want to return this observable. So we just subscribe to it right there. And it will keep doing its job. Now, this is not really the right way of doing things. Because this do should only be used for debugging. We are doing it for side effects. Side effects are bad. What we should ideally be doing is that we, say, use this widget clicks in our view. And widget clicks should return the class name. Now, let us not confuse you further and forget it. So the last thing we are going to do. OK, let us keep it up to here. And further in the tutorial, if you guys are interested, you can go to this GitHub. And the whole tutorial is written in these steps. You can follow. At the end, we will have something like this. So I told you that we will use the local storage, not the local storage, the offline storage. So what offline storage does is that it will completely change the way we are dealing with data. Now we just get the request. We pass it to the feeds. But then we have to update the database, the index dv. And we have to update the views. We have two operations. We have to, say, take the request and do both. And if the request isn't passing, we have to take the data from local storage, offline storage. That is actually more complicated than it sounds when we actually get to implement it. So one way we can do it is the offline first. When we make the request, we fetch all the data and put it in a local storage. And we show the data from the local storage to our views. To our views render immediately from the offline data. And when the data comes, the offline data updates. Now we get another responsibility. That when the offline data updates, we have to update our views again. But we are doing reactive programming. It should be reactive. So in next steps, what we do is that we make the index dv reactive so that whenever something changes in the index dv, so this is a post dv. Whenever something changes in the dv, say, I clear the dv, the UI should change. We don't have to deal with UI after that at all. We just get the data and update the dv. That's it. And if we want to do something with feeds, we just do feeds.clear and our feeds are gone. So we are actually saving this data, the feed, in index dv. So for accessing index dv, because it has not so pretty API, we are using dexy.js. Dexy.js provides us hooks to listen to the events that when something is added to the database, when something is removed to the database. And we convert the dexy.js to observables because observables are reactive. And then we use those observables in our views. So what we basically get is that we want to remove this post, get its link, and we can do something like this. We just delete it from our database and the view updates accordingly. So if you guys are interested, you can check it on this GitHub. It's a tutorial. And you can actually use it's app. I do use it. So in the end, we also have to implement this one so that when we click a URL, we see the whole view. We use HTML to hyperscript parser for parsing the HTML to the virtual DOM. And then we have this button which deletes that view. And we come back here. So this is about it that we are going to do today. We're out of time, almost. So any questions? Say we don't subscribe to anything that we subscribe to only those things which we need for side effects, like these clicks. We don't want to return it. But feeds we want to use in this view. So what we do, we create the view using the feeds. All right? The feeds is in observable. View is in observable. Now view is composed of feeds. It consumes feeds. Then this view goes to the main view, the root of all. Evil. So that main view is then imported in our index.js and given to our renderer. Now our renderer subscribes to it. It gets subscribed in the end. Because once we have subscribed to an observable, the chain ends there. We don't want to end it. We want to use the chain further. So if any error comes anywhere along the chain, it will be handled here. We can handle the error accordingly. We can show, say, a warning that this thing has happened or anything without putting the warning messages all around the app. We can put them in the end. No, not always. It will happen only once. And we have this button, patch all feeds. The user clicks on it, and the feeds are patched. And this is the RSS reader. So it should be updating itself. So we can put an interval which will patch the feed. Any more questions? Of course, it handles it really well. So we can boost up. Say there is an operator called takeUntil. It will take the value until you don't know it. So the problem is that our view might not be present at the point. So we want to reject it. So there are operators. There is one takeUntil. We put the check in that. So if the check is true, then the promise, the further in the chain, we will get the value. Otherwise, the value just gets rejected. This is one problem with promises, actually. How do we reject a promise? We can't really do it that well. We can do it with observables pretty clean. So you can actually think of an observable as a promise which resolves more than once. It can keep resolving forever, or it can complete. Yeah? We all are. Sorry, I can't hear you. I am not getting you. Yeah? Yeah. OK, we are compiling only the ES6 syntax. Rx.js itself is compatible till Internet Explorer 6. So we don't need to compile the Rx. We are compiling the ES6 syntax. Normal. Yeah, it will be reflected then. We can compile it to that and don't need to then. Yeah, we have a watch so that we can compile this ES6 syntax, this arrow, and all that, to ES5. Any more questions here? The beauty of observables is that we can convert everything to an observable, an array, a value. So even the handler from index dv. We get the data from index dv, and we convert it to an observable. Then we use that observable to create our view. Like we do that like here. This post now here. The post now is coming from index dv. So index dv, when we get it, returns as a promise. This post is that one thing. And we map it to our views. This is how we link them together. Everything is an observable. We just say, do the plumbing. Get observable from here, another from there, plumb them, convert the data to the view, put it in the virtual domain. Done with it. Any more? Yeah? Will we monitor, say, we have an array, right? Array, by definition, is the snapshot at one time. When it updates again, we have to create a new array. We don't update an array. No, it won't work that way. Say, we have converted that into an observable. So it can watch for it. If it tells the observable that I have changed. Array can tell anyone that I have changed. Event can. Event is basically, that is what it do. When we have an event, it says that, hey, I have a new value. So our observables are reactive in that case. Yeah? I don't really know that. I don't know. It's in JavaScript. I will check it. Any more questions? OK, then. Thank you, Vipur.