Why Does Everyone Hate Redux !?

It is official, we’ve hit the big one y’all! A company, ExcelWO Work Order Management, has commissioned us to help them build a software application that is both modern and will serve to simplify work order utilisation. The company aims to compete with the likes of names such as, Process.st, SalesForce — Case Management, and Atlassian Jira. ExcelWO realised there was an issue that needed solving;

“Coordinating work orders among groups of people is difficult, from creating the list of tasks to prioritizing them, then assigning them. Digital task lists exist, but they don’t connect the tasks at hand to objects in the physical world.”

And so the work began! For an application such as this, where global, predictable state would be utilised, connecting it to a Redux store was a unanimous decision — a mantle that was somehow passed to myself. I’ve heard several times that Redux boilerplate by itself is a pain in the backside to set up. However, I was excited as I looked at it as an opportunity to dive in and learn more about it. A bit of nervousness did indeed kick in, in lieu of not having dealt with Redux in over four months. The basic bare bones set up did not seem difficult.

Initialising the Redux store, pulling in the reducer(s) via rootReducer and wrapping the app in Redux’s Provider component.

Oh, That’s Why!

Okay look, I think I understand Redux pretty well. A high level description — you have a store, it serves as the one source of truth for any state or data, throughout an app, that would change. As a change needs to be made within a component, a dispatch() method triggers an action that is then pulled into a reducer. The reducer takes the apps’ current state and mutates a copy of it depending on the type of action and returns that new state to the components that are subscribed to the store.

Sounds easy enough right? So I thought! In the example below, my intent was to have a list of all work orders available, render on page load after the user has been authenticated. We used Okta for user validation.

useOktaAuth & getAuthHeader were already imported

I then imported the action I wrote

Dispatching the action getWorkOrders() inside of a useEffect hook, passing in a company Id of 1 and authState which is set to useOktaAuth()

Below is the action constructor getWorkOrders() that pulls in the work order data from our API.

Then the workordersReducer() which returns altered states based on the type of action.

Next came a climb that really tested my grit. Maybe from the codesnippets you might have figured out why my code failed to render on the dashboard page? As I’ve very basic experience with Redux, rendering the work order data from the API call was indeed the challenge I faced. However, I was successfully able to get a response in the console.

However , it proved challenging mapping that data to our dashboard component. Below was my one of many of our attempts at mapping the API response to our dashboard.

Initialising a mapStateToProps() method, then setting state to a variable allWorkOrders

And then…

Mapping the data from allWorkOrders to a card component MaintenanceCard that structured the data properly

Proceeding to the browser to load the page aaand…. It didn’t work! Nothing is showing up! Time to consult the oracle, well in this case peer programming. Got the team on several Zoom calls, all of us admitting our incompetence regarding Redux. However, we met and met, tried idea after idea, troubleshooted and debugged, all to no avail. It is unfortunate my contributions were unable to be used. However, all was not lost. A teammate who had experience with Context API was able to get done what we, I, was unable to accomplish, even with help from Team Project Leads, an SL, as well as help from a tenured Engineering Lead. So, as a team it was unanimous, due to time contraints we abandoned Redux and got things working with Context API. Check out our apps’ set up with Context API below.

WOProvider component is imported into the main index.js file. We wrap the App component with WOProvider.

WOProvider component accepts state props — workorders, setWorkOrders — as values so that they can be be passed down to the components children

Inside our dashboard component we are setting work orders to useContext() that returns that value that comes back from Redux’s createContext() above.

Then we use an HTTP GET request to pull in the work order data we need. You will see below we set the API response to a variable orders which was then passed into setWorkOrders().

Lastly, our work order data was mapped to our child component. Success!

Yup, I Hate Redux!

Hate to say it but I’ve jumped onto the “I hate Redux!” bandwagon. It was too confusing and mind boggling for me. As a team we couldn’t get it to work. Escalated help from Team Leads and still no luck. Yet and still getting help from a seasoned Engineer whom I admire, still, we could not get Redux connected and speaking to components properly. Although frustrated, I’ll have you know, I’m now, more than ever, inspired and determined to delve deep into React-Redux and really learn the inner workings and how to implement it in projects.

Thankfully we were able to achieve a smaller goal by taking advantage of React’s Context. Despite the uphill climb, features successfully delivered include;

• A modal that pops up when you click to create a work order
• Functionality to set work order priority and status
• Click on categories to see work orders grouped by status
• Work order priority colour coded

See below media.

In the future I can see an addition of working features such as — different levels of work order management depending on what user is signed in. For instance, say a tenant, they would only be able to create and maybe cancel a work order. Other features could include Twilio integration, allowing for message notifications concerning work order status to be sent in an app or through sms.

We may have gotten away with using Context this go around likely because the app is currently small and we really only used one component, the dashboard. I imagine that as the app scales and the code base grows, Redux would most definitely be a more viable option. Though I could not successfully implement Redux here, I don’t count it as a loss, but a turning point. My grit was tested, I did not call it quits, so to speak. I am more determined now to make sure to get my repetitions in so that when Redux next shows it’s intimidating face, I’ll be competent and far less intimidated.

This project added cross-functional, remote, team work experience to my belt. I’ve seen a small example of talent I’d be up against in my job search as well as in the workplace. I now have a measurable goal to work towards while preparing for an opportunity in tech. Also, this project has given me an opportunity to realise a need for knowing how to clearly communicate one’s experience and contribution on teams, and projects. I thank you all for reading. I bid you adieu.

Warmly,

Idong