This article describes the steps I have used to create a basic application using Ruby on Rails API, an ActiveAdmin dashboard and Create-React-App. There are many ways to get a website up and running for a small business, but here are the reasons that I chose these technologies:
I’ve had a project from my Flatiron bootcamp waiting patiently on Github for an upgrade. I wrote the project to learn how to build an app with Sinatra and then later with Rails. Part of the program was then rendered with JavaScript. The project was inspired by my AP Environmental Science students who were studying their greenhouse gas emissions from their diets. We were using real data, but finding the correct data and then analyzing it was a cumbersome process. The app I built only addressed the first step in the process - finding the data for greenhouse gas emissions from specific foods. It didn’t then provide a tool for students to track their own diets and complete the calculations. All of that we did with google sheets. This was a great way to teach students about google sheets, but in the end the complexity of the spreadsheets took a lot of time and some students got really frustrated with the long process. If the goal is to help students better analyze their own personal impact using real data and also learn about climate change, there needs to be a better tool to balance teaching students how to analyze data without creating a hurdle to learning by introducing overly complicated spreadsheets.
Building an app using React and Redux gives a developer a lot of flexibility and choices in how to organize the components and pass objects between those components. When learning React and Redux it can be confusing to determine when you have choices and when code needs to be a specific way. To help sort this out, I’ve created a list of the common choices that the developer can consider throughout the development of the app. For each, there is not a wrong answer. Any choice should work (as long as you code it correctly) and the decision comes down to the specific functions of the app and developer preference. For example, one developer may prefer to never use a local state while another developer may decide to use it for specific tasks such as storing form data until the form is submitted. For all these choices there is no need to treat the option as one or the other. Within the app you can use props from both routes and from connect, both functional and class components, and both local state and store. You can also code most of your routes in one container and then selectively move some to other components when it makes sense.
So if you’ve done some Ruby projects you probably have made friends with Pry or byebug to dig around in your code to fix bugs or better understand how your code behaves. But now maybe you are learning javascript and it seems that you need a new friend to help you get to know the DOM better. I was recently introduced to breakpoints in the Chrome DevTools while working with a Flatiron Technical Coach and my eyes were thrown open. As a kid did you ever do the invisible ink science experiment with lemon juice where you write something on paper with the lemon juice and it looks invisible? Then you hold it up to a light and the message shows up in brown like magic (except its science, but oxidation probably sounds less interesting than magic unless you are a chemist and totally scary if you are a high school chemistry student studying for an exam). Well, using breakpoints and seeing the values in your code appear is even more exciting than the appearance of the invisible ink. If your browser is set up like mine then they actually do show up in a brown box - just like the “invisible” ink.
Seed data is essential for building and testing any application that will collect or organize any data. There are several ways to generate seed data quickly to test your application without spending a lot of time creating data. The Faker gem is great for this and I used it initially when I started building my Food Emissions Log application for my Flatiron Rails Project. However, once I got the basic forms, views, routes, and controller actions working, I found that the Faker data not only generated unbelievable data (which was still entertaining and useable), but I needed specific values for some attributes in order to add features such as scope methods and dropdown menus on forms with specific options.