When I was first learning React I went through about 17 tutorials before I finally grokked what it was all about. Which is weird because React is quite simple really.
I’m gonna build the tutorial that I wished I’d had when I started learning it.
Let’s do this.
But “Do what?” you may ask?
We are going to build a blogging platform. It’s going to be Rails on the back end and React on the front end. We’re going to test with Minitest, Jest and Enzyme as we go along. We’ll deploy it on Heroku. We’ll use CircleCI for continuous integration.
We are not going to use Redux. I have an idea for a more object-oriented state management system that leverages the rich metadata that Rails already has and, hopefully, avoids all the acres of boilerplate code that every other React tutorial seems to generate. I don’t have a design for this in mind. I’m hoping one will emerge as we go along.
Let’s start with a quick planning session. What do we want our blogging platform to do?
An author can publish a blog post.
A reader can read a blog post.
The home page shows a list of posts, most recent first.
An author can edit a blog post.
Readers can comment on a post.
Comments are held for moderation.
The author can approvecomments.
Notify the author when there are comments.
At some point we’ll want to upload images and have multiple authors and fancy formatting and RSS feeds and other blogphernalia but that list is enough to get us started.
I’ll tackle the second story first because I like to get something working from end to end as quickly as possible and reading a post has fewer moving parts than creating one.
I’ve been using React for a while and now that I have got over my disgust for coding with angle brackets, I think it is wonderful.
It’s not all roses in React Land though.
Here’s an example from https://www.robinwieruch.de/react-fetching-data (nothing against this particular example. This is a typical React tutorial.)
Here’s the (kind of) equivalent code in Rails/haml.
class HitsController < ApplicationController
@hits = Hit.all
- @hits.each do |hit|
%li= link_to hit.title, hit.url
And that was just the view.
I haven’t figured out state management in React yet and that’s my mission in this series of posts — to find a better to way to hook the view up to a Rails back end. I have no idea whether I will arrive at my destination but I intend to travel well.
In my first React app, I tried to build an object model like I might in an iOS app and I passed a controller down through the view components to handle events. Disaster.
Then I discovered Redux and I used it for the next couple of apps. I felt like I had joined a south sea cargo cult. If React revels in a surfeit of syntax, Redux positively wallows in it. The tutorials never seem to end and I found I had to constantly go back three pages to remind myself of the difference between an action and an action creator.
On page 7 of the tutorial, if your actions and your action creators and your reducers and your selectors and your dumb components and your connected components are all aligned correctly you’ll get a bit of data to appear in a view but I can’t stop thinking the whole time how much easier it would be to just write 5 lines of haml.
When I am learning, I like to have something working with a few lines of code and then to build from there.
And finally, a bonus, and no doubt unwarranted, rant about functional programming.
After 30 years of OOP, I struggle a lot with functional programming. It bugs me no end that, in Redux, the things that look a lot like methods are on the other side of the island from where the data lives. It’s as though the cargo cult people discovered that you could throw a message in a bottle into the outgoing tide and it would be received in the next cove on the following Tuesday.
Why not put the methods next to the data that they manipulate? I’m imagining an object-oriented Redux that feels a bit like Active Record.
So that’s what I’m going to do. Like the final round of Whose Line Is It Anyway?, I’m going to try to sing Redux in the style of @dhh.