When I learned jQuery, I was on top of the world.
All the fantastic things like animations and manipulating the DOM were at my fingertips. The late 00’s were a tremendous time of learning frontend development for me.
Then, I no longer cared about frontend development. In 2012 I started learning full-stack web development. I was more interested in server-side code than frontend code. After all, I could do what I “needed” to with jQuery.
Well no, I didn’t.
To be honest, I didn’t have a desire to learn those frameworks. In hindsight, the lack of desire was because I had yet to work on a project that required much interactivity.
Things started well. Using my Ruby on Rails monolith, I was able to mock up the application quickly. I dropped in some jQuery, and voila- a working web application.
The code, though messy, worked. However, it made tracing down bugs difficult. There were no tests. I wouldn’t even know where to begin testing that.
That project should have taught me that, but it didn’t.
I once attempted to build an Ionic app using Angular 1. This experience left a bad taste in my mouth. I was (still am) unsure of what belonged where in Angular 1.
At the cost of my arrogance, I was ignoring an opportunity to yet again, fall in love with programming.
A lot of people I follow in the Laravel community began to evangelize Vue.js. I thought, well if they like it, I’ll love it. (I know, I need to work on following blindly.)
I enjoyed it! For a myriad of reasons.
Most notably, though, I enjoyed how easy it was to build an interactive frontend application. Instead of having to manipulate the DOM with jQuery, I was working with data.
The data drove the application!
I told myself a lie. In fact, I don’t think I ever heard this myth, I just assumed it.
Geez, telling you this next part is embarrassing. 😊
“No way this provides any benefit inside Rails applications.”
One day at work we began migrating a legacy screen we use internally. It’s rather complex. The current page relies on redirections to other pages for specific actions. This setup works fine, but it slows down the employee. They use this page frequently.
The page in question doesn’t need to be a standalone application with an API. It can (and should) live in one of our existing applications.
“We can make components for the sections of the screen that need to be interactive.”
What a great point!
DHH had just released a gem named Webpacker. Webpacker will configure and integrate Webpack (make sure not to confuse the two! 😭) into a Rails 4.2+ application.
- The application in question is a Rails 4.2 application. ✅
- We don’t need the entire page to be React. ✅
- Webpacker has an installer for React. ✅
We agreed and got to work on migrating the screen.
💖 React & ES6
The first week entailed an initial learning curve of how to think in React. Since then, I’ve been writing frontend functionality at a blistering pace.
Thinking of the frontend in components wildly changed my view of the frontend. These self-contained elements make difficult functionality easy to compose. Not to mention, it makes testing much more natural (once you learn the concepts).
Alongside React, I’ve been making use of JSX, ES6 module imports, arrow functions (🙌🏻) and much more.
The benefit, to me, is that I get to keep building Ruby on Rails applications. Instead of breaking them apart, I can implement React as I need it, and continue delivering at a steady pace.
My newfound React knowledge has allowed me to work on React Native apps in my spare time.
Though enamored with React, there is much more to explore.
The integration we’ve done with React and Rails isn’t specific to React. I’d be happy to give Vue another go with Rails, or even Angular.
Please Submit a Talk to RailsConf 2018!
If you’re in a similar boat, here are some resources I’ve found valuable:
- Frontend Masters (notably, the course on React)
- Laracasts’ Webpack for Everyone
- Webpacker (if you’re a Rails developer)