The Triple Threat: Rails, React, & Redux
I am finishing strong at Flatiron by making some final adjustments on my last project, which uses rails as an API for the back-end and React and Redux for the front-end. React is a Javascript library that makes it possible to create user interfaces with UI components, while Redux is another Javascript library that manages state through the use of store, the entire state tree. I decided to create a event planning application that allows a user to sign in, login, be automatically logged in (using his or her token on local storage), add events to a particular month, delete his or her own events, and search events by event name and/or description. A user can view all events altogether from others and themselves on the show page for each month to see what event he or she would like to attend in the future, with accessible links to the location as well as event website.
Instead of using React state manager, one of the requirements was to use Redux as a state manager, which does the same thing but in a more efficient way. Redux is especially helpful the bigger an application gets and the more components it is comprised of because parents don’t need to pass state, data, as props to their child components to sustain code flow. Redux uses an object called store, or global state, that handles all state changes through actions.
Actions, or ActionTypes, are events that come from a user’s input and/or button pressing that sometimes make use of the database. In my application, if a user wants to see a list of all the months, an action called “SET_MONTHS” will be passed to the reducer, dispatched, and the reducer will respond to the action by grabbing all the months from the database to be to show them to the user, which also results in the reducer returning those months in a new state until “UNSET_MONTHS” is called. Another example of a need for an action would be to create a new event from the event form.
A reducer is a simple function with two arguments, state and action, that takes in the current state of the application and uses the action being called to create a new state. Reducers are needed in order reflect changes from client’s side to the database. Any component that is stateful, needs to keep track of state and change data. On the other hand, any component that is stateless, is presentational, meaning it does not have a need for keeping track of state or make any changes to it. An example of a stateful component in my project would be EventForm.js, which adds an event to a month. An example of a stateless component in my project would be NavBar.js, which is used solely to show a user the navigation options for my application.
Thunk, a middleware that works with Redux, allows action creators to be called that return functions instead of objects. These functions receive the store’s dispatch method, which is used to dispatch actions inside the functions body.
One of my many dilemmas when working on my project happened when I was trying to render a month’s events. I would save this file:
and the months event’s would show just as I wanted:
However, whenever I refreshed the page, I would get this error:
I was stumped. Why did it happen to render the events perfectly only when commented out, commented back in, and saved but not upon refreshing? I console logged the “eventsArray” and was getting back exactly what I wanted an array of four events objects, which I was then mapping over each event object, on line 23 in MonthsEvents.js. As I come to find out, I was looking at the wrong file in my code the whole time. I looked at my reducer, and found this:
A month’s initial state’s events was declared as an empty string! Once I changed that into an empty array, the events were re-rendering whenever I was refreshing. Sometimes the errors are found within the simplest things, you even know the answer to and would think to not miss, but I enjoyed trying to debug this and laugh at my mistake at the end.
