 Okay, I think we can begin. Thank you, Alain, to take the speech and talk as quick as that. I hope you enjoyed it. Thank you. Hello, everyone. My name is Alain Schnester. I do a lot of WordPress work and also more general Twitch work. I jumped in at last minute here to give a talk. The talk is targeting mostly plugin developers and people doing integrations into the WordPress packet. It is a bit more advanced, but not too deeply technical. It's more like a concept, not about the actual code. I just want to say that the talk was originally planned for 40 minutes, so I'll go through it a bit quicker, so please don't mind me speaking a bit faster. With Gutenberg, there will be a lot of changes that are ahead of us. If you already do integrations into the WordPress backend, you will need to be aware that there are some architectural changes coming. First of all, Gutenberg will change the admin backend to move it from a server-based interface to a client-based interface. What does that actually mean? If you look at this diagram, you see that we have the server that manages the current application state of where we're at on the screen and what we're completely trying to do. The server always sends the output to the client. On the client, you then see your admin backend, and when you click on the link, click on the button, that basically sends a request back to the server. The server adapts its date and then renders a new output for the client. The client in between these requests doesn't really exist. Inside of your browser, the page is just displayed, and as soon as you click something, that page is just gone, and your browser will wait for a new page to be loaded to be sent from the server. With Gutenberg, this will change. Basically, the server will send logic and data to your client, and your client is expected to manage the state of the application. The client here, as I said, is the browser. You can imagine this, that a JavaScript application will be sent to the browser, and the browser executes the JavaScript application. While you're clicking around on this application, it all just stays inside of the browser. The browser adapts the output, makes presents a nice animated user interface, and this all goes on inside of the browser without getting back to the server until whatever this application was meant to be is finished. In the case of Gutenberg, now it will replace the post-editing screen, so the application is this entire post-editing screen, so not only the editor, really the entire screen is one application, and you will be able to click around there and make changes. This all just stays inside of the browser, and only when you click on a new page, like if you move to the user's page or something, then this application will finish. In between, of course, there will be data being sent to the server. For example, if you hit the publish button, there will be a restive care request to actually store what you had in your editor inside of the database on the server level and set the status to publish, but the entire time the client application of the browser will still continue to run. This means that this is a fundamental different approach to going about building a user interface, so where you're now used to building templates on the server and working with URLs that get routed to new templates when you click on a link somewhere, you will now build the entire application, the entire logic in JavaScript and send it to the client. It is important to state that the way you work on the server is fundamentally different than the way you work on the client. So if you just try to replicate what you did on the server, exactly the same way on the client will probably have security issues and performance issues because these environments are totally different. So it's important to know that this environment that you will need to adapt the way the entire application state is managed. For example, on the client side, you cannot just do a quick request to the database to fetch one option from the options fields in the database because on the client side there is no database, it's as simple as that. So what you can do is on the client side you could do a request to the server to send you that option from the database, but if you do that for every single piece of information you need, all of a sudden you have hundreds of network requests. These network requests, they might be very slow, so that's not a very performant and scalable solution. So you should need to think about how do I set up my client so that once it runs, it has everything it needs to only get back to the server in very rare cases. The REST API integration is an important change. Every interaction between the client and the server runs through this REST API. REST API requests are expensive because it is always a network run trip. This might mean that your server is here in Switzerland and someone from Australia clicks somewhere and when he clicks the data gets requested from Switzerland and gets sent back, so it can be very expensive network run trips. Also, they are expensive in a different way because when you request unused data through the REST API, this might potentially be transferred over very costly mobile network connection, for example. In the third world, where it's very expensive to just be online when you send them all sorts of unused REST API data just in case you might need it, that can actually cost them real money. Also, REST conventions, they are limiting on purpose, so REST API is built on the HTTP verbs so that the HTTP protocol is like get, post, put, delete. Basically, the REST API is designed in such a way that you model resources and each resource can use one or more of these HTTP verbs. This means that when you build your API that the REST API should use for sending data, the modeling aspect can be pretty difficult because you need to map everything to these very simplistic resources. So you cannot just create a method, get all my active products from my store, you would have resource products and you need to think about how can I add filters and other qualifications to this request to get the active ones, for example. So the modeling aspect is also quite different than we used to on the server side. Then we have React components. So this single-page app that we'll now replace the host editing screen, it is a baseball React. It uses React components to build up the mock-up, basically build it with these encapsulated components where each component knows how to style itself and how to react to changes. So these components, they also are quite a change to how you might be used to do the mock-up when you're just sending an HTML out. It basically means that just like with object-oriented programming, you try to think about your building blocks of your page first and then build each building block in a separate, isolated and encapsulated manner and the mock-up then is just a hierarchy of these building blocks. So it's not just a random collection of mock-up that happens to look nice. It's much more structured, which is also more of a challenge to model properly, especially when this is new to you. There are many useful components that Gutenberg will provide out of the box. There's a reference in the Gutenberg Handbook where you can see these components and you can reuse the existing components and you can extend the existing components so that you don't always need to start from scratch. So if you want to build a call-to-action button, you can start with the button component and just add your customization. Then there's the Redux Dataflow. So state management is something that's actually a hard challenge to solve at scale and state management on the client side with the server not directly available is even more difficult. That's why in the React Keeper system they come up with Redux, which is a React-based flavor of the algorithm of the flux principles. So it starts with the basic premise that state is immutable. The easiest way to deal with state is when it doesn't change. When I have this data about my state, it will not change. It is immutable. This is a very powerful concept when you can just be sure you have a guarantee that there's no side effects when you just use this data. However, we are aware that while your page still needs to change in some way, state still needs to change. That's why there's this Redux Dataflow. It basically means that there's a cycle running all the time inside of the application where state data gets fed into the system and once it's in the system it is considered to be immutable. It cannot change. But if you want to make change to the state you can dispatch a change request so this change request will then get back to the cycle. The cycle Redux will process this change request to adapt the state and then feed the change state back into the cycle. But inside of your code you can always just assume that your state is immutable. You don't need to check the variable that I stored before is that still in the proper state? Did my value not go stale? And also you don't need to think about the ordering of your code. So if you load state and then pause and other code executes and might change that state it cannot have an effect on you because if it wants to change the state it will need to make a request and change state will be fed back in. So the order of execution all of a sudden is safe in any combination. You cannot mess up other people's code anymore by just changing something. So the vocabulary that's being used by Redux is that when you want to make a change it's called an action. Similar to WordPress actions in Dain but the concept is slightly different. An action is more like a command that you dispatch to make a change and Redux has a concept called reducers and it's basically like a handle of that command. So you create a command to do this and this change and the reducers they take this command and out of this command produce an adapted state that reflects the changes that we requested with this command. So once your state runs through all the reducers you have new state and it contains the result of the combination of all change requests basically for this state. This has all been abstracted away for Gutenberg in the WordPress slash data package so that you don't need to try yourself directly to Redux but more importantly to build an extension to this that works not only inside of your single application but that is modular so that for example the Gutenberg state can interact together with the state in plugins and themes because Redux is built traditionally for a single page app and in WordPress we don't have one single page app that makes up your system because each plugin is built in an isolated way so you don't compile your entire WordPress site as one application. WordPress core will be compiled and each plugin will be compiled in its JavaScript applications and then this WordPress data package is basically built to be able to have the Redux data flow across multiple of these applications. Yeah, that all sounds pretty interesting. The big issue that people normally face is if they have existing code if they have plugins or backend integrations this all sounds like you need to store completely from scratch because pretty much everything changes. So how can you avoid just rewriting everything from scratch only to find out one year later once you finish that was not really what I wanted. So there's a few methods you can use to gradually go from non Gutenberg code to Gutenberg code. The first one is the most simple one. It's basically it's considered to be a legacy approach. It's called server-side rendering and a server-side rendering basically means that you have a block but that block doesn't have a clue of how to render itself. It just has a callback to render its output on the server. So you can think of this as the block-based version of the shortcode. You basically tell the block when you register it okay you are block so and so this is your name and whenever you want to render yourself this is the PHP callback and the block will then call the REST API with this callback and the REST API when it gets triggered executes the PHP callback fetches the HTML that was rendered and hands it back over as the REST API responds to the block. There's also documentation for this of course. Here's a small example of how that would look. This is simplified of course. Basically you can see on the left side you have the arguments that you need to register your block and you can see that we have a render callback. So when we register this block by the way, as this talk was planned for Woodcam New York you will see references to New York everywhere. I didn't have the time to adapt it. So this render callback when the block is registered this is stored so that once the block wants to render itself it knows what callback to pass to the REST API endpoint that it needs for the server-side render. And on the server-side we can just build you can see that on the right side we can build PHP code that outputs HTML. Here in this case we're using a separate view as a PHP file and just include it with output buffering to reduce output but you can also use whatever other methods you use you can use moustache rendering or whatever else or just hard-code the HTML into the callback that's up to you. But the basic principle is that you can just provide a PHP function and that will be called over the REST API to reduce the HTML. So this, if you have for example a plug-in with a lot of short-codes this is a very easy method to just get it into the Gutenberg Editor where people then have blocks they can drag and drop it just looks like all the other blocks there's just, you notice that when every time it gets rendered there's a small animation to show you, please wait there's a server request going on but other than that it just works like normal short-code. It comes with a disadvantage though that like short-code it needs to be rendered dynamically every time the page is being displayed so keep this in mind all the other Gutenberg blocks they are usually rendered when the post is saved so the final markup is already inside of your HTML and for the dynamic blocks that's not the case so every time you display your HTML it will need to be re-rendered on the server side. So the next step let's say we have our plug-in we turn our short-codes into blocks so that's already nice but we have so much more stuff that's going on in our plug-in and if you also want to move that over to Gutenberg the second step I recommend is to think hard about whether you can abstract away your data model because very probably your plug-in will make direct requests to the database and as I said before on the client there is no database so all the code you've written that directly interacts with the database and it works by just porting it to the client side so when you build an abstraction of your data model first of all it allows it to decouple everything so you can change the individual pieces independently and you can provide an interface where you say ok from now on this is the contract that my server has the front-end and I will always ensure that this contract stays intact so as long as the front-end stays with the contract we put in place I can make whatever changes I want in the back-end as long as I fulfill this contract that's the role of the interface so this type of abstraction allows us to get some form of shield in front of our back-end code and we can make changes across the back-end code while the front-end still just uses this abstraction and never notices that we are currently making changes so this allows you to make more drastic changes behind the scenes without breaking too much what you're doing to give you a visual idea of how that would look so basically right now probably your code will directly communicate with your database and it's very difficult to then move your code over to use the REST API instead because the REST API is a requirement for using client-side code with data that's in your database so what we want to do is we put an abstraction layer in front of our data model this abstraction layer is the only thing that our code on our front-end code then sees or business logic then sees and from that moment on you can easily make changes behind that abstraction layer also this abstraction layer when these are smart objects they can contain additional logic to do routing so for example you can have your database and your REST API coexist happily while some requests are delivered by the database some requests are delivered by the REST API and the abstraction layer knows how to dispatch the individual requests the front-end code, the business logic they don't need to know where do I get to my data they just request the data and they get it and they know where it came from this would look a bit like this so for example let's say we have a collection of books in our database we want to show them on the front-end the interface book repository that just has a method FindAll to get all the books and then we can build an implementation that uses the WPDB database code to request these and this is now we're still using WPDB we're still using our database but now we have an abstraction in place and as long as the rest of our code only uses the interface the whole method then we can make whatever changes we want in the back-end I'll come back to this later so why use the REST API on the server side the REST API is basically the requirement to be able to bridge the network up so you have the back-end you have the front-end let's rephrase it you have your server code you have your client code so the PHP server API is the tool you use to bridge that gap and it is the first requirement for clean-board integration now basically what you can now do is as we had this interface book repository we could now build an alternative implementation that uses the REST API to fulfill this contract and here we're using the REST API directly from the server so we're not making a network request we're using the REST API to build the REST API objects because the REST API also comes with an object model that is directly usable in PHP so we can now already start using the REST API on the server while we still haven't moved everything over to the client this allows us to safely shape our REST API model the different endpoints we need while we still have the database then we can build reusable React components so there will be a transition phase with every big major change there's always a transition phase and you want to make sure that you're not stuck too much in a state where you need to maintain multiple versions of your code that is very costly, very error prone and you want to reuse this as much as possible so one way to use this is to immediately start using React components instead of the usual way you're building your interface and use these in such a way that you can use the inside of the Gutenberg interface once that update comes as well as in your other code without Gutenberg so that you can just use the same code in these two environments so there's an example that is currently being used in production it's the Yoast WordPress SEO plugin they are using this mechanism so if you look at this screenshot here you can see that we have the Gutenberg editor with the sidebar on the right and the sidebar contains Yoast SEO integration and if you look at the source code of the page you see that this is all React components it looks a bit cryptic but just believe me that these are React components that worked with React before and what they have done is they built a meta box container that mimics the Gutenberg sidebar so that this meta box container can accept the same React components the same Gutenberg components than the real Gutenberg editor uses so what they normally have in Gutenberg in the sidebar without Gutenberg it just ends up in a meta box because this meta box is not smart enough to accept React components so they can build the entire code just once and the only thing they need to maintain is this container to allow React components to running you can see that in the source code here at the bottom it's the same component it's the exact same code that's being used it's just that they had to provide their own container here's a bit of a simplified example of how that looks so they built a meta box that creates the right environment for React where we have a store provider a sidebar item etc and then the snippet editor that is this reusable piece of code that works within Gutenberg just as well as outside of Gutenberg without any changes finally in the long run first of all you should always control the fragmentation you should always make sure that whenever you don't need to maintain any legacy code get rid of it as soon as possible you should keep your code it's very flexible with Gutenberg there's probably still a lot of changes ahead of us some might be pretty unexpected depending on how you catch up to us so always keep your code base very flexible as with the abstractions that are showed and then finally also properly embrace Gutenberg once you've managed to make your existing code work in some way think hard about how you can make the best use of the new environment at Gutenberg of us because what you use now as interface in the old paradigm will not be the best use experience you could do within Gutenberg there might be other options and you could do much better with a different approach the key takeaways for this talk so for a gradual move to Gutenberg first you use existing code through the server-side render component move over your shortcodes and your widgets etc then abstract away your data models so that you are able to gradually move it over then optionally build React containers which can accept reusable React components so that you can manage to have most of your code be reusable with or without Gutenberg and then finalize a tight user interface and user experience integration while getting the most out of this new environment at Gutenberg of us and the most important one stay flexible and adapt to change because change is coming and just know that you need to deal with it in the future so you set yourself up as flexible as possible in the present time thank you very much I'm not sure how much time we have for questions two minutes is there a question a next two minute question I will also run around here later on I just want to know if we can find your slides yes I will tweet the link to the slides as soon as I leave the room here with the hashtag for we can present thank you I've originally had a few quotes saying that you didn't need to learn React and everything to build Gutenberg components is that still true or is it more than enough there is still work being done on allowing pure server side registrations so that allows you to even have very simplistic blocks without any JavaScript at all this is not completely finished but there is still work being done on it and you can also as long as you stick to the conventions that Gutenberg sets you can also use any other framework or no framework at all for building your blocks in the end it's just JavaScript but using React makes it faster and easier experience because you can just reuse what has already been built with Gutenberg and you can just assume that React once Gutenberg hits React will just be available so you don't need to deal with providing your dependencies and so forth you can just as well use Vue for example what do you mean though that you will have React and Vue loaded at the same time which is not necessarily your best interest if you want to create a barely inside I have questions so I have been asking in the core editor channel I wanted to register a block which renders a recent post and I think there is still no way to not create the HTML on JavaScript side and on PHP side so is there a way to do it but I don't need to duplicate the HTML I write you mean templates you can render on both clients my problem is that I would need to write it down in React obviously but it's a dynamic block so I would need to do it in PHP too so you just need to use the server side render for this component right? you can also for example on the server and on the client side you could fetch the output from the server side and then send it in some way depending on what you are planning to do you could also use you can for example render a JavaScript code on the server side as well if the server allows it JS for example on the server side can create isomorphic code that allows you to run the same JavaScript on both client and server so you can do the same rendering step on the server as well if you need it on the server but in general, especially in the WordPress this is still an unsolved problem because in the WordPress you don't usually have no JS running on the server or things like that so all the tools that are out there to solve this problem usually assume that your JavaScript available on the server that's not the case with the common WordPress server so you would also stick to the server side render for components to do this it really depends on the actual use case so you should really think hard about what your performance and scalability requirements are and then think about best approach and optimising for that because there's probably no approach that is best overall it's just depending on what your actual use case is you might optimise it in that direction because for example dynamic server side rendered code will need to render step every single time you're in that page so you need full caching etc. it depends on the exact use case this is true at the moment too so the WordPress template has changed right now even the there are some components that still use server side rendering because of that so thank you yes thank you very much thank you so much