Building a WordPress Plugin in ReactJS - My Experience
In this blog post, I'll tell you about my experience of writing a WordPress plugin in ReactJS. I hope that by reading this you will be able to decide if it's something for you or not. If so, then keep reading!
In this blog post, I'll tell you about my experience of writing a WordPress plugin in ReactJS. I hope that by reading this you will be able to decide if it's something for you or not. If so, then keep reading!
I have more than 10 years of experience working with PHP and WordPress. I started using angularJS when it first came out, and I liked JS frameworks ever since. When React came out, I gave it a try and liked it a lot.
I work for some big WordPress plugins, and I used react at work whenever that was possible. The problem I see now with react development in WordPress is that there are no tutorials on how to render small react apps in the WordPress frontend or the WordPress dashboard. Most tutorials cover building headless themes or building WordPress sites from scratch in react.
Sometimes you might want to build more dynamic features of the site in React, without rewriting your whole site. I will write more technical stuff about this in the future.
Naturally, when I had the idea to build WPCodeBox I used ReactJS as a framework. The reason was that I wanted a single-page interface, without switching pages and having to wait for reloads, I felt this would increase the user experience tremendously. That was later confirmed through user feedback.
WPCodeBox is made like a modern web app. The plugin itself is a single-page application (SPA) that is built in react. The backend is a custom-made API with which the frontend communicates. This way, the backend only returns JSON code, and there is no need for HTML. This makes the whole experience faster.
Writing and integrating a ReactJS SPA in WordPress was surprisingly easy. I just created a ReactJS app and rendered the code on the page of the plugin. More info on this in the next tutorials.
A big concern from the start was security. Integrating a Single Page Application with a custom-made API in WordPress created some challenges from this point of view, but also offered some opportunities.
Modern web apps generally don't use sessions and nonces, but newer technologies like JWT Tokens. I could have it implemented this way, but in the context of WordPress, it wouldn't have made much sense. To make sure the application is secure, I had to do 2 things: send the session data, and the nonce to the backend API, to make sure the request comes from an authenticated user.
Sending the session cookie was straightforward. Sending the nonce would have required a lot of boilerplate code for each request. My decision was to send the nonce in an HTTP header, this way, I could add it for all requests in one place and the whole system would be more secure. The HTTP headers are almost impossible to trick someone into sending in the case of an XSRF attack.
Altogether, the plugin turned out great using these technologies. And more importantly, it's a pleasure to work on developing features for it going forward. Hope this motivates you to try to use newer technologies in your WordPress themes or plugins.
