DEV Community: Michael Iodice

Dark Mode: A how to guide for React and Redux!

Michael Iodice — Fri, 26 Mar 2021 17:22:15 +0000

Who doesn't love dark mode?

I know I do! In this tutorial, we'll be taking a React application and adding in the new feature.

To keep with React / Redux best practices, the application should be a faithful representation of the current state. In order to implement the feature with this design pattern in mind, we'll be taking the following approach:

1) Adding a new component that renders a button
2) This new component will be responsible for dispatching an action
3) This action will update the application's state
4) Add a new reducer with a case to handle this request
5) Connect the header and footer components to Store
6) Have header and footer components render styling conditionally based off stores Dark Mode state

Start with the UI

I prefer to program in steps that seem logical, so let us start with making a button!

I opted to create this as a class component and connected this component to the Store so it could both dispatch an action to toggle the state of Dark Mode and connect to Store to receive the status of Dark Mode as a prop. This is helpful since the component is handling its own responsibilities, and also able to inform the user by changing the text of the button. Once we've created this component, don't forget to render the component within your own header file! It's as easy as importing the component to your header, and rendering the component wherever you'd like the button to display.

Wait a second, my button doesn't do anything yet!

Not to worry, next we'll create our new action. This is the action we're trying to dispatch on line 25 of the DarkMode.js component. Pop in to your actions folder, and create the following:

Excellent. Now let's head over to our reducer and create a new reducer. The only caveat here is if you are using multiple reducers. I am, so I've created a new reducer, pictured below, and added this reducer into my combineReducer function. I like this approach as 'darkMode' is now under its own key in reducer and not nested within other state for different parts of the application. It's easy to find at the root level, which is where I think someone else would try to find it. On line 11, we're able to set the default status of dark mode.

Check your dev tools!

At this point, we can examine state within our dev tools and see that the button component, when clicked should be properly dispatching the action and the state should be updating correctly. If you're working without dev tools that show state, the button should update its text between "Turn off Dark Mode" and "Turn on Dark Mode" when its clicked. This text is driven directly off the value stored in state.

Render color Schemes conditional on state's Dark Mode value

The final two steps are to alter your header and footer files to accept a prop linked to States Dark Mode value. This approach will vary depending on styling packages used and locations of styling within your application. For this project, I've used a Bootstrap template and by changing the class tags from 'dark' to 'light' and 'white' to 'black,' my color scheme inverts perfectly.

To leverage this built-in styling, I've connected my NavBar and Footer components to Store, and mappedStateToProps, handing in only the darkMode portion of state. Afterall, that's all these two components need to know about.

The final step is implementing a ternary operator, that evaluates if darkMode is set to True or False, and returns the dark color scheme if True, and the light color scheme if False. The styling is saved as a string to the variable and interpolated into the header.

The result

The header and footer color schemes invert themselves when the dark mode button is clicked! The button further provides information to the user to prompt them to turn on or off Dark Mode, providing a little more information than a standard button. This is a fun, easy-to-implement feature that gives the website a very different feel and may even encourage users to stay on your pages longer.

React / Redux, A Useful Tool

Michael Iodice — Thu, 25 Mar 2021 17:01:29 +0000

Have you ever spent hours manually calculating the 'CO2 cost' per mile of various vehicles and thought to yourself, there needs to be an easier, faster way to consume this information? There is so much great data, that is so hard to reach. This issue provided a perfect project for my final Flatiron School project.

The site would primarily be a React application and use Redux as a state management tool. Using Thunk allowed me to easily use asynchronous API calls and seamlessly handle the data when it returned.

The project started with two main goals, first was to make an easy-to-understand graphical interface that explained why electricity is 'dirtier' or 'cleaner' during different times of the day. The next component was to give consumers a tool to compare real emissions data for fuel (and electric!) cars to help them better decide on a vehicle to purchase. After all, a lot of car companies are talking about the environment, but a tool that allows users to dive back 10-20 years at a time and see how much progress has actually been made is more valuable. Actions speak louder than words!

