So I finally decided to get around to learning React, after putting it off for…well a long time. Part of my reasoning was that there were so many frameworks around (Angular, Ember, React, etc) that I’d wait a while to see which one would become dominant. Most of my daily projects didn’t seem to require that heavy dependence on state and animation that seemed the benefit of using a JavaScript framework. Also, it felt like a bit of trend (still feels like a trend).
With Gutenberg originally being created using React, that more or less settled it for me, as WordPress is my go-to for a CMS. Despite the shift for Gutenberg to a framework agnostic system after all the drama with React’s lack of an MIT license, it still feels like the right choice.
So after plowing through a number of tutorial sample projects, I decided to make my own. I wanted to see how easy it was to use React to take advantage of the WordPress Rest API. This meant setting it up to pull posts from my website, displaying them in both list and post views, and allowing the user to search for posts by title. You can see the finished product here and see the code it runs on here. The result is a little on the recursive side as it’s going to contain the post describing it.
It’s a lot of effort for displaying something that WordPress almost does out of the box, but I can see some advantages. Once the page is loaded, shifting between views feels effortless, and setting up the search was very easy. Keeping the state in the app also means a lot of things run very well, like the search term remaining in place as you switch back and forth between post and list views.
React definitely scratches the part of my mind that likes things being kept modular and DRY. Things separate out into components that can be reused as necessary, and there are clear patterns for setting things up and keeping your code nice and neat. Of course, I ‘m sure there’s some React apps out there that are hot JavaScript messes, but it does feel like the whole way the framework is set up just encourages that economy of code.
Here were a few things I learned going through (or still haven’t figured out yet).
Dangerously Set HTML
The WordPress REST API returns the excerpt and content for your posts in HTML, only the second of which seems obvious (I’m used to the_excerpt() stripping out HTML characters). According to React standards, this is considered bad practice. To output the content, you have to name it dangerouslySetInnerHTML so that you know you’re doing evil:
<div className=”excerpt” dangerouslySetInnerHTML={{__html:excerpt}} />
There’s really no way around it for this, at least for the post content, as WordPress posts are going to include HTML. As I’m running this blog and controlling the content, it’s not much of a risk, but if I was handling other people’s data it would be more of a security risk. Running some regular expression to remove any script links from the HTML would probably be best practice in that case.
Routes
Part of my plan for this app was to have routes set up so my posts could live at a location like wordreact/postname or some such. I tried to implement this using the React Router DOM package, since this was what Treehouse had instructed me on.
This did not work.
The way the <Route> components work, they don’t play nice with the state of the app. You can’t send the state values into the route using props like you would for a regular component (not quite sure why this is). From what I’ve read online, the only solution is to use something like Redux to handle the state.
This feels like major overkill. Why use yet another major library just to handle something that seems as fundamental as routes playing nice with state? I guess this is why a lot of apps turn into giant stacks of technologies and libraries. This unnecessary complexification of front-end projects feels like a major problem with the modern web, while at the same time, many devs struggle to write semantic HTML. It goes against my philosophy of parring down projects to only what is necessary to achieve them. Keep it clear. Keep it clean.
Hopefully I’ll find a work around in the future. Otherwise, I guess I’ll need to shoehorn Redux into this at some later date.
CSS Animations
For the animations in the app, I’ve used a combination of straight CSS with keyframes, and the CSS Transition Group add-on. I had difficulty getting the package to play nice with the shift between the list and post view, so I had to add in the standard CSS keyframe animations as an alternative (basically elements animate when they appear). Ideally I’d only be using one of these options to keep everything tidy. Really the only reason to use the transition group package is so components animate out nicely, but if you’re using it you might as well use it for everything. If I do a second iteration of this, I may try using a different package like React Transition Group, as the one I used turned out to be deprecated. Still, everything more or less works with this approach.
Speed
It’s pretty snappy when it comes to that. 100% on Pingdom. Even Google likes it.
Closing Thoughts
I ended up liking React more than I thought I would. It’s fun to play around with when you’ve got the basics mastered, and it allows you to do a lot of very cool things very quickly. However, I don’t have a use case for it in the work I get paid to do, so for the moment it’s going to be something I play around with in my spare time.