 So, welcome to this talk about integrating React.js with PHP projects. My name is Nacho Martin. I work at laymini, which is an agency I co-founded, and in the last time, every project needs a fridge frontend for one reason or another. When you talk to the customer, maybe it's a single-page application, but it will be the best choice for them, or maybe it's a more traditional approach, but it will be best. For instance, an admin panel, but they always have some requirement, it always happens. For instance, they need some kind of sub-application in there, complex application, which needs a lot of JavaScript in there, for instance, a calendar for bookings that you cannot do it in static HTML anymore or with jQuery. So we have been thinking about this, how to solve this for some time. And we really like React.js and React native, the mobile version. We have been using it for some time now. So this talk will be very practical, but I would like to address this question, this thing that I see from some friends of mine more and more. As the frontend has become more and more complex, and there are always new libraries, there is always this new library, this is the greatest thing ever invented, and then, yes, next month appears a new library, this is the best thing ever invented, and use abandoned, the last one. So some friends of mine just say, know what? I consider myself a web developer in the past, but nowadays I consider myself a backend developer. I write PHP and I am now specialized. So I just focus in providing a great API, like I do the most beautiful APIs you have ever seen. And I think this has a good side, which is that you are specialized, so you can help your team to build better products. I mean, it's a way you are focusing something, so you become great. But it sometimes comes with this other sentence, say, this and. And you know what? Now that we are thinking some beers, I tell you I don't care any more about this frontend thing. I think it's crazy, and I don't care any more about JavaScript or whatever they are, it's consuming my API. And this is not so positive. It has some, and I think it has some, it has a bad side. For instance, in companies, I see sometimes that now that there is an API, for instance, they try sometimes to divide backend and frontend teams and put them in the same room, for instance. I have seen teams where frontend teams are now under marketing umbrella, and they can only talk by issues in a book tracker. And I haven't even seen a company where they cannot even talk by any way. So they resort to open the door and shouting corridors, like the API is not working. What do you mean? Which field? And I've seen that. I don't think that's like, it's not very helpful to build great projects, right? And also there is a bad side, I think, in the personal level. Because I think it can make you a bit darker. I know this feeling because I had this exact feeling in a different context this summer, not in the frontend context, but very similar, at least for me, which was this context. I was watching the TV on summer and there were some kids doing these summer solstings, these scrolling things. And I just remember, ah, I used to do this when I was a kid. It was something I could just do. I could do here, for instance. Then, but how long have I been without doing this thing? Well, I said, OK, I have nothing to do. I was in summer. And I said, I can just try. And then I put my safe in position and it became very clear that I couldn't do it anymore. It was absolutely impossible for me. I said, OK, I'm not doing this. But then came this thought, this bad thought. I thought, what if I met the 10-year-old version of myself? What would he think of me as a kid? What would he say? OK, let's see in the future what I am as an adult. Oh, I'm this guy cannot even do a summer solst. And I think it can be applied also to web development. I say, if I think of the version of myself who was so excited about web development and so excited about the internet and the exact moment when I put in my resume, I'm now a web developer. I can do this. Then if I freeze this moment, if I talk to this guy, maybe he asks me now, what are you doing now? Which kind now? Your experience. Which kind of cool things are you building? What do you mean you are not doing this? What do you mean you only do? You can only do one part. Which part is that? What do you mean level-free API, restful? Because if he's not level-free, he's not restful at all. Well, maybe it works for you. Which is best, but it's not what I had in mind. This is not the greatest feeling to have. But I think the good news is that if you are just a bit open to the front end, it's very easy to fix this. And I think that React is a brilliant library to do these two. Because React is not a framework in the sense that it's not a set of tiny tools that you have to memorize, and you have to memorize a lot of calls. I don't like this kind of knowledge, but you have to memorize a lot of things, how they combine together. It's more about a few core concepts that are elegant, and they are very powerful. And learning React means that you become natural with these concepts, which are, by the way, concepts that, at least, made me a better programmer. They are about functional programming. They are about declarative programming. They are about managing the state. So let's see which is the fundamental concept of React. The fundamental concept, let's think how to build this to-do list for this. It's a to-do list, typical application. And you have this functionality to add items, or maybe change the order of items. So if you do the first version, it's not an omelet, because you need to do this. Otherwise, it's fried eggs, so you discover this. Then how to build this. There are two options. One is to think just about the state and think, OK, say, whenever I have a new version of the state, I just re-render everything. I clean the component and re-render everything. This is simple, and it's the kind of work I like to do. It's about logic. It's about you can unit-test it. It's very nice to do. But it's not efficient. If you have 1,000 items or 1 million items and you just want to re-order two of them, and you repaint all of them every time, that's not a good user experience. So we don't use this approach. Instead, we do this other more annoying approach, which is finding the document model, which things to change, which things to move. It's typical jQuery work, for instance, with selectors. This is complex. It's not the kind of problem I like to work. But you have to do it, because it's efficient. Your users count more than that you are enjoying what you're doing. But what if you had something like React says, OK, you focus on the first one. You do the first one. You focus on the state, which is the part of the job that you know your business. And I do the second one. In fact, Facebook's engineer will do the second one in a very efficient way. And in other words, give me a state, like care on the state, on a render method. And I will call it and do it efficiently. So you can pretend that you are just working with the state. If you want more control, of course, there are some hooks to have control over this. Then with this in mind, let's write our first component. We have this very simple component, which is just a counter. We click the counter, and it increases the value. So it produces a new version of the state, which is class one. This is a component that is simple enough to fit one slide. So this is the full code of this component. There are some things to notice here. We will see this component in detail. First, I'm using in my slides this new JavaScript syntax. You will see import, class, things like that. This is the new version. This is much nicer. And I think it's more closer, for instance, to object programming, like class. I think it's nicer, just nicer. So I use it. It's even easier to understand. But we will see later how to translate this to JavaScript. So normal JavaScript that this is also JavaScript, but JavaScript that row serves understand it, particularly Internet Explorer, of course. But about React itself, we have things like initial state here, how to set an initial state, how to change a state, or not change, but produce a new version of the state. It's the right way to think. And render function. In detail, initial state, we produce a new object. This creates an object. State is always a JavaScript object, just as simple as that. And then we can assign a state by calling set state with a new version. So this is important, this thing of producing a new state, because we are never modifying the state directly. So we are providing a new frame, if you think of an animation. Just avoid doing this thing. This is a beginner mistake. You may just think, OK, I changed the state. And it's not working, because React needs to know when. I mean, you have to change your state and render or do whatever it needs to do. Then about the render function, which is something that at the beginning is a bit controversial, just for one day or two, is you see this HTML inside of JavaScript that looks very ugly at the beginning. It's not HTML, it's JS6. React will transform it internally into JavaScript. It will transform it then into HTML elements. And we will see later how to really divide the presentation and the code. But still it goes against any good practice I've ever had. You have to prepare. But then after two days, you are like, well, my code is clean, so I mean, it's not so bad. Then good practice to make render as clean as possible. Only a return is possible. At the beginning, ah, sorry. There are some things that change. This is part of memorizing. But this class is not class, because it's colliding with the class in JavaScript, for instance. So it's class name and very few things like that. And then you can also insert the expressions between these pointy brackets. Then about making render as clean as possible. It's just only do these kind of things. At the beginning, you don't know where to put your code, and you know that there is a render method, so you try to put your code. I tried to put all my code in there or whatever I could think of the first days. Here, we don't modify the state. Never. Here, we don't make Ajax calls. Here, we don't do any other stupid or crazy thing we need to do. We don't change the state of the world here. It's not something that will work. We have to find somewhere else. We have to write our own methods and call them. With this, we can start building our application. But if we are just writing a component, it will become very large, like very confusing at the end, a very super component. It's not very clean. So one important concept in React is to think about hierarchy, about parent children relationships. That's how we have small components that combine together. So you have something like this. You may, from the user interface, it's typically, from this interface, you extract which components you need. We call something like this, for instance, this separation. How do we work with props? Maybe our project manager decides that now we need not one counter, but two counters. And they have now a greeting in Spanish. I don't know why. Say, click me, amigo. Click me, señor. For me, more polite, less polite. I don't know why, but we have to do it. So we can just use our component that we wrote. Yes, as it was just a normal tag. It's not HTML tag. It would be translated to JavaScript, so to our code. Then, and then in our counter method, now we can receive this name, this property, as what is called props, a state that is given by your father or your parent. And you don't have a function to set props. You cannot change the props from children. So this is something that it's immutable for you. So you have to provide, for instance, a callback from your parent. That's possible. But it's one-way binding. This is important. And with this, we have seen a lot of React, like really a lot. Yes, it's a matter of writing and not committing small mistakes that you make at the beginning. In fact, we have seen so much that we can start to provide good practices. Like, if your component only depends on props, you can have this short syntax that is only about templating. If it's just you find yourself just writing a render that depending on props, you have this. You can have this shorter syntax. It's just cleaner. It's like a lambda function in ES6. Then this allows us to do this good practice. If you have a complex component with logic, auto-logic like Ajax calls and so on, you can split it in two. And one component has all the logic. And then in the render, yes, renders the presentational component that only depends on the state passed by its parent. Then this always, as you see, about the state and how to render it. Looks like simple, but it's really powerful. And then it's everything depending on the state. So we can do things like reproduce the states. If we restore a state, we can reproduce the state of a component or even a tree. We can rewind or time travel. This is particularly powerful in Redux. And do, for instance, is something that is not so difficult to do if you are just changing your state. You can log state changes, or you can, for instance, have storybooks. So you have someone who is just devoted to change styles or choose styles. You can have a storybook. There's a library called React Storybook. It feels great. And you put all your presentational components there with different combinations of states. So boot on disabled, like this. Boot on active, like this. And then they can just change, for instance, CSS and see how it changes. But it has more powerful consequences. One of the most powerful consequences is this what they call learn once, write everywhere. Which means that what if instead of this, what if it's this HTML-like component that we had in our counter, what if we have something like this now? This doesn't look like HTML anymore. This has something that is suspicious here. It's this switch-ios thing. This is, in fact, a render method of a mobile application, what it's called React Native. Then React can take your XML tags or your JS6 tags and translate it to JavaScript and then to native components. So they are more performant than just a web view. That's how React Native works. And it's because the web is just one of the targets. There is one side of React that is React DOM. There is another React Native. And there are more. Some of them by the community, not by Facebook itself. One that I find very cool is this React bless for terminal. You would say, terminal, what has to do terminal with React? Well, bless is an awesome library to build things like this. You see it, but it's like it has a map, it has charts. So if you are, for instance, in DevOps and you don't want to do anything with frontend, maybe you can still use React for things like that. I think it's super cool. And then how to, well, we know a bit of React. It's a bit about practicing this. How can we just use it? How can we, for instance, translate this JavaScript model into JavaScript that browsers understand? Well, recommending it up is to use Webpack. This is a module blender. So you have your source files, and you have some configuration to build your assets that you serve to the browser. And then Webpack has many good things, for instance. Manages dependencies for us, which is great. Allows environments. You have a production environment which is optimized and development, which has debugging options. You can do automatic pages reload when things change, or even you don't reload the page, but you change the code, and the state is the same. So without reloading, you change the code in there. This is particularly powerful in React as it's about the state. You can use preprocessors or transpilers. I don't like much this word, because how it sounds. Like Babel. Babel is for taking a modern version of JavaScript. You can even choose the features, even experimental features, and translate them to JavaScript that particularly Internet Explorer can understand. It has one drawback. It's, of course, a complex tool, so you need some time. And we cannot present Webpack in detail in this talk. However, I maintain a sandbox. If you want to look at it with integration with Symphony, I particularly use Symphony with some things for development and things like that. Want to check it out? I will upload slides later, don't worry. Then, but with this, let's assume we have Webpack in place. How can we insert React into HTML? So it's very simple. You just provide a tag, can be selected, and then you say to React DOM, the web part of React, to insert the component in there. Then, and this is what a front-end guy will do. We are not talking about PHP, right? But we can do some things in PHP. We wrote a library called React Renderer. We were looking at some things we wanted to do from PHP in React, and we ended up writing this library. But we were, in fact, copying another library, because we saw what other communities are doing. And there was this brilliant library called React on Rails, of course, for Ruby on Rails that made this guy from Hawaii. As you can probably guess, I guess. Which is very happy, right? And this library is great. So this has two parts. One is the Ruby part, and one JavaScript part that happens that we can use in PHP. So we can start using it. So you see here React on Rails, the JavaScript part has nothing to do with Ruby. So we can just register a component here, and we wrote a tweak tag. So you can say, here, insert my component with these initial props, right? And this will produce this element that then React on Rails knows where to put your component. So this is only something a bit nice to see, but it's powerful in the sense that now we are rendering from a tweak tag, so we can render whatever we want here. We can render this, or we can render other stuff, and that opens as the door to do server-side rendering. Server-side rendering, otherwise. Also called universal applications, and also called isomorphical applications, which happens to have a very particular meaning in Maths. It has nothing to do with the meaning we are using here. I don't know who came up with this isomorphical word. I like the word because I like how it sounds, because I go home and they tell me, what have you been doing today? I say, isomorphical things. And it makes me feel good, and you only leave once, but just keep in mind that you cannot keep this conversation farther with people. You cannot, yeah. So we had this fundamental premise, and this is another consequence. It doesn't say anything about browsers. It doesn't say anything about, I need a running browser. So you can say, what if you give me representation of a string? If I give you a state, you can give me a string? Yes, of course, so we can do this. It's good for, for instance, certain general optimization. Happens that the Google crawler, some of the Google crawlers have JavaScript, or others not, and you never know. Also, the Facebook crawler for social tags can be useful for this. And just to be sure, in Search Engine, faster perceived page loads you present with an initial state, so visual elements are in there. So instead of a spinner, it's a loader, you present with an initial version to the user. And also, we can cache this response, which is quite cool. Then how it works in this tweak tag, which is, you can say, rendering both, which is, by the way, the default option. And then it will produce all the code. Like, it will be everything in the first state just rendered for us. And then when React on Rails, or React finds our component, wants to inject it, we want to render it. And we'll say, OK, I see that it's already rendered, so I just take control over the component, make it more dynamical, and make it like a React application, a typical React application. Then how this works in the server side. Which options do we have to do, really, like low level thing? So first option is to call a Node.js to processor. This is, as it would be the equivalent of opening a terminal, we use for this the symphony process component, isolated without the framework. In this library, php.js, I wrote. An adaptation of one Ruby library I found. So it just looks, if you have Node.js, it just opens Node.js and says, OK, here is my code. And I want to render this component, give me the string. This is slow, because you have to know how php works. After every response, between request, you don't share the state. So you have to say, bye, bye, Node.js. I will call you with 90% of the same call next time. But yes, now I want this other component, all these other props. So this is a pity, but well. Then if you have php.js, php.extension installed that allows you to write, to execute JavaScript code from php, this library will use it. You have to compile it once, but it's easy to use. It has the same problem. You have to see this v8 extension, and you see, OK, I have to say goodbye after this, like, fight up. Using php.pm, I think it potentially can be solved, but I've not tried it yet. I think if someone wanted to try this, something that can work. Because there is a third option that is fast. So it's using an external server that is always running. Doesn't know anything about our code. Our code can be our banking, about health stuff. The node server is the same. So it's a bit annoying, because you have to keep it running as another service. And you have to, yeah, it has to be alive. Not super annoying, either. And it's faster. It's just a no-thing. Then options one and two in PHP. You have to provide this renderer you want, psp.exe.js renderer, or external server renderer. It uses, say, I will communicate with another server with a unique socket. So it was like this. I think that one possible setup is to have in development option one or two. And in production, use external server. And if you can cache in production, it's always better. It's something we can cache. Then now we can do this in PHP, or even in Ruby, or whatever, because people say, if you want to do this kind of thing, you have to rewrite your code in Node, which fix me out. Like, I have been working for years in my code. I have my models there. I like, I mean, they are good. They are tested. I have to rewrite, because I want to do this. Yeah, yeah, of course, yeah, because this is JavaScript. Well, it's not like this, but it doesn't mean, either, that you have to do it every time. It's something that introduces some complexity. We have to have our node server running. You have to do some adaptations to your code, so it's not making an hijack call in the first time, things like that. But something, if you need it, you can do it. Facebook, for instance, doesn't do it in Instagram. Instagram doesn't do this, even if they are experts, but they are doing it in other cases. So, and then, now let's talk about a bit about library. It has also some support for Redux. We can also give a brief introduction to Redux. Redux is something that is recommended, even by the author of Redux, which is from, I think it lives in London, at least. It's from London. Dan Abramov, he says, the first time you use React, don't use, it's better if you don't use Redux, if you have to be aware which problem, which kind of problem does Redux solve. So, when you find this problem, you know that you can really refactor your code and make it cleaner by using Redux. So, which kind of problem is it? If you are writing an application and it's a bit more complex, you will find that you have different places where you use the same state, right? So, let's see, we have this hierarchy, okay? Then, where should this state live? So, as children cannot pass their state to their parents or to their siblings, it should live in the first common parent, which is this one, it has nothing to do with the name. And also, they have these intermediate components that are just receiving a name and passing it to the children, like, I receive this from my parent, I pass to my children, I don't know if they are still there. So, you see the code and you see name going around, but the component has nothing to do with name, and maybe you have 50 things like this and you are like, I don't understand my code anymore and when you don't understand your code anymore, you know something that will happen very soon. So, this is the kind of problem that Redux solves, right? Redux, I think the important part is you have to have an idea of a circular flow, okay? I think this is the main point of Redux, because when you are using Redux, when you are at the beginning, it's not so difficult, but the code is split in several files, so you have to, like, so this is going on to this file or maybe this other one, so I don't know, until you have the full picture. And if you, when you have this circle, it's better. So, in your components, you can just dispatch now actions instead of changing the state, and action is like a description of something that has happened, kind of an event, it's just a JavaScript object with a description of what we want to do. And then, or maybe a click, and then there is something called Reducer that has, like, it's a huge, well, can be huge, or you can split in several Reducers, tends to be a big switch construction where you say, okay, if I get, if I receive this action, I know how to produce a new version of the state, so I can produce frames, and I mentioned frames, I know how to produce new versions of the state. This state lives in a store, and the store is connected to the components, so now the components can kind of connect it, like they receive as props the name, so they can re-render themselves. So, this is also explained with a picture, I don't think it will work in PDF version, but it's very easy because it will be like a wall moving around, like, following the arrow, so you dispatch an action, you create an action, goes to the dispatcher, and then the Reducer, using the current state and the action produces a new version of the state that is connected to the component, which will be updated, so same circular flow, right? Yeah, okay. So, we can use this in React Renderer because Ruby on Rails has support for it as well, so we just adapted it, and then you can just register a store, and you can connect your components to this store, so you can have just one component using this store, or you can have several components using this store, which can share state now, so you can, if you are not doing, for instance, a single page application, no JS people like to do single page applications so much, but I don't do them so much, so you can have, for instance, things like this, you have static components and react components, and they can just change the state, and the state, well, everyone knows because they share a store, okay. And this is why it will be like a general thing for a general application, but there is one special moment where we can do even better, I mean, there is a point of really a lot of friction, which is forms, friction between front and back end teams and technologies, because there's a lot of things going on here. When do we need forms in React, which are the cases? Inside of React components, you have a React application, you have a form in there, it will be a React form, important forms, for instance, when it's a purchase form, you are saying or renting a house, and you say, this house is not available on these dates, that you are filling your form, I see that, but I can just give you a recommendation of this other house, so this means better conversions, means more money, and probably means happiness, and also very specific forms, which are very dynamical, or I don't know, a calendar, date picker, I have this customer has these ideas, okay, I can do it. Also, forms that are not boring, even they are not related to money, you can, for instance, this is this company, type form, who builds this service, or they can, I think the forms can be used for other things on surveys, but this is a good example. I guess users are more likely to fill the survey if it's like this, then if it's like checkboxes, or radio buttons, that's just what I would personally do, like, you user, get your user, you have to use these checkboxes, just fill them. I have a feeling I would like to have, but suddenly it's not happening, it's better to use this. Then, typically, PHP frameworks have a form component that you may think it's only doing forms, but in fact, it's doing a lot of things. So, in symphony, it's called form, very, yeah. I think in other frameworks, it must be called the same thing, would be very confusing, otherwise. You can populate the form with initial values, you can give hints for which widgets do you want to use, we can bind and commit data, deserialize it into even existing objects, which is very cool, if you try to do yourself by hand one day, it's annoying, you can validate, which is also very annoying to do one manually, maybe with another component, but it's like integrated. And have a way to return errors integrated in the form. And then, they have typically this other side, create view, or helpers in other frameworks, but in symphony, you create a form view, which is like a presentation of the form. And this does the render view, which is awesome, if you give it for granted, like it's something awesome to have, show errors after zoom meeting there, which is also painful to do, and some client-side validation, right? Not so much, but maybe choosing the right type for HTML. But in APIs, at least, I like to use forms still in APIs to receive requests from post, put, to date, create, or patch, things like that, to update values or create new models. You miss many of these things that you gave for granted before, and you were so happy you didn't know. Like, you cannot have initial values anymore, like you can serialize your model maybe, but sometimes, in many cases, it's not the same representation, maybe you have a date in the form, which is a select or month, year, day, and you serialize your model is a string, so you have to work a bit more on this, some overhead, you cannot give, use interface keys, you cannot return errors easily, you have to serialize your form in some date that you understand, and, of course, we miss everything, we don't have anything in the right side. So, and also, if we want to do this kind of work, in JavaScript, we typically want to do even more stuff, we want on-summy validation, if there are obviously errors in there, like the price is negative, I don't want you to even ask the server, if the price is negative, that's wrong, so you can just send an error to the user. Or on-blur, sync validation, password, it's not strong enough, just keep working on this form. Or on-sync validation, just check with the server, your username is already chosen, I have these options for you, or whatever dynamic thing you want. So, but I still use forms for this because this is super good to have, right? Then, suppose this symphony form, this symphony form, in an example, it's typically in other frameworks, it's a choice, yes, with some countries, three countries in this case, and, yeah, the value you show to the user, you write the kingdom, and the value you want to receive in the post, GB, Deutschland, Spain, Spain, ES, and then a collection of addresses is simple and typical, but if I have to do this in an API context, I start to say, okay, have to do this. Why? Because if you are just using static HTML, you have this great view and creates perfect representation of the form, like everything is done, so yes, great view, is there with the right choices with everything. And then if you submit, you receive the exact data you want, not whatever someone interpreted from the documentation or whatever was written in the documentation, who knows who wrote these documentations, so, and then you submit, you bind the request, and then everything works, but in API, you don't have create view, so you have to, yeah, guess, okay, or based on the documentation, so, show the incorridors, maybe, we see, hey, Deutschland is not there. What's going on? So, read the documentation, what do you mean documentation? I didn't know, even it existed. And then, even if I'm writing this myself, the both parts, JavaScript and PHP, when I presume it, I know that it will fail, like I never, I never guess, in a complex form, I never guess the right presentation, the first try, and I start receiving errors like this. Not extra fields, what do you mean? Values selected is not a valid choice, okay, I'm not sure, I have to check. Things like, one of more given values is invalid, you have a long form, like, well, yeah, this is like, what's going on, and then, well, this was animation, throw in the computer, which is the feeling I have, and someone is like, why is taking you so long, it's just a form, and you are like, just leave me alone, leave me alone, I have to fix this, I know I will fix it. What's the problem we have? So, now we have to keep in sync three separate things, form in the server, API documentation, and form in the client. And this introduces some overhead, if you have to do only three, four forms, that's okay, you can live with this, you can argue a bit with the front-end guy for some time, and then you can be friends. But what happens if your application has to do a lot with forms, like we have this customer, they are some dieticians, and they wanted to build like an expert system, so they gather information from their patients in an interview, what I mean about them, a lot of information, and we build diets based on how they are, physically or what they prefer. So, we were very excited about this, so we wanted to do this expert system, they think it's so cool, how can we do this, we were discussing about this, and some day, I remember I asked the guy, what do you have in mind about the interview? What do you have in mind? Just tell me what you have in mind. And he was like, well, actually yeah, we gather a lot of data, and we wanted to have a step-by-step form, because otherwise we'd be huge, okay? And yeah, he just sent me the first thing, yes, don't work so much on it, but just send me what you have in mind. And I preserved this document for historical reasons in my company, which was this, and we were like, okay, and they started to say, this is just the first version, because we want different markets, and yeah, it will be like, we will be changing things all the time, and they send us like some ideas they have, like if you choose your woman, of course it asks you if you are pregnant, which month of pregnancy, stuff like that, if you, so this is asking you, pregnant in Spanish, by the way, or if you say, I must, I practice sports, how serious are you, you are taking supplements before, after, these kind of things, a lot of ramifications, also they wanted always to use iPad, they use iPad and they want sliders for everything, like everything can be used with a slider, they want to do this thing, so it was like the most important thing, sliders. Like for hours, for everything, well, okay, that's, then if your front and back end teams are just communicating with an API and they don't care about each other, this can introduce a lot of overhead, a lot of delays, I think, and which I think is even more important, even if your project sees the light, maybe you will see that the front end guy and the back end guy, in the Christmas party, they tend to not sit together, like, they are like, no, I've been arguing with this guy for the whole year, I hate him, so this is not great to have, I mean, it's not the way to build better products, right? So we were thinking, how can we fix this? What do we need? So we're missing this, we're missing this create view thing, so we can build something, right? In API, it always means serializing, so the answer of everything is serializing. Okay, then, in which format? What happens that there's a very good format for this, which is JSON schema, which is a standard, people, I tend to use it to serialize models, but I think it's also great for serializing forms, so, well, I think more people think that it's not our idea to serialize forms. With every standard, happens that when you read the specification, at least me, I don't understand anything, it's impossible to understand these kind of sentences, but it's easier if you see an example, like, this is how JSON schema looks, has properties, validation rules, types, you can even add your own options in there, it's not so strict about that, so we can add user interface, we want to use this widget here, so I always say, okay, this is great, let's use this, let's serialize, we are looking about people who are doing things like that, where people are using symphony, we are using symphony, so symphony component, you can take this idea to other frameworks as well, but we will serialize it for symphony components. So, there was this guy who was using forms to create forms in the terminal, in the console, so we used the same approach that he was using, the library, by the way, it's published, it's this one, so basically you have a resolver who has a lot of transformers, register, you can register more or create your own, so on these transformers, resolver looks field by field and says, okay, I apply this transformer to this field and I get this slice of the, recursively I get this slice of the form, so you get a full representation, maybe this one is a text area, so you can extract a lot of information from here, or maybe for instance, it's a daytime, so you can say the format is daytime, the widget is daytime, you can have required values, and in fact you can extract potentially, I think all the information that form view can use, it's easier to do than a whole view, so we were very happy because we, ah, sorry, we also needed two serializers that we wrote or the second one we copied from a first press bundle, which is a bundle in symphony, to serialize errors and to serialize initial values from the form, two other things we needed, I think easier but also useful, and with this we had this left part complete, right? So, but we're still missing the second part, where we can say, okay, we are backend developers, we have done our job because now we have backend and even a documentation that is always on sync, describes what we can do, so we, the number of issues decreases, right? But happens that once you have additional schema, you want more things because you can just have them for free, like for instance you can just say, look, we have additional schema now, just using this AGV library or other libraries, you can validate your data against the schema and you, if you see there is an error, just present to the user and you don't even have to send me a request because maybe the price is negative or something regular expression is not right, so we start receiving less requests, which is also nice, and also happens that we have a complete representation of the form, so we can write generators and there are many generators for React or Manila JavaScript, I've not explored the full field of generators, but I've explored the React ones. I think if you want to use one, I think maybe the first option or the first option will be use the Mozilla one, which is like has been for some time and people has contributed a lot, I think it's quite stable. We couldn't use it, so we wrote our own because it was not extensible enough, we couldn't do easily or even so, the way to build a wizard form, for instance, or to customize it so much, so we wrote our own, also using Redux form, which is a library that we think is awesome for forms, and anyways, if you are going to create your generator, it's not something crazy, especially if you only support some widgets, you don't need a color picker, like I had to provide a color picker to publish in this library, I was like maybe someone used a color picker so I wrote this widget, but sometimes you don't need all of them. Then, Redux form, which is the library which is doing the work, in our case, out of work has representation that is powerful in Redux, you can use it without, of course, without this library. You can have all kinds of validation, you can write your own widgets, and you know from the beginning that it's flexible enough, because if you see the front page, they have an example, for instance, for us for wizard forms, which is something if you are writing a form library, it's not something people tend to do, like in the first place, they say, okay, maybe you can adapt our library, but if they are flexible enough, they say, okay, you can use it whatever you want, I mean, the way you want, and they did so we need, we can succeed doing this. Then, using this as well, there's some boilerplate, importing, so on, but the important part is like this, using this component, reform, and passing an schema and submit function, it also has validation stuff, you can also control it, passing more props, write more arguments, but this is the simpler version that also fits the screen. And then, with this, basically we can have this schema and create, react a, react representation, like a react form. And with this, yeah, we got all of this, so we said, okay, now we can focus on the part that we really would like to do in this project, and we are so happy, and we had everything. And then, well, as I said, I maintain a sandbox for these concepts, the libraries we are publishing or so on, maybe you can, if you are using Symphony, you can take directly the concepts, or you can use a sandbox, maybe for something, for starting something, or taking examples, if you are not using Symphony, maybe you can use the libraries without like the bundle part, it's like the connection of the libraries which are pure PHP with Symphony, but the libraries can be used standalone. If you are using, if you are not using React, maybe you can take the idea from this talk of using, for instance, JSON schema. Or using Redux can be used with our React, by the way, which is a really nice library. But in any case, if you are not doing any frontend at all, I would like to just ask you to be a bit open about these frontend people, because just by thinking about what they do or thinking about the frontend, you can sometimes, many times, just do a better job together. And also, which is the main goal of this talk, which is that you have a nice Christmas party, like to save the Christmas, so people are really happy in Christmas party, which is very important. So, you have questions or, well, this is my contact details if you want later, or I don't know. That's it, thank you.