The first piece of the project was relatively simple, it utilized a public API, meaning I did not need to handle any type of authorization tokens, special hashing, or anything of the like. The API did require time formatted in a particular manner and this required manual calculations. Once the Container responsible for the chart rendered a blank graph, a React lifecycle method componentDidMount() was used to fire off the asynchronous fetch request. This allowed me to load the information I had ready, as it became available and increase their user experience.

The next phase of the project proved to be more complex. I had decided from the outset that the user should have the ability to select as many vehicles as they decided to compare at once. This presented a fun problem to solve, and ultimately I opted to assign a prop to each of the "vehicle selection containers" I rendered on the screen. While mapping state to props, I used a ternary operator to check if the "vehicle selection container" existed in state, and if not, I created a unique key within state using the prop handed into the "vehicle selection container." This allows me to integrate a drop down menu that prompts the user how many vehicles they would like, and then render as many components they chose, automatically creating different props for each one. This is very handy as the chart package, ApexCharts, auto-scales the Y axis, so looking at two very dirty cars appears similar to two very clean cars, unless they are rendered at the same time.

The next main feature of the site is a series of API calls to the US EPA's API. These API calls are basically a menu-driven approach to selecting a particular year, manufacturer, and model of vehicle. As the information for the years is returned, the next API call will ask for all the manufacturers for that particular year, and return them, etc...

Once the user has selected year, make and model, we are returned a federal vehicle ID. With that ID, we make our last call to the EPA's API and are sent back many details on the vehicle. For fuel cars, we're able to directly apply the Grams CO2 per mile measurement to our charts. At this point, it became clear the ideal solution for pure battery electric vehicles was to apply the kWh/100 miles rating, to the real-time data from the UK API. This allowed me to display the 'dirtiest' and 'cleanest' gram CO2 per mile, depending on how clean the electricity was at the time of charge. Fantastic, a data-driven visual that allowed users to freely select a vehicle and display how clean it was.

So why is this all so important?

Well, as home heating and transportation move to full electrification consumers need a tool that can help handle the new loads in the cleanest possible way. Engineering solutions that double, or quadruple efficiencies of machinery can be extraordinarily expensive and therefore never succeed in the market. How many engineering hours would it take a 30mph car to reach 60-120mpg? I'm not sure, but I can tell you the technology has never reached production vehicles. If you had an electric vehicle, shifting the charge time from 6 pm (peak pollution time) to overnight can easily achieve this reduction. It only makes sense, therefore, to do this when the option is available. Many manufacturers of electrical appliances or vehicles make no mention of this while purchasing products. A Useful Tool should exist to fill this gap.

A lesson on fancy CSS examples

Michael Iodice — Mon, 01 Feb 2021 04:21:48 +0000

When it comes to poking through examples of slick features online, it's easy to get sucked into what 'could be.' During my most recent project, a Ruby on Rails API with a Javascript front end I decided to try to spice it up a little.

Front end work is admittedly less familiar than handling logic and backend organization, so I decided this would be my time to shine. After selecting a couple features I wanted to integrate into my application, I quickly got to work.

And stopped shortly after. The styling and amount of event listeners for very nuanced features was overwhelming. Piece by piece I removed the components that made it look so attractive, until I was left with the basic HTML elements, and a learned lesson.

I gained the bulk of the functionality I was aiming for, but at a significant cost. The final implementations took about 10% of the total time invested, the other 90% was unwinding complex styling and going down rabbit holes. I can say for sure, I will still be scouring the web to gather ideas of an ideal product but my approach will be completely opposite.

Pairing these examples down, especially ones you can identify as being outside of your understanding, to their base elements and starting there allows for early victory. Additionally, there is no point to having a pretty thing that doesn't work, so focusing on the nuts and bolts of the elements, prior to getting distracted with how they look will ultimately be a better user experience than something that is buggy or not functioning at all.

