 So today I want to talk about the single-page application front-end development with reframing agent. So single-page application. So now everyone is talking about it. Actually, it's a web application or website in fits on a single page. Previously, we do the web development. We have a bunch of UILs where we move back and forth. We will post a request or we will do something. Then the back-end server will render the page for us then to send to the client. But now everything changed. We have this SPA and also people want to compete with native desktop and the mobile application. Wow. So what does it mean for us as developed or headache? So we can see that we have a client and a server code totally separated. So when we do design the things, when we testing, when we send to the dev operation, a lot of problems. We can see front-end and the back-end when we want to deliver to production, but people find, oh, we are using the different contracts. Boom. So we also, the data transport and the binding become a big problem for us. Previously, no such problem because everything located in back-end. So it's a load from database. It's rendered in the server itself. Then sends only HTML to the front-end to do the rendering. But now, no, even the client will handle some logic business logic. So we get a lot of new technologies. Now we have HTML5. It's a lot of new terms. We have Ajax WebSocket, some server push events. We will have fire uploads, orgs, such kinds of APIs. So we also have a lot of new frameworks. We have AngularJS. We have React. We have so many things. Need to learn to handle. You can look at the wiki pages. It's talk about all the challenges, all the things as a developer need to take care of. So here comes our savers. First, functional programming. It really makes the things simple, make the things composable, because we don't have the state. No, not have the state. We can limit our states in a very small area. We have, with closure, we have the data-oriented design and the data-driven. Actually, in the last three months, we are doing all such design and implementation. We find we have failed more and more love with the data-oriented design. Everything flows from the data model then to the pipeline till the end to render in the client. Closure and the closure script. Previously, in the last pitch, we say we have the code separation problem. Client and the server, now it's separated. So in our current workflow, we use different programming language. In the front-end, we use JavaScript. In the back-ends, we use Java or others, Scala, Ruby, such kind of things. But closure and the closure scripts make us use closure. I think they are almost the same. I don't say totally, but we use almost same languages in the front-end and the back-end. And also, even with our current work, we are trying to investigate when we're doing the development, we even run the logic in the front-end, means which are compiled to closure scripts. When we send to a dev operation, we separate to the code. We deliver the business logic to the server. So we don't need to worry about it, because everything, they run on the same thing. Nope. Sorry. OK, then reframe. Reframe is a very good-designed framework. Although, actually, we dropped it two or three weeks ago. We find it has some problem. I will talk about it later. But I think a lot of concepts can be referred in the project. What is reframe? Reframe is a framework for writing SPA. Actually, it includes the basic idea is it thinks in the front-end we have a single app DB. So we store all our models, even the rendering information, everything into front-end DB. Then this DB can use, how do you say, use atom to be directly mapped to the view. Then the view rendered by reagent in the React. We can do some dispatch from the DOM level. Then it will be handled. Actually, in the end, it's like event queue. So front-end can dispatch all the events. Then in the end, the event handlers will take all your events, then reduce all these events into the DB. It's a very common pattern with the closure and the closure script. It's a reduced pattern. It means also you can see it's event source. So you have initial model, then you collect all the such kind of events, then you reduce into a new model. Then it will reflect to the view again. OK, any questions? OK, so this is the main components. So to follow the idea, if you are developer with reframe, you can see first you need to have a DB code, its model. Inside it, you also can have some specifications to verify this model. Then you have subs. Subs is a query layer. Actually, you can define some queries against your DB. You define event handlers. So you can see it has event ID. It will return you the DB and the event payload. Then you can do some operations on your DB. You can associate. You can reduce anything you want to do. Then you have views. You can see in the view it's a subscribe your query. Then it's use hiccups to give more HTML. Then it will be rendered by reagents and react to the DOM. So if you develop with reframe, this is like the workflow. So I think I will talk about it in the dojo also. So we can try some things. Any question? Are the events global always? The events are they global? Yes. Actually, for reframe, it's a state machine. So it has a global DB, means global model. It has this global state machine. Then it has a queue. It feeds everything into this queue then to be consumed by this machine. Any more question? So we can repeat these patterns. So for large projects, you may have many panels. So you can repeat it. So you separate your codes into your panel one, panel two. Then in your panel, you repeat these patterns to finish your project. Even you can see in the demo code, it has a panel. Actually, it's a routing panel. It gets the active panel from the APB DB. Then it decides which panel to be rendered to show in the front-end. This is a bit complex idea. Previously, I think in the last year, I present in the meet-up for use. Actually, at that time, reframe don't have these concepts. Previously, if you need to handle something like HTTP request, or even you request some time. For example, you want to know current time. You need to do new date. But it's changed a lot with effects and the co-effects. I think the example the author gives is, for example, if you want to know the current time, you will embed a side effect in your handler. It will make you difficult to test because your handler is not a pure function again. So he brings in these two concepts. It's called effects and the co-effects. It's mostly used to move out the side effects from the function handlers. For example, you can register the date as a co-effect. So when you use the event handler, the reframe will inject this co-effect to you. So you can reference this co-effect in your handler. If you are doing the testing, you can replace these co-effects with some exact or with the data instead of to call some new dates or such kind of things in your code. And also for these effects. Effects previously, it only has DB as an effect. But now it also uses HTTP. It has HTTP dispatch, all these things to register. So you can use. So from what I think is, reframe also moves more and more into data oriented. If you look at its source code, actually now for every snapshot, reframe can be exported as a map. So you can find everything. If you dive into it, there is a called refrisk. It's a tool to help you to debug all these events, all the effects happened. So you can see it's used this feature. It captures every snapshot. It finds all the events happen, record it, and all the models snapshot also to show you what happens exactly for every step, for every dispatch. Interceptors, OK? I think it's done. Interceptors is something like middleware. I think I forget to compile in this machine. It's like a debug or path or trim. It's the ideas of middleware. So you can handle the data before it's put into the feed to the handlers. Also it can have some post effects like debug. So after the handlers happens, it will call the debug to export the results to you. So you can see, for example, database, what is previous and what is next. Any questions? I think that that's almost the reframe. So if you develop with reframe, you use such kind of things like you define a model, you define all the event handlers, you define your query layer to query the things you need in your front-end. Then you design all your front-end components. Then it will be sure. For these interceptors can help you to massage your data, to meet your requirements. Like you want debug, you want to, because for all the feeds, like it has some event ID, you don't want to use it. You can trim it. Also it has some paths. For example, you have some handlers only focus on part of the DB. Because you know the maps have all the branches and sometimes it's very deep. So you can use some such interceptors to give you only that part. Interceptors are like cleaning your data. No, it's like a middleware. I'm not sure whether, for example, you use ring, you have a middleware. That means you have some incoming data. So you can massage this data. So you can have the pre or post processing lines. What do you usually use them for? Interceptors. Interceptors, I just said is, for example, debug. For example, if you want to know the DB changes, you know when these events happen, which part of my database has been impacted. So you put a debug interceptor in your registered event. It will output your database the previous and after. Usually during development, but not so much in production. Debug, no. But for example, the path, that's an interceptor called path. Path means when you do the handlers, you want to only focus some part of the database. Because now everything, every data in your front-end, you may have model. You also can have view data. You have user preference. Your handlers may only interest it in parts of such kind of data. So you use paths to slice it, to get those parts. Does that improve rendering performance? I don't think so. But when you're doing the code, you don't need to get a long path to get such kind of data. It will give you directly. Also, it will update back. What do you store in the DB? What do you store in the DB? Everything. Everything you need. Do you keep the version of them? It depends. It depends on what you need. Actually, you have atom. So sometimes you don't need to use the DB to save your model. It's all design taste. It depends on the purpose. Yeah. What to store. Because you have atom. You even can add watch. You can know everything when it's changed. You can even somebody develop something like it can be rollback, because it's all data. So it will give you such kind of flexibilities. You have this data. You have that data. You know when the data has been changed. So you can record these versions. So when you need it, you roll back. So you got the verb of what they done is all right. Because the DB is in front of you. Yeah. Which you can do for everything. Yeah, it's a design decision. It depends on how complex your application need to be. For normal case, we don't have. Or we only care about some kind of things. Like we want to do something like undo, or such kind of things. We will use these features. Otherwise, I think 80% case, we don't use this. OK. So pros, what we find good for with RIM? Actually, it's a separate of concepts. It's give you, it's totally separate to the view and the logic. So you can do anything to your model. Then it's automatically mapped to your view. So you don't. So in your view, what you need to do is dispatch, dispatch. So it's totally separated. So there's no such things. So it's make sure it's come come possible. Because RIFRIM, it's refer the Elm. It's architecture. It's try to make your code can be composed. You have different things. Then you can easily compose them into a new things. Like since it's separate of concern, it's easy to test. As I say, it brings a lot of new concepts. So you make sure your handlers are pure. So pure function, easy to test. So even the single sentence, I think, mean everything the benefits of this framework. Now comes negative. First, global state. Actually, this one is very smelly. When we first try to use it to investigate, to do some pilot projects, we feel not good. Because it's a global state. Even now, I think people folk the RIFRIM to give it separate, to make it some state local. So you do the local things. Because from my experience, the global things, like you need to worry a lot of things, like your key conflicts, even your developers make mistakes. And also, you have very large map you need to care about. Heavily bounded with reagents. We don't think it's a good thing to be bound. For example, even reagents is a very good design, and a very good front-end library. But we also have RAM. We have other things. We have OM. So we don't think it should be necessarily bound to reagents. Even, I think, just this week, someone published a very good step. I think it's a new framework based on RIFRIM. It's use RAM. It's give you the local state. I think more and more people use it. More and more people have the same feelings. It's a framework. As closure developer, we don't like framework. It's bound, how do you say? Limit your mind. So you do all the boring things. So you follow the workflow to follow all these steps. Later, when you want to change or you want to try some new things, actually, it's very difficult for you. Even our one-month pilot project, we find you everywhere. We have dispatch everywhere. The event handlers keep long and long. Then even some small things, we use some very complex handlers, like a sync handler to handle. Actually, for example, if we do some causing things, you can do it very concise. So we moved our way, actually. Any questions? Local state. Ken, actually, we have some discussion on the Slack channel. There are two group of people. One group of people say to avoid this, they use some conventions programming. So they have some naming convention. So it seems separate, something local. So because if you need to operate on it, you follow very complex naming convention. The second group is they wrap the model. Actually, it gives you some factory method function. So you feel everything. It gives you all the local handlers, local subscription. I think that's the most two basic ideas. So later, you can combine these local states into bigger tree. For question? Well, OK, Ken. There's three agents from React. I will give you next. So reagents. So when we talk about the refrain, we must talk about reagents. They are brothers. Regents is a simple closure script interface to React. It's very good design if you're finding how to say, when you do simple things, it's brilliant. It's very easy to use. So you can see, if the firm one, if you want to define a component, you say I want to greet. So you see the code. It's just a function. Is it? So if you know the hiccup, it's much easier to understand this. So everything will be a vector. You have the tag names as a keyword. You have the attributes list. Then you have the child. OK, a bit complex one. This one is a function return function. So this one you can think is component factory. For example, in this, you want the time, but other people don't use it. They just render it directly. So it gives you the real render function here. So it shows you how much time has been passed. So actually it's a local state. Then it's export this real render function to you. OK, this one. Yeah, this one is React. You see? It's create class. Actually it's called React. It converts all these structures into React class. It has the demand. It has the demand. It has real amount. It has render function. But it's called reagent render instead of render. Actually, when you use third party libraries, a lot of places you need this form. So have you written code like this for production? Have you written code that you've used in production like this? We do pilot project. Do you ever find yourself just looking at the react that it would end up being? Do you ever find yourself wanting to see what this would actually be translated into? Yeah. Yeah. And you look at that one debugging sometimes or never? No, no need. So far, we did not encounter the problem. It's very easy to use. Any questions? That's all about reagent, actually. Almost done. So no questions? What was the reason you moved away from it? What are you using now? Actually, we designed our own libraries. What was your motivation to design your own? We moved more and more to the data-oriented design. So we tried to use functions to operate on the data. Then everything will be a data, even tier the IO, actually. If you know Haskell, even now our front-end is a map. Then it will be fed to a render engine. It's render the whole thing. Actually, you even can think reagent, something like that. But it's not that few, because react. OK. This is a reference. Reframing is very well documented. Even if you don't use it, you can read this document. It's very nice to read. The idea is very good, although it's a bit of an idea. Regent's tutorial is very interesting. If you want to get into this, do we start reading up reagent first or reframe first? You can see the reagent is very easy. It's just a function to vectors. So you can ignore it first. Tier you need like from three or from two. No more questions. Then I will start the dojo.