(This is not a Halloween Story.)

We all rely on libraries to help make our programming lives easier. However, not all libraries are created equal. Sometimes you need to learn the hard way that the library you’ve chosen just doesn’t have the capabilities necessary for your desired end case. Maybe the real answer is a little vanilla Javascript.

I was recently working on a project and wanted to throw in some graphs to display user information from the database. It seemed like an easy enough task. I had already written the logic for my API calls. All I needed, now, was a way to display the information.

I had never used a graph in a project and decided to try Charts.js. I’m not sure if someone recommended it to me or if I found it on my own. So, like, with any new library I went to the documentation to learn how to implement a chart. It was a clean site with seemingly good docs. They had some examples linked up and it was compatible with React. I copy and pasted a tester not related to my code to see if it would render. It rendered. All good, I thought.

This is where the trouble began.

The issue I kept having while trying to implement a Doughnut chart was that I could not pass dynamic data into the chart. Hardcoded data worked fine. Was this a Promises issue? Most likely. I attempted to conditionally render the hardcoded data until my dynamic data loaded and then update the state. Again, no luck. After wrestling with this for a over a day, I had a decision to make.

Do I change routes and use a new library or keep trying and testing? I had a Monday deadline and each hour that passed was valuable.

In the end, I chose to change paths and used react-google-charts. It was very Googly. Little style but excellent functionality. I had my chart rendering with all my data in under an hour!

import { Chart } from 'react-google-charts';
const countObj = {};
const Charts = ({ poses }) => {

 const countObj = (poses.map(pose => pose.difficulty)).reduce((prev, curr) => (prev[curr] = ++prev[curr] || 1, prev), {});


        let level = Object.entries(countObj);
        let count = Object.values(countObj);
        let output = ['Difficulty', 'Number of Moves'];

return (

  <div>
    <Chart
    width={'420px'}
    height={'420px'}
    chartType="PieChart"
    loader={<div>Loading Chart</div>}
    data={[
      ['Difficulty', 'Number of Moves'],
     ...level


    ]}
    options={{
      title: 'Degree of Yoga Poses',
    }}
  />

  </div>

)

  };

Sometimes what we don’t know through a lack of experience can be one of our biggest obstacles in programming. I could have saved myself an entire day had I just switched chart libraries sooner. But, then I wouldn’t have learned about the difficulties of using Charts.js with dynamic data. Also, I would have learned less about why charting data is so fussy. And why it’s a great exercise to attempt to improve your asynchronous coding. One of the major issues you will face is breaking the page because your data has not loaded before it gets called in the call stack. In order, to prevent this from happening you will need to have some conditional rendering while the Promise is waiting to be returned.

It’s not that I won’t keep working to figure out how to properly render a chart with Charts.js. But, it is an issue when making use of a library and not fully understanding what is happening behind the scenes. It’s much harder to troubleshoot an issue when you don’t know how the library functions.

A big red flag and one that I will follow in the future is that I couldn’t find a single working example of Charts.js being called with an API or passing props to load in dynamic values. At NPMJS.com, there were a handful of different chart examples at a Github link. However, none of these examples had dynamic data being passed. I should have stopped before I got to this point. Lesson learned, I guess.

It got me thinking, though. I spent countless hours re-implementing reduce, map and filter, so that, I could better understand how to use these functions while coding. Maybe I need to take some of the lessons I learned in my early bootcamp days and apply it to the libraries I seek to use. At the very least, I will learn what’s happening under the hood.