Lesson learned: aim high, but find the core components of each example and be strategic about the integration process. Most importantly, if you don't understand the basics of the example, set it aside for a time when you can properly research the implementation.

Teamwork makes the dream work.

Michael Iodice — Mon, 04 Jan 2021 03:03:16 +0000

I've just completed my first Ruby on Rails CRUD website for Flatiron's Software Engineering course. The jump from Sinatra to Rails came with a lot of new powerful tools, and helped fast track the standard setup for CRUD functionality. During this project phase, a key lesson I learned was the importance of teamwork.

Every student in our cohort is responsible for their own projects, but I opted to ask a cohort member if they wanted to 'pair' through the process together. It was a great learning experience, and after having established a rough plan to adhere to, we both were holding each other accountable.

The pairing process was constructive, time saving, and challenging. We prepared flow charts of our work, presented them to each other. We had to answer critical questions about design choices, and most importantly get over the fear of 'lost work' to accommodate a good point picked out by the other person, which ultimately yielded each of us better projects.

After planning was completed, we dove into programming and the pair process continued to pay dividends. Each of us helped the other get unstuck on various topics that we each understood. The debugging process was always over video chat, and focused mainly on helping the other person connect the missing dot and not simply solving the issue ourselves. The teaching process helped tremendously to reinforce our own understanding and yielded great satisfaction to help push someone into understanding a topic they couldn't grasp entirely.

The other side of that experience was equally as beneficial. At a point, trying to solve the same problem hour after hour can become very discouraging. The time lost on small things that can be quickly explained simply from another point of view can yield much more progress if focused on other areas. It was great knowing I could get a different perspective on something that just wasn't clicking.

With that extra time, we were able to exceed many of the project's requirements and troubleshoot the process together of getting our first 'local' programs working with Postgres and live hosted on Heroku. The satisfaction at the end of the day to see a project, built entirely by myself that far exceeded what I could have done on my own in the same time was a critical lesson learned and one I'm glad we took the time to experiment with. Teamwork makes the dream work.

Holding yourself accountable!

Michael Iodice — Sun, 22 Nov 2020 17:27:23 +0000

I have been a user of Fitbits platform for some time now. I love the dashboard that keeps everything organized, lets you easily set goals and watch your progress to achieve them. Wouldn't this be so much better if you could break out of the limited selections and keep track of everything that's important?

Enter, ReportCard. An application I have been wanting to build for a very long time now. For our phase 2 project in Flatirons Software Engineering program, we were tasked with building an MVC CRUD application that integrates a sqlite3 database with multiple tables containing relationships.

I realized this was my opportunity to build the application I had always wanted to see.

Its main features are providing the ability to create and track as many goals as the user could desire, over as many dates as they wish. The program lets the user choose if they want to track goals that are "yes / no" achievements, and also quantity tracking goals, for example, tracking miles of running.

The application then normalizes the achievements depending on the date ranges and how often the user targeted to achieve their goals, and gives them a percentage grade and the corresponding letter grade in a report card format.

In the future, I plan to build out feature sets to integrate Fitbits API to grab much more activity data and aggregate it into one place.

Fitbits platform proved to me that data driven results helped remove the "wishful thinking" of achieving a goal. I hope to provide users a tool to expand on this data driven approach and stay motivated to achieve all their other goals.

Ruby CLI Scraping Trail Selectors

Michael Iodice — Sun, 25 Oct 2020 20:59:53 +0000

The Journey

The journey through the first couple of weeks of Flatiron's Software Engineering course was tough at times, and very rewarding at others. Phase One's projects requirements were to find a website with somewhat structured data, that would lend itself to scraping and offer a consistent second page for "in depth" information to return. In order to structure our scraped data, we would need to have at least one "has many" class relationship structure within this data. The user would not need to know what was going on behind the scenes, and be presented with a nice CLI program to interact with so they could make selections.

