Building a Web App with ReactJS and Laravel

I recently had the opportunity to build a web app using ReactJS and the PHP framework called Laravel. I was the front and back end web developer, the development operations manager, and the web designer. Somehow, it turned out okay. Note that this is not a tutorial, but that doesn’t mean you won’t be able to glean any useful information from it.

Install All the Packages

Development operations had me pulling my hair out, but the web development side of things (front end and back end) was more manageable. When I installed something, it would work… for the most part. Here’s a list of all the React and Laravel packages I had to install.

  • A Laravel package to manage images
  • A React package (which was broken) for managing pagination
  • A React package for letting users share their entries on social media.
  • A React package for using Stripe.
  • A React package (which was also broken) that created a popup to let users choose an image from facebook.
  • A vanilla JS package for managing cookies.

I’m sure there were many more packages, but those are the ones that come to mind.

The Confusions of React Router V4

Besides taking a few React courses on Teamtreehouse.com, I had never used React for a professional web application. I didn’t quite understand how to use it, but I was able to use it to build the web application. Getting it set up was very confusing though. React had just recently switched over to React Router V4. I never really understood what React Router V4 actually was the whole time I was building the app,. Basically, React Router V4 is a library for conditionally adding and removing (not just hiding) React components based on the URL/path of the site. Don’t try to equate React Router V4 with any routes that you normally use. It won’t work. I was equating React Router with Laravel routes, and I thought of  components as Laravel pages. That was definitely not the right way to think about them. They are a lot different. You can wrap a little button component in a route and only display that button on a page with the URL mysite.com/page-with-extra-button. You can put that button (<Route path=”/page-with-extra-button”><MyButton /></Route>) anywhere you want. It can be in a menu, in the footer, in a random component in the middle of another component. It can appear anywhere. You definitely can’t do that with a Laravel route. It is a very strange way of thinking about routes.

The Laravel Back End

There’s not too much to say about the back-end. I set up a couple models in Laravel and their corresponding database tables. Nothing really blew me away or totally confused me. Routes acted like routes. I still don’t quite understand Models, but I sure took advantage of Controller classes and functions.

For the most part, Laravel just acted as an API for React JS, and it acted as a very good API at that.

Development Operations (Launching the React/Laravel App)

I deployed the development project to the live server using git. I set up the app (the website) on a LEMP Digital Ocean droplet. Installing the Laravel dependencies was a bit of a doozy. I remember one composer package needed PHP 7.2 (gotta stay current, right?), and I had to uninstall the previous PHP version and install the new one. That caused some issues. I also had trouble (errors) setting up the MySQL database. Honestly, each of these errors seemed to be like a brick wall, but with enough troubleshooting, I was able to get through each one. In addition to actually building the app (development), I was also in charge of development operations (setting up the server for the site and deploying it) and web design. That’s usually how it goes in small companies. Since I’m not a designer, I got most of my inspiration from other websites.

A Good Result

There was so much stuff to do, but it turned out pretty good. It’s amazing to see everything working together in unison (and not crashing and burning).  One big issue is that the live site only updates every three hours. I think it’s a JS caching issue that I haven’t been able to figure out, but it may also be a Laravel template issue. It could also be both. EDIT: The issue was indeed a JavaScript caching issue. Each time I pushed the dev server to the live server, I’d have to change the version of the JavaScript file.

Because of time constraints, I had to really, really rely heavily on React and Laravel to work in development, and they both performed wonderfully. Would I use React and Laravel to build another web application? The answer is a definite yes.

If you want to read more about my experience with React, check out my article named My Biggest Takeaways from Using React JS.

Building a Great User Experience

As the web gets more sophisticated, the typical user experience becomes more demanding. Users expect more and more from everyday websites, even though they are everyday websites and not giants like Amazon, Facebook, or Yelp. These giants can provide “incredible” experiences because they have the resources. I put quotations marks around the word incredible because the experience really isn’t incredible. It’s just expected, normal, intuitive, and easy. The work it takes to create a user experience that feels intuitive is sometimes unimaginable. To a user, it just makes sense. I click this, and that happens. The typical user doesn’t think about the thousands of computations going on in the background in the blink of an eye. When they click something, and something happens, typically, the user isn’t awed by the fact that there is a complex system behind it made up of millions of lines of code with each component working in unison to accomplish a seemingly simple task. But users have come to expect that seamless experience on all the websites they visit. When a user clicks something, and what they thought would happen doesn’t happen, they usually don’t think “Oh, there is an incredibly complex system working behind this website made up of millions of lines of code that must work in unison. I can understand why this one small function might not work.” No, that would be nice if they thought that, but what they usually think is “Oh, it’s broken. What a terrible website.” But creating that seamless experience for users is becoming less and less of the monumental task it once was, thanks to SAAS (software as a service), APIs, and libraries like React JS. What once wasn’t possible a few years ago, is now possible for a few or even one web developer to accomplish. I don’t mean it’s possible for one person to build a clone of Facebook, but it is possible to harness a site like Algolia and a framework like React JS to create an incredibly fast and intuitive search experience: instant filtering of thousands of items, typo tolerance, ranking, distance sorting, and auto-complete. Granted, it will take a lot of work to set up that amazing search, but it is possible. And the possibilities are just increasing. The game’s getting more challenging. So, it’s time to step up your game. Get used to the fact that users will expect a “phenomenal” experience. Learn the ways of the new internet and pick up a skill like ReactJS or Laravel. As a web developer, you certainly won’t regret it!

My Biggest Takeaways from Using React JS

I recently started using ReactJS for projects at work a lot. These are my takeaways.

Not SEO Friendly

React applications are not SEO friendly if they load data using an AJAX request which is pretty much all React applications. None of the data retrieved from the AJAX request (like a blog post) will be indexed by search engines. To fix this issue, I started retrieving all the data for a specific page on first load. This does create some overhead in the application, but it’s worth it (and sometimes necessary). For example, the first time the user (or crawler) loads the application, I get all the data I need (blog posts), turn it into JSON, and echo it into a div. Then, when the HTML loads, I get the JSON string from the div using JavaScript (divEl.innerText), and I parse it with JavaScript (JSON.parse(json_string)). But I only do this if this is the first time the application is loading. It’s not very magical, but I don’t see any way around it if you’re not using Node. If you’re using Node, you can do server side rendering.

Routing Is Fun

Routing makes it really fun to conditionally show parts of your application (components), depending which page the visitor is on. There is nothing magical about Routes. You just wrap the component in a Route and specify the URL of that route. Then, when that route is visited, the component is mounted, and it is destroyed when that route changes. There are also Switch statements which are very useful.

Components Are Extremely Reusable

Components are incredibly reusable. When I first started using React, I thought of all components as pages. I created what I thought was a Login page and directed users to that page. But then, I realized that I could take that whole entire Login “page” (component), and load it wherever I wanted, as long as I supplied the right props.

State and Props

State and props are important. That’s kind of an understatement. State and props are the life blood of your application. If you’re building a blog website, state and props are the blog posts. Components are just used to display the blog posts (the state), and the components update automatically when the state updates. They are very tightly coupled. In fact, they inseparable.

Lifecycle Functions

Lifecycle functions are very important. Right now, the two I use the most are componentDidMount, and componentWillReceiveProps(nextProps). I used this component to solve my back button problems.

For example, I had a complicated component that would let the user filter the data and paginate. The route and URL would update with these changes (when I would get new data), but nothing happened when the user would hit the back button. The route (the URL) would change, but React would not get the data. I had to use componentWillRecieveProps to check to see if the route was changing. Since all of the changes were in the params of the URL, this worked pretty well for me. I would just get the previous page’s params, and get the data, again. I’m not sure if this is how I’m supposed to do it, but it works.

Hide Complex Components

You don’t have to destroy a component when you leave a route. You can load components (not using Routes) when a certain condition exists and hide hide them with CSS when that condition is false. This is completely fine. Vue has something callled keep-alive that works similarly. For example, I had a large component that loaded a lot of data and then performed a lot calculations on that data. Instead of including that component in a route (/oranges), I used plain JavaScript to check if the URL contained the word “oranges.” If it did, I would load the component and make note that the component loaded. If the user left the page, I hid the component using CSS, and I would reveal the component when the user visited that page, again. Simple, but it works.

Summary

So, React JS is not SEO friendly. Routes are fun. Components are incredibly reusable. And state and props are the lifeblood of your application.