For my project, I decided to use a website that featured the 100 top trails in America. I opted to configure my "has many" class relationships between trials and states, one state having many trails and each trail having one state.

What I loved

Of the material so far, the project was perhaps the most fun for me. My background in coding comes from replicating a product that was way too expensive (motion control equipment for camera time-lapses) or for products that I simply could not find, like my 'motivation box' project that opens upon completion of a to-do list android application. Being dropped in an empty code editor, the process of scratching out a flow diagram, identifying which tools would need to be implemented for the correct functionality and building each component one at a time felt very familiar. I enjoyed the stage of 'architecting' the program and trying to anticipate all the structural issues and concerns that I'd need to take into account when selecting methods.

Scraping proved to be the most time consuming part of the build. Having very limited experience with HTML, I found myself 'getting lucky' while picking selectors to hunt down my data fields. From here, I really enjoyed the step by step functionality building and then carefully analyzing which class was the most responsible to run the piece of code. Sometimes that was very obvious, other times not so much. I ended up using the main CLI file (as it guides the user through the program) to take user inputs and call on other class's methods as much as possible. From there, the classes focus on handing data back and forth between themselves as much as possible, only returning said data back to the CLI when it needed to be presented to the user.

The next big focus was taking care to eliminate all forms of variable storage possible within each class, and ensure that the CLI was calling class methods that would directly return the variables of each class instance. This is a very important process as it results in retrieving the 'primary source' of data, and not something that was previously stored in a hash, array, or variable. The requirements of constantly asking an entire class for specific pieces of data really provided reinforcement of the class & relationships between them. I also had fun building a separate validation class, as to make sure the user would be unable to cause the program to error out by entering the wrong inputs.

If I were to do the project over again, I'd have built another class which would have the ability to filter by activity allowed at the trails. The website featured bicycling, hiking, horseback riding, and a couple of other options which varied for each trail. I thought it would have been really neat to be able to select by activity type, and perhaps enter in a number of different states, and show the user the results that matched their inputs. After finishing my core functionality, I ended up on Zoom helping others with their questions and problems. Seeing them start to connect the dots and making new friends was extraordinarily rewarding. Looking back, it's hard to say if I would have learned more by implementing the new class, or by explaining concepts and looking at other students' code. Either way, I consider the first project a success and am feeling excited to head into my project review and share my work.

Real Estate Developer to Software Developer

Michael Iodice — Mon, 12 Oct 2020 18:54:04 +0000

My journey to software engineering

From an early age I took apart all my toys. I was very interested in their design and learning about new mechanisms was just more interesting than playing with them. These toys rarely made it back together, and most never functioned again.

Years later, I still find myself drawn to work and hobbies that involve piecing together solutions for difficult problems.

Perfecting the process

The process of understanding the big picture, developing a high level plan and then solutions for the unknown has always felt fun and natural to me. Managing different types of projects always lets me learn new things. Most importantly it also allows me another iteration of the research and implementation process.

In my previous role as a real estate developer / project manager, I was given a large amount of freedom to achieve our company's goals. I found myself excelling at the project management aspects but I was increasingly drawn to high performance buildings and environmental solutions that are needed to help solve climate issues.

Pivoting to solve different problems

After various university tours and many months of research, I resolved to pursue a career in software engineering. I am drawn to the 'fail fast' approach and the requirement to understand the entire scope of the task at hand, with the ability to construct every detail. Additionally, pursuing this career change is building on top of the knowledge I've gained from one of my hobbies - programming micro controllers for various items I could not find commercially available.

The next 5 months of bootcamp are sure to be a challenge, full of highs and lows. After completing the program I hope to find a company that offers great mentors and to continue learning from seasoned professionals. Eventually, my goal is to aid in developing software to better people's lives and facilitate the transition to a cleaner, healthier environment.