DEV Community: Clarence Gatama Chege

JCars Logistics: From Raw Data to Actionable Insights Using Power BI

Clarence Gatama Chege — Wed, 30 Sep 2026 12:34:08 +0000

JCars Logistics is a Kenyan vehicle sales and logistics business operating from a main yard in Nairobi and seven other branches. It sells vehicles to individuals, dealers, corporates, government bodies and NGOs and arranges delivery to customers.

Understanding the Dataset
The raw data came as a single flat CSV export Jcars_data.csv containing 32 columns. The grain of the dataset: a row represents a sale made by Jcar with the following fields recorded for each sale:

Item	Detail
Source file	`Jcars_data.csv`
Columns	32
Grain	One row per order (identified by Order ID)
Customer fields	Name, Type, Age, Rating, Review Count
Location fields	Region, County, City, Branch
Vehicle fields	Make, Model, Vehicle Type, Year, Fuel Type, Transmission, Color
Money fields	Unit Selling Price, Unit Cost, Discount, Delivery Fee, Logistics Cost, Revenue Recorded
Process fields	Order Date, Delivery Date, Payment Method, Payment Status, Delivery Status, Returned, Lead Source, Sales Rep, Unit Sold

DATA QUALITY AUDIT

Missing header - header values were saved in first row.
Missing Values - all columns except Customer Type, County, City, Branch, Sales Rep, Car make, car model, Fuel Type, Transmission, Color, Unit Selling Price, Payment Method, Payment Status and Revenue Recorded have blank values.
Inconsistent formatting - the two date columns , order date and delivery date have different date formats ,for example, 03/20/2026, 10-Feb-25, 19/01/2025. Currency columns also have inconsistent formatting with values having different currencies for example: USD, KES, KSH, ZAR and others not specified. Text columns such as Customer name, Customer Type etc also have formatting issues. Some text values are in proper case, others are fully uppercase and others are fully lowercase.
Inconsistent Categories - examples of inconsistent categories in this dataset include government, Government, GOVERNMENT, govt, GOVT all representing the same Customer Type. Such cases are also there in other columns like Region, County, City, Branch, Sales Rep, Lead Source, Car Make, Car Model etc
Possible Outliers - in the dataset there is an entry of a customer whose age is 121

DATA CLEANING
1. Headers- my first cleaning step was setting the first row as the headers. This can be done in Power Query Transform Tab under the Table Subgroup. The screenshot below show the before and after transformation.

Before:

After:

2. Formatting - Most text columns have values in different formats e.g, all uppercase, all lowercase and others in proper case. I converted all text columns to proper case on power query by right clicking each text column and selecting Capitalize Each Word under Transform.

3. Inconsistent Categories - there are columns with different values representing the same thing e.g, government, Government, GOVERNMENT, govt, GOVT in Customer Type column. I used Replace Values to replace the different values with a single value, for example for Customer Type government I replaced all values representing government with a common value Government.

4. Category columns

Columns such as Car Make, Region, Branch, Sales Rep, Payment Status and Delivery Status were cleaned with:

Trim / Clean (Transform tab) to remove extra spaces and non-printable characters.
Replace Values, run once per known misspelling or abbreviation (for example totoya - Toyota, nbi - Nairobi).
For columns with partial entries (Sales Rep recorded as just Grace instead of Grace Njeri), Replace Values was used again with "Match entire cell contents" checked, so the fix only applied to standalone first names and did not corrupt rows that were already correct full names.
Remaining unmatched or placeholder values (blank, "na", "unknown", "tbd") were replaced with Unknown.

5. Numeric and currency-style columns
Columns Unit Cost, Unit Selling Price, Delivery Fee, Logistics Cost and Revenue Recorded were mixed KES, Ksh, USD, EUR, ZAR, R and an unrecognised ? symbol. Exchange rates used in cleaning were: USD - KES: 129.45,
EUR - KES: 147.28,
ZAR - KES: 7.85
Here is how they were standardised to KES:

Detect currency from the prefix before stripping symbols, using a Conditional Column (Rate Multiplier): USD/$/? - 129.45, EUR - 147.28, ZAR/R - 7.85, KES/KSh/no label - 1.
The ? symbol did not have a clearly identifiable currency. To determine the most appropriate currency, the affected values were converted using the USD, EUR, and ZAR exchange rates. The USD conversion produced results that were reasonable and fell within the expected range for each row.
Another Conditional Column was used to flag rows with a M suffix. For these rows the new column stored 1,000,000 as a multiplier, while all other rows were set to 1.
Replace Values was used to strip the currency labels (USD, EUR, ZAR, R, ?, ,) from the original column, leaving just the raw digits, which was then converted to a numeric type.
Combine the columns. The three columns (the cleaned numeric value, the Rate Multiplier, and the millions multiplier) were then combined by multiplying them together (product) producing the final standardised value in KES. ** 6. Word-based numbers Columns like Customer Age (thirty) and Discount (fifteen, ten percent) were handled with Replace Values, mapping each specific word to its digit equivalent, before the column was converted to a numeric type.

6. Validity ranges

Enforced with Conditional Column, setting any out-of-range value to null:

Column	Valid range
Customer Age	18–100
Customer Rating	1–5
Discount	0–50%

7. Sales Rep specific fix

Some rep names had a stray 1 in place of the letter i (for example Fa1th for Faith). This was corrected with a Replace Values pass (1 to i) run before the name-matching replacements, and double spaces between first and last names were collapsed with a second Replace Values pass (two spaces - one space).

8. Derived columns
Expected Revenue was added as a Custom Column:

[Units Sold] * [Unit Selling Price] * (1 - [Discount]) + [Delivery Fee]

9. Date Column Cleaning
Dates arrived in mixed formats and some had been stored as whole numbers (Excel serial dates). The steps below were used to clean Order Date & Delivery Date:

Mixed date formats: a small number of dates were in mm/dd/yyyy instead of dd/mm/yyyy. These were identified and corrected manually using Replace Values to swap them into the consistent dd/mm/yyyy format.
Whole-number (serial) dates: to isolate these, the date column was duplicated. The duplicate was converted using Change Type - Whole Number, which turned every genuine date-text value into an error/null, leaving only the true serial numbers intact.
That duplicate was then converted using Change Type - Date, which correctly resolved the remaining serial numbers into proper dates.
A Conditional Column combined the two: where the original cleaned date column had a value, it was used; where it was null, the converted duplicate (now holding the resolved serial dates) was used instead. This conditional column became the final cleaned date column.

Assumptions and Business Rules

Grain is one order per row;
Expected Revenue = Units Sold × Unit Selling Price × (1 − Discount) + Delivery Fee.
Discounts above 50% are treated as data errors.
Values without a currency label are assumed to be KES.
Ambiguous ? currency values were assumed to be USD.

Data Modelling Approach

The flat table was reshaped into a star schema: one fact table of measurable events surrounded by dimension tables of descriptive attributes. Benefits: smaller model (repeated text stored once), faster filtering, and simpler DAX.

10. Important DAX Measures

Total Revenue = SUM(Fact_Sales[Revenue])

Aggregates the pre-computed order revenue; responds to whatever dimension is on the visual.

Total Cost = SUMX(Fact_Sales, Fact_Sales[Unit Cost] * Fact_Sales[Units Sold])

Total Gross Profit =
SUMX(Fact_Sales, Fact_Sales[Revenue] - (Fact_Sales[Units Sold] * Fact_Sales[Unit Cost]))

Gross Profit Margin % = DIVIDE([Total Gross Profit], [Total Revenue])

Units Sold Total = SUM(Fact_Sales[Units Sold])

Avg Customer Rating = AVERAGE(Fact_Sales[Customer Rating])

Total Logistics Cost = SUM(Fact_Sales[Logistics Cost])

Net Logistics Margin = SUM(Fact_Sales[Delivery Fee]) - SUM(Fact_Sales[Logistics Cost])

Calculated column example

Age Band =
SWITCH(TRUE(),
    ISBLANK(Dim_Customer[Customer Age]), "Unknown",
    Dim_Customer[Customer Age] < 25, "18-24",
    Dim_Customer[Customer Age] < 35, "25-34",
    Dim_Customer[Customer Age] < 45, "35-44",
    Dim_Customer[Customer Age] < 55, "45-54",
    "55+")

11. Executive Dashboard Design

Purpose: monitoring, not investigation.This is to allow stakeholders to quickly understand the organisation’s overall performance at a glance.

Detailed Report Structure

Key Findings

Kakamega sold the most units, collected the highest revenue, and had the most fully paid units.
Thika had the most refunded units.
Only Athi River, Kakamega, Mombasa and Nakuru had a positive gross profit margin.
Sales were heavily dominated by Toyota (144 units), with Mazda second at 69 units, less than half.
Toyota had the highest gross profit (KSh 23.26M); Isuzu had the largest gross loss (KSh -23.06M).
Peter Kiptoo sold the most units of the most profitable vehicle.
Mitsubishi, Mercedes, Mazda, Isuzu and BMW had more than 50% of units not fully paid.
Orders with the most cancelled payments were mainly handled by Daniel Kimani, Grace Njeri and Faith Achieng.
Kakamega and Thika had the highest delivery fees and logistics costs.
Delivery fees are KSh 2.99M below logistics costs.
Customer view: the 55+ age band generated the highest revenue (KSh 0.36bn); the top customer was John Kariuki (KSh 53M); Individual customers had the highest share of fully paid units.
Volume does not equal profit. Most branches sell at a negative margin, so growth without margin discipline increases losses.
A large share of units across five makes is not fully paid, creating collection risk.
Delivery is a cost centre. Fees recover less than logistics spend.
The best branch is also expensive to serve. Kakamega leads on sales and collection but also on logistics cost.

Recommendations

Tighten payment collection — set up minimum deposits for each order and do payment follow-ups.
Review Isuzu and loss-making branches — check pricing and total cost incurred.
Reprice delivery either based on distance or vehicle type to close the KSh 2.99M logistics gap.
Investigate Thika's high return rate and improve pre-delivery checks.
Coach sales reps on cancellation-heavy accounts.
Replicate Kakamega's sales practices elsewhere while monitoring its cost-to-serve.
Improve data capture — mandatory cost fields, single currency at entry and age range validation.

20. Conclusion

The original flat file contained inconsistencies that needed to be addressed before meaningful analysis could be performed. After cleaning and validating the data, it was transformed into a structured star schema with reusable DAX measures and an interactive dashboard. The analysis shows that JCars Logistics generates strong sales but faces challenges from low margins across many branches, a significant share of unpaid units, and delivery costs that are not fully covered by delivery fees. Future analysis can be strengthened through better data collection, including accurate unit costs, reliable customer identifiers and consistent currency records.

The full project, including the Power BI file and supporting files are available on GitHub: Github Repo

Data Modeling, Relationships, and Joins in Power BI: A Practical Guide

Clarence Gatama Chege — Mon, 14 Sep 2026 18:56:15 +0000

Power BI is a business intelligence tool that allows you to connect to various data sources, visualize the data in reports and dashboards, and then share them. Power BI helps to track Key Performance Indicators (KPIs) and helps businesses to get insights that inform decision making.

This article explores data modeling in Power BI, comparing flat table, star schema, and snowflake schema designs; the role of fact and dimension tables; how relationships and filter direction work within the model; how joins in Power Query differ from relationships in the data model; and finally, a recommended approach for structuring a typical business intelligence solution.

Data Modeling

Data modeling is the process of creating a structured and visual representation of data and their relationships. Without data modeling, Power BI projects suffer from bloated file sizes, slow performance, and incorrect report numbers.

A well-designed data model is important for several reasons:

Reporting and analytics - a clean data model is crucial because it ensures fast report performance, accurate calculations, and a simplified structure that allows users to easily build and scale their own analytics.

DAX calculations - DAX measures rely on relationships between tables to filter and aggregate data correctly. A strong model keeps DAX formulas simple and predictable; a weak one forces overly complex workarounds or produces incorrect results.

Performance - a clean data model reduces memory usage, allowing dashboards and interactive visuals to load and filter instantly.

Scalability - a good model can absorb new tables and new data sources without requiring a complete redesign.

Maintainability - when tables are logically separated with clear relationships, the model is easier for others to understand, troubleshoot and use over time.

In summary, a well-designed model makes reporting, analysis, calculations and performance much easier, while a poorly designed one creates unnecessary challenges at every stage.

There are primarily three structural types of data modeling in Power BI: Flat Table, Star Schema and Snowflake Schema.

1. Flat Table
A flat table is a single, wide table that stores all relevant information in one place. It has no relationships and the data is in a single, spreadsheet-like structure. This is typically what a dataset looks like the moment it's loaded into Power BI from a single Excel file or CSV before any modeling.

2. Star Schema
A star schema is a data modeling approach where a single central fact table is connected directly to multiple surrounding dimension tables, forming a shape that resembles a star when viewed in Power BI's Model view. It is the most widely recommended structure for Power BI reporting.

Fact table - a central table in a data model that stores the measurable, numeric events of the business along with foreign keys linking each row to the relevant dimensions.
Dimension table - a supporting table that stores descriptive attributes about the entities involved in the events stored in fact tables.

The screenshot above shows a Star Schema. FactSales sits at the centre of the model, connected by four separate relationship lines to DimCustomer, DimProduct, DimLocation and DimDate with their relationships.

Advantages of Star Schema

Simple, intuitive relationships - every dimension links directly to the fact table, making the model easy to read, navigate and explain.
Simplifies DAX — Dimension and fact responsibilities are separated, making measure logic clear.
Easy to build reports - dragging fields from dimension tables onto a visual filters the fact table correctly with no extra configuration.
Highly scalable - Supports adding new dimensions without affecting existing structure

Disadvantages of Star Schema

Data Redundancy - Denormalized dimension tables repeat attribute values across multiple rows, which can increase storage needs.
Risk of Inconsistency - Duplicated data means that updating an attribute (like renaming a product category) may require changes in multiple rows, risking data quality issues if not done correctly.

Where it is appropriate
The star schema is the default, recommended structure for most business intelligence projects. It is particularly appropriate when:

Building standard reporting solutions such as sales analysis, financial reporting, or operational dashboards.
Dimension tables are moderate in size and don't require complex, multi-level hierarchies to be broken out separately.
Report performance and simplicity of DAX are priorities.

Implications for Power BI performance and complexity:
A star schema significantly boosts Power BI performance by allowing the VertiPaq engine to optimize data compression and accelerate query execution through direct relationship paths. Also the star schema minimizes data complexity by separating numeric facts from descriptive attributes, streamlining DAX calculations and simplifying the overall reporting model.

3. Snowflake Schema
A snowflake schema is an extension of the star schema in which one or more dimension tables are further broken down into related sub dimension tables, normalizing the data further and producing a shape that resembles a snowflake when viewed in Power BI's Model view.

In a snowflake schema, a dimension table that would normally sit as a single table in a star schema is split into two or more related sub dimension tables, each holding a narrower set of attributes. The lowest level dimension retains a direct relationship to the fact table, while the additional sub dimension tables branch outward from it in a chain, with each table connected to the next through its own primary and foreign key. This continues until the attributes have been separated into as many normalized levels as the hierarchy requires, resulting in a structure where the fact table sits at the centre, immediate dimensions surround it as in a star schema, and further related tables extend outward from those dimensions rather than connecting directly back to the fact table.

The screenshot shows the snowflake schema in Model view, with FactSales connected directly to DimProduct as in the star schema, but DimProduct_Snowflake now extending further to DimSubcategory and then to DimCategory, illustrating the extra normalization and relationship hops that distinguish a snowflake schema from a star schema.

Advantages of Snowflake schema
A snowflake schema reduces data redundancy further than a star schema, since repeated text values such as category names are stored once in their own table rather than repeated across every product row. It can also save storage space when a dimension table is very large and its higher level attributes repeat extensively.

Disadvantages of Snowflake schema
The additional tables mean more relationships and more relationship hops for filters to travel through, which increases model complexity. DAX measures can become harder to write and slower to evaluate when a filter has to pass through several linked dimension tables before reaching the fact table.

Where it is appropriate
A snowflake schema is appropriate when a dimension table is very large and highly repetitive at higher levels, when strict normalization is required for governance or auditing reasons, or when a dimension naturally has a deep, well-defined hierarchy that benefits from being modeled as separate levels, such as Category, Subcategory, and Product. It is generally used on specific dimensions rather than applied across an entire model.

Implications for Power BI performance and complexity
Because filters must pass through additional relationship hops before reaching the fact table, snowflake schemas are slower than star schemas and place more load on the DAX engine when aggregating across levels. Model complexity is also higher, since there are more tables and relationships to maintain, making the snowflake schema best reserved for specific dimensions that genuinely benefit from normalization rather than the whole model.

Relationships in Power BI
Relationships in Power BI refer to the logical connections between two or more tables based on a common column. These connections enable Power BI to combine data from multiple tables and perform calculations across them, just like joins in traditional databases.

Relationships are the core of any data model because star and snowflake schemas intentionally divide information into separate tables. Without these connections, the tables would stay completely isolated, preventing data from being filtered, combined, or analyzed together.

Every relationship in Power BI has a cardinality which describes how many matching rows can exist on each side of the relationship.
1. One-to-Many (1:*)
One record in the first table is related to multiple records in the second table.

For example, in our model, DimCustomer has one row per customer, while FactSales can contain many rows for the same customer, since a customer can place multiple orders. CustomerID is unique in DimCustomer, but repeats in FactSales wherever that customer appears again.

2. One-to-One (1:1)
Each row in the first table relates to exactly one row in the second table, and vice versa, meaning the key column is unique on both sides of the relationship.

3. Many to Many (:)
Rows in both tables can have multiple matching rows on the other side, meaning the key column is not unique in either table.

For example, a student can enroll in many courses and each course can have many students. Neither StudentID nor CourseID is unique on its own, since the same student appears against multiple courses and the same course appears against multiple students.

Primary Keys and Foreign Keys

A primary key is the column in a table that uniquely identifies each row, such as CustomerID in DimCustomer.
A foreign key is a column in another table that references that primary key, such as CustomerID appearing in FactSales. This is why CustomerID contains unique values in DimCustomer, appearing once per customer, but appears multiple times in FactSales as a foreign key, once for every order that customer places.

Unique Keys, Cardinality and Referential Integrity

Unique Keys For a relationship to work correctly in Power BI, the column on the “one” side must contain unique values. A unique key allows Power BI to establish a valid relationship between tables.
Cardinality Cardinality defines the type of relationship created between the tables based on how their key values correspond.
Referential integrity Referential integrity means that every foreign key in one table has a corresponding primary key in the related table. For instance, each CustomerID in FactSales should have a matching CustomerID in DimCustomer. If some foreign key values do not have matching records, Power BI may produce blank or unexpected results in reports.

Active and Inactive Relationships

Active and inactive relationships become important when tables can be connected through multiple relationship paths. Power BI permits only one active relationship between two tables at a time and this relationship is automatically used when applying filters and performing calculations. Other possible relationships are treated as inactive and must be specifically enabled within a DAX measure using functions such as USERELATIONSHIP.

For example, suppose the FactSales table contains both OrderDate and ShipDate, with each column connected to the DimDate table. Only one of these relationships can remain active at a time. The other relationship is inactive and can be temporarily activated in a measure when analysis needs to be based on the shipping date rather than the order date.

Filter Direction
Filter direction determines how filtering behaves once a relationship exists, specifically which table's filters are allowed to affect the other table.

Single-Direction Filtering
In single-direction filtering, filters flow only one way, typically from the "one" side of a relationship to the "many" side. This is the default and most common setting in Power BI. For example, if you select a product from a DimProduct slicer, Power BI filters the FactSales table so that it displays only sales related to that selected product. However, the filtering does not work in reverse, changes or selections in FactSales will not filter the DimProduct table.
Bi-Direction Filtering
In bidirectional filtering, filters flow both ways, meaning a selection in either table can affect the other. For example, if bidirectional filtering were enabled between DimProduct and FactSales, filtering FactSales down to a specific store location would also filter DimProduct, showing only the products that were sold at that location, in addition to the usual DimProduct-to-FactSales filtering. This is different from single-direction filtering, where FactSales selections have no effect on DimProduct at all.

Joins in Power Query
A join, in the context of Power Query, is a way of combining two tables based on a matching column between them, using the Merge Queries feature. Unlike a relationship in the data model, a merge in Power Query happens during data preparation, before the model is even loaded, and it produces a new, physically combined table rather than simply linking two existing ones.

Throughout this section, we'll use two sample tables:

Customers

CustomerID	CustomerName
1	Alice
2	Bob
3	Carol
4	David

Orders

OrderID	CustomerID	Amount
101	1	250
102	2	100
103	2	75
104	5	300

1. Left Outer Join

Returns all rows from the left (first) table, plus matching rows from the right (second) table. Where there's no match, the right table's columns are filled with null.
Every row from the left table, matched or not, is retained.

Example: Merge Customers (left) with Orders (right) on CustomerID

Expected Output:

CustomerID	CustomerName	OrderID	Amount
1	Alice	101	250
2	Bob	102	100
2	Bob	103	75
3	Carol	null	null
4	David	null	null

This is the default and most common join in Power Query — used when you want to enrich a primary table (e.g., Customers, Products) with related data without losing any of its original rows.

2. Right Outer Join

Returns all rows from the right (second) table, plus matching rows from the left table. Unmatched left-table columns are null.
Every row from the right table, matched or not, is retained.

Example: Merge Customers (left) with Orders (right) on CustomerID.

Expected Output:

CustomerID	CustomerName	OrderID	Amount
1	Alice	101	250
2	Bob	102	100
2	Bob	103	75
null	null	104	300

3. Full Outer Join

Returns all rows from both tables, matched where possible, with null filled in wherever a match doesn't exist on either side.
Every row from both tables is retained. Nothing is dropped.

Example: Merge Customers and Orders on CustomerID.

Expected Output:

CustomerID	CustomerName	OrderID	Amount
1	Alice	101	250
2	Bob	102	100
2	Bob	103	75
3	Carol	null	null
4	David	null	null
null	null	104	300

4. Inner Join

Returns only the rows where the key exists in both tables.
Only matched rows are retained. Anything unmatched on either side is dropped entirely.

Example: Merge Customers and Orders on CustomerID.

Expected Output:

CustomerID	CustomerName	OrderID	Amount
1	Alice	101	250
2	Bob	102	100
2	Bob	103	75

5. Left Anti Join

Returns only the rows from the left table that have NO match in the right table. It is the logical opposite of an Inner Join, restricted to the left side.

Left-table rows with no corresponding right-table match are retained. No columns from the right table are brought in (there's nothing to bring in, since by definition nothing matched).

Example: Merge Customers (left) with Orders (right) on CustomerID.

Expected Output:

CustomerID	CustomerName
3	Carol
4	David

6. Right Anti Join

Returns only the rows from the right table that have NO match in the left table.
Right-table rows with no corresponding left-table match are retained.

Example: Merge Customers (left) with Orders (right) on CustomerID.

Expected Output:

OrderID	CustomerID	Amount
104	5	300

Power Query Joins vs Power BI Relationships
A Power Query merge combines data by adding columns from one table to another before the data is loaded into Power BI, resulting in one combined table. In contrast, a Power BI relationship keeps the tables separate and defines how filters should move between them when queries and reports are processed.

A merge is useful when you need a combined table for export or when you want to permanently add a small number of lookup columns. A relationship is more suitable when the tables represent different entities that need to be analyzed independently in reports.

Recommended Power BI Model
For most business intelligence projects, a star schema is a strong choice. It typically consists of a central fact table, such as FactSales, linked to shared dimension tables such as DimCustomer, DimProduct, DimDate, and DimLocation. These tables are usually connected using one to many relationships, with filters flowing in a single direction from the dimension tables to the fact table.

Compared with a flat table, a star schema reduces the repetition of descriptive information across large numbers of fact records. This helps keep the model more compact and can improve refresh performance. It is also generally simpler than a snowflake schema because it reduces the number of relationships and filtering steps required by the model. This makes DAX calculations easier to write and the overall model easier to understand.

A star schema also provides several practical benefits. It supports consistent and efficient filtering, works well with common DAX and time based calculations, and gives report developers a clear structure that is easy to navigate. Since descriptive attributes are maintained in dimension tables rather than repeatedly stored in the fact table, unnecessary data duplication is reduced. The model can also grow more easily as the amount of business data increases, while changes to business information can usually be made in one central location.

Conclusion
In conclusion, effective Power BI modelling depends on choosing the appropriate schema, separating fact and dimension tables, and establishing well-designed relationships between them. A star schema is generally preferred because it reduces data duplication, improves query performance, simplifies DAX calculations and makes the model easier to understand and maintain. Using reliable keys and controlled filter directions also helps ensure accurate and predictable results, while Power Query merges should be reserved for situations where combining data during preparation is necessary. Overall, applying these principles creates a Power BI model that is efficient, scalable, easy to manage, and suitable for reliable business reporting and analysis.

Building an Interactive Excel Dashboard for E-commerce Product Analysis: A Case Study of Jumia Products

Clarence Gatama Chege — Sat, 05 Sep 2026 22:06:19 +0000

Introduction

In this project, I used a Jumia product dataset to demonstrate how Excel can be used to explore, prepare, and clean data then use the data for analysis to get insights.

A final workbook, available in this GitHub repo, is organized into separate sheets for the raw data, cleaned data, analysis, PivotTables, dashboard, and data dictionary. The original data is preserved in the Raw_Data sheet, while all cleaning activities are performed in the Cleaned_Data sheet.

Our initial raw dataset has 5 columns and 116 rows. The table below represents each column:

Source Field	Meaning	Expected Cleaned Type
Product	Product name	Text
Current Price	Current selling price in Kenyan shillings (KSh)	Number / Currency
Old Price	Price before discount in KSh	Number / Currency
Discount	Advertised percentage discount	Percentage
Review	Number of customer reviews	Whole Number
Ratingd	Average rating out of 5	Decimal Number

Initial Data-Quality Audit

Before cleaning, I reviewed the raw dataset to identify issues that would affect analysis. This is what I uncovered:

Column headers: one misspelled header (Ratingd).
Data types: Current Price and Old Price stored as text. Discount stored as plain text rather than a percentage.
Duplicates: 3 duplicate entries.
Missing values: columns Review and Ratingd. Here is a summary of missing values for each column using COUNTBLANK formula

Inconsistent formatting: Headers Current price and old price are written in different cases.

Data Cleaning

Before I dived into cleaning the dataset, I created a new sheet named cleaned-data and copied the dataset. This new sheet is where all the cleaning happened.
I also formatted my dataset header by adding a background and bolding the text and used Freeze Panes to ensure the header is always at the top even while scrolling for easier column identification.

1. Removing Duplicates
A record is considered a duplicate only when all of its column values are identical.

To remove duplicates, I selected a cell within the dataset and went to the Data tab. Under the Data Tools group, I selected Remove Duplicates. Excel displayed a dialog box listing all the columns in the dataset. I left all columns selected and clicked OK.

Excel found 3 duplicate rows and removed them.

2. Cleaning the Rating Column

Next I moved on to cleaning individual columns, starting with the Ratingd column. The first issue I noticed was that the column name was misspelled as Ratingd and I changed it to Rating.

The values in this column were also stored in a format such as 4.5 out of 5, it would be better if we had a numeric value for analysis for example 4.5. I used Find & Replace to remove the text out of 5 from the values, leaving only the numeric rating.

After removing the text out of 5, I changed the column type to Number and set the values to one decimal place.

Applying filtering on Rating column helped me identify missing values (blanks). Before deciding how to handle the missing values, I checked other columns to look for a pattern behind the blanks. I noted Review column also had blanks and all rows with a blank in Review column also had a blank in Rating column. This led me to the conclusion that the reason for the blanks in Rating column is because the products were not reviewed. I decided to replace the blanks with text Not Rated.

3. Cleaning the Review Column
While cleaning Rating column I identified that there are products that did not get reviewed and hence had blanks in rating. I replaced the blanks, in Review column with number 0. This shows that products with 0 reviews were Not Rated supporting Rating column cleaning decision.

I also noted that the rest of the values in Review column had negative values yet the column represents the number of customer reviews. I converted the values to positive numbers using the Absolute function Abs(value) using the following step:

Creating a new column with same name Review
On first row, set formula Abs(E2) E2 referencing the first value on original Review column.
Double-clicking the fill handle to apply the formula to all rows.
Copy the new Review column.
On the same column, I pasted the values
Delete the original Review column

3. Cleaning the Current Price & Old Price Column
Both columns Current Price and Old Price values are aligned to the left, meaning they are stored as text. To record them as numeric values I selected both columns and used Find & Replace to replace Ksh with blank. Most values immediately shifted and were aligned to the right.

A hack to identify any non-numeric values in a numeric column is sorting the columns from largest to smallest. Any present text values appear at the top. This helped me discover a product whose Old Price and Current Price were recorded as a range.

For the Old Price of the product, I used the middle value of the range which is 2,700. I then used the discount percentage provided in the dataset to calculate the corresponding Current Price which was 1,674.

After cleaning the data, I converted the cleaned range into an Excel Table using Ctrl + T. I confirmed that the table had headers and gave it the name tblProducts.

Excel Formulas and Enrichment Fields

After cleaning the individual columns, I used Excel formulas to create additional fields that provide more useful information for analysis. These derived fields are calculated from the existing columns rather than being directly provided in the original dataset.

New Field	Based On	Type	Categories
Price Category	Current Price	Text	Low Price, Middle Price & High Price
Discounted Amount	Current Price & Old Price	Number	Difference between Old Price and Current Price
Discount Category	Discount	Text	Low Discount, Middle Discount & High Discount
Rating Category	Rating	Text	Missing, Poor, Average & Excellent
Engagement	Review	Text	Missing, Strong Engagement & Normal Engagement

Derived Fields, Formulas and Thresholds

1. Price Category

Formula:

=IF([@[Current Price]]="","Missing",IF([@[Current Price]]<=Price_Q1,"Low Price",IF([@[Current Price]]<=Price_Q3,"Medium Price","High Price")))

Note that Price_Q1 and Price_Q3 are named cells representing Current Price Column First Quartile and Third Quartile respectively.

=QUARTILE.INC(tblProducts[Current Price],1)
=QUARTILE.INC(tblProducts[Current Price],3)

2. Discounted Amount

Formula:

=[@[Old Price]]-[@[Current Price]]

This calculates the difference between the original price and the current selling price.

3. Discount Category

Formula:

=IF([@Discount]="","Missing",IF([@Discount]<20%,"Low Discount",IF([@Discount]<=40%,"Medium Discount","High Discount")))

Thresholds:

Blank - Missing
Below 20% - Low Discount
20%–40% - Middle Discount
Above 40% - High Discount
4. Rating Category

Formula:

=IF([@Rating]="","Missing",IF([@Rating]<3,"Poor",IF([@Rating]<=4.5,"Average","Excellent")))

Thresholds:

Blank - Missing
Below 3 - Poor
3.1–4.4 - Average
4–5-5 - Excellent
5. Engagement

Formula:

=IF([@Review]="","Missing",IF([@Review]>=Review_Q3,"Strong Engagement","Normal Engagement"))

Note that Review_Q3 is a named cell representing the third quartile of the Review column. It is used as the threshold for identifying products with strong customer engagement.

The third quartile can be calculated using:

=QUARTILE.INC(tblProducts[Review],3)

Thresholds:

Blank - Missing
Review count below Review_Q3 - Normal Engagement
Review count greater than or equal to Review_Q3 - Strong Engagement

These thresholds provide a consistent way of grouping products and make it easier to compare them during the analysis stage.

Analysis and Pivot Tables

I used calculations, charts and Pivot Tables to summarize the cleaned data.
Below were my findings for descriptive analysis:

Here were my relationship analysis findings:

The Pivot Tables below represent product ranking analysis:

Top 5 Products by Rating
Bottom 5 Products by Rating
Top 10 Products by Discount
Top 10 Products by Reviews
Products with High Discounts but Low Rating
Products with many reviews but average ratings.

Dashboard Design and Slicer Connections

The final dashboard is a combination of key Pivot Tables and charts in a single view, with slicers connected to allow filtering by rating category, discount category, price category and engagement.

Key Finding

Higher discounts do not mean more customer engagement. Discount percentage and review count show essentially no correlation (r = -0.11).

Business Recommendations

Sellers should not rely on discount depth alone to drive customer interest — engagement appears to depend on other factors not captured by discount size.
High-review, low-rating products (e.g., the cordless vacuum cleaner) should be flagged for quality review, since visibility without satisfaction is a churn risk.
Encourage more customers to leave ratings and reviews since half of the products lacks both rating and reviews.

Limitations

Dataset size (116 rows) limits how confidently patterns can be generalized.
No units-sold or revenue field thus analysis lacks a sales indicator.
Nearly half of products are unrated, limiting the reliability of rating-based conclusions.

Conclusion

This project demonstrates how Excel can transform a messy real-world dataset through data cleaning, formulas, PivotTables, and an interactive dashboard. The analysis revealed that discounts, reviews, and ratings do not necessarily correlate, highlighting the importance of testing assumptions with data.

The full workbook, formulas, and dashboard are available in this GitHub repository

Excel for Data Analytics: Fundamentals & Data Cleaning

Clarence Gatama Chege — Sat, 29 Aug 2026 20:11:16 +0000

Microsoft Excel is one of the most important computer applications because of the key role it plays in many sectors. It is used in data entry, record keeping, project management, business intelligence and data analysis.

The data stored in Excel can sometimes be messy due to duplicate values, missing values, inconsistent text, incorrect data types for example having a text value in a column with numeric values etc, which can affect the accuracy of analysis. In data analytics, before the data can be analyzed, it needs to be cleaned and well structured.

In this article we will explore the basics of Excel and also practical data-cleaning techniques. We will use the Cafe Sales Dataset to demonstrate how to work with data in Excel and cleaning the data to prepare it for analysis.
Download the dataset from the link above.

Understanding The Dataset

Let us explore the dataset first before diving into cleaning. Exploring helps us understand what exactly we are working with.
The dataset has 8 columns in total and 10,000 rows of synthetic data representing sales transactions in a cafe.

Column Name	Data Type
Transaction ID	Text
Item	Text
Quantity	Numeric
Price Per Unit	Numeric
Total Spent	Numeric
Payment Method	Text
Location	Text
Transaction Date	Date

Below is a screenshot of the dataset when opened in Excel:

Working With Excel

Before we dive into cleaning let's look into some Excel fundamentals that will help us work with this dataset.

Adjusting the column width

You will note that when you open the dataset not all cell values are fully visible. Some values, for example values in column Transaction Date, are represented by # because the values are longer than the available column width. Adjusting the column width makes all values visible. Start by selecting all values in our dataset with CTRL + A. Then in the Home Tab, cell group, select Format and choose AutoFit Column Width.Excel automatically adjusts the width of each column based on the contents of the cells, making the values fully visible.

Formatting the Header

We can make our header row different from the other rows by making it bold, centering the text, and adding a background color. The header row is the row containing the column names. Select the first row with column names, in the Home tab under Font group click B. Alternatively you can use CTRL + B to apply the bold.
While still selecting the header row, in the Home tab under Alignment select Center.
We can also add a background color using the Fill Color option in the Font group. This is how the header row looks after formatting:

Adding Freeze Panes

As you scroll down the dataset you will note that you lose sight of the header row. This makes it hard to remember which column is which. That is where freeze pane comes in. What Freeze Panes does is that it ensures the header row is always at the top of the dataset.
To freeze our header row first select the whole dataset, then under Window group in View tab select Freeze Panes and choose Freeze Top Row. Now as you scroll down the dataset, the header row always remains at the top.

Also note that Freeze Panes can also be applied on the first column.

Sorting Data

Sorting means arranging data in a specific order. In Excel, text data can be sorted alphabetically, from A to Z or from Z to A and numeric data can be sorted from largest to smallest or from smallest to largest. Date data can also be sorted chronologically, from the earliest date to the latest date or vice versa.
For example in our dataset we can sort Price Per Unit column. To do this, select any cell in the Price Per Unit column, go to the Data tab, and select Sort Smallest to Largest icon in the Sort & Filter group. This will arrange the values from the lowest price to the highest price while keeping the other values in each row together.

Sorting makes it easier to examine the data and identify values that may require further investigation during the cleaning process.

Filtering

Filtering allows us to display only the records that meet specific conditions while temporarily hiding the other records.

For example, in our dataset, we can filter the Payment Method column to display only transactions where customers paid using Cash. To do this, select any cell in the dataset, go to the Data tab, and select Filter from the Sort & Filter group. A dropdown arrow will appear in each column header. Click the dropdown arrow in the Payment Method column, deselect Select All, select Cash, and click OK.

Excel will now display only the transactions where the payment method is Cash and the other records will be hidden.

Basic Formulas and Functions

Excel formulas and functions allow us to perform calculations and extract useful information from a dataset.

For example, we can calculate the total quantity of items sold in our dataset using the SUM function. Since the Quantity column contains the number of items purchased in each transaction, we can use the following formula:

=SUM(C2:C10001)

The AVERAGE function can be used to calculate the average quantity of items purchased per transaction:

=AVERAGE(C2:C10001)

Other useful functions when exploring a dataset include COUNT, MIN, and MAX. For example, COUNT can be used to determine the number of numeric values in a column, while MIN and MAX can help identify the smallest and largest values.

Data Cleaning

Having gone through some of Excel fundamentals, we can now move on to cleaning the dataset. Data cleaning is the process of identifying and correcting inaccurate, incomplete, inconsistent, or irrelevant data to improve the quality of a dataset.

Removing Duplicate Records

The first step in cleaning our dataset is to remove any duplicate records. In our dataset, a duplicate record would be a cafe sale that has the same value in all fields.

We can do this by selecting a cell in the dataset, then in the Data tab under the Data Tools group click Remove Duplicates. A dialog box appears showing all the columns in the dataset. Since we are looking for records that are identical across all fields, ensure all the columns are selected and click OK.

Our dataset does not have any duplicate rows.

Missing Values

To identify missing values, we will make use of Filter. Select any cell in the dataset, in the Home tab, under the Editing group, select the Sort&Filter dropdown and click Filter. You will see a filter dropdown appear in each column header. When clicked, this filter dropdown shows the unique values contained in that column. To identify missing values, we can look for the (Blanks) option in the list.

For example, we can check the Item column for missing values. Click the filter dropdown in the Item column. We can now see all the unique values in the column, (Blanks) included. This shows that there are missing values in the Item column.

To handle such missing values, we first check if we can determine the missing value from the other values in the row. Since we cannot do that, we will use Find & Replace to change them to Unknown. Select the Item column then press CTRL + H. A dialog appears. Leave the Find field empty and write Unknown in the Replace field then click Replace All.

A total of 333 missing values in the Item column were changed to Unknown

Correcting Data Types

Another important part of data cleaning is ensuring that each column contains the appropriate type of data. The data type determines how Excel interprets and works with the values.

For example in our dataset, Quantity, Price Per Unit, and Total Spent should contain numeric values because they represent quantities and monetary amounts. Transaction Date should contain date values, while columns such as Item, Payment Method, and Location contain text.

A good example of a column with data-type problems is in the Price Per Unit column. It should contain numeric values but we have identified it has values UNKNOWN and ERROR.

Perfect way of cleaning this is by using the Find & Replace we used earlier on. Find cells with UNKNOWN then replace with blanks. Do the same for ERROR.

The Quantity column also contains the text values UNKNOWN and ERROR, which can be replaced with blanks using the same approach.

Conclusion

In this article, we explored some of the Excel fundamentals that are useful when working with datasets, including adjusting column widths, formatting headers, freezing panes, sorting, filtering, and using basic formulas and functions.

We then applied these concepts to clean a cafe sales dataset containing 10,000 records. We removed duplicate records, identified missing values using filters, and handled missing and inconsistent values such as UNKNOWN and ERROR.

Data cleaning is an important step before performing analysis because the quality of the data directly affects the quality of the insights gotten.

Understanding the Git Workflow: From Local Folder to Remote Repository

Clarence Gatama Chege — Sat, 22 Aug 2026 19:50:08 +0000

For quite a while I have used Git without knowing what happens behind the scenes. I mastered using all commands from initializing, adding, committing to pushing code to Github but I couldn't explain what was happening to the files after each command. In this article we are going to cover what Git is, the git commands used when working in a Git repository and the four areas Git uses to track and manage your files.

Git and Github

Git and Github are not the same thing.
Git is a free, open source tool that helps you save and manage different versions of your files and code. Git sits silently in your project folder, keeping track of every change that happens.
Github on the other hand is a platform that hosts your project folders and repositories online. This way other people can access your code, collaborate with you or review your work.

Git Repository

A Git repository is a folder that Git lives in and tracks for changes, this includes, every addition, deletion, and edit made in that folder. To initialize a repository (to make Git track your folder), you use the command git init.

This is how it works. You have a folder article that has a file README.md and a folder first-article that you will be working on.Right now, this is just a standard folder on your computer. Git has no idea it exists.

Once you run git init, Git creates a hidden .git folder inside it. From this point on, your article folder serves as your Working Directory.

The Git Workflow

In Git, files move through four distinct workflow areas or stages. Lets look into each stage:

1. The Working Directory
This is the folder where Git has been initialized and where you make changes to your files, in our case the article folder. New or updated files cannot be tracked by Git until you stage and commit them. Using git status we can check the current state of your working directory. For example in our current working directory, git status shows we have a file README.md that is untracked meaning Git is aware of the file but it is not currently keeping a record of its changes.

2. Staging Area
To make Git track the different versions of our files we use the command git add. Git add takes a copy of your current files from your working directory to the staging area.
In our example, lets make changes to README.md file and also add a new text file in folder first-article. These changes will still be untracked until we use the git add command as in the image below.

To make git track this changes we use the git add command. In this case we can run either:
git add README.md first-article/ to add the two or we run git add . to add all the untracked files.

Now when we run git status we'll see that git can now track our files and can confirm that README.md & first-article/ have changes to be committed.

3. Local Repository
The git commit command takes the snapshot from your Staging Area and moves it into the hidden .git folder. The git commit command includes a message that describes what the commit is about
git commit -m "Commit message"
Running git commit packages your changes and outputs exactly what was saved. Running git status and seeing “nothing to commit, working tree clean” means the staging area is empty, and all your current changes have been committed and safely backed up.

4. Remote Repository
After committing, your changes are saved only in your local Git repository. Use the git push command to upload those commits to a remote repository, such as GitHub or Bitbucket, making them accessible to others.

Conclusion
In conclusion, understanding Git’s four tracking areas gives you a clearer picture of how your project files are managed. Instead of running commands without knowing what happens behind the scenes, you can now understand how your work moves from the Working Directory to the Staging Area, then to the Local Repository, and finally to the Remote Repository, giving you control over your project history and ensuring your work is safely backed up. One important advantage of Git is that you can access previous versions of your work. Overall, Git provides a reliable and organized way to manage, track, and protect your projects.

Building a shopping cart using React, Redux toolkit

Clarence Gatama Chege — Sun, 26 May 2024 12:59:55 +0000

In this article, we'll walk through the process of creating an simple e-commerce application with the Fake store API using React redux and react toolkit, with a focus on implementing a shopping cart. By the end of this tutorial, you will have a functional application with the following features:

A product listing page displaying products available for purchase.
The ability to add items to the shopping cart.
A shopping cart page where users can view, update quantity, and remove items from their cart.

Let's get started !!

Create React project using vite:

npm create vite@latest shopping-cart -- --template react
cd shopping-cart

We will create three components: Cart, Navbar, and Shop components.

3.We will use fakestore api to get products for our project. Below is our initial Shop.jsx:

import React, { useEffect, useState } from "react";
import axios from "axios";

const Shop = () => {
  const [products, setProducts] = useState([]);
  const getProducts = async () => {
    await axios
      .get("https://fakestoreapi.com/products")
      .then((res) => setProducts(res.data))
      .catch((err) => console.log(err));
  };
  useEffect(() => {
    getProducts();
  }, []);
  return (
    <section className="shop">
      {products.map((product) => (
        <article className="card" key={product.id}>
          <img src={product.image} alt="" />
          <div className="details-div">
            <div className="title-price">
              <p>{product.title}</p>
              <p>{product.price}</p>
            </div>
            <button>Add to cart</button>
          </div>
        </article>
      ))}
    </section>
  );
};

export default Shop;

We now have the products set up so we'll dive into redux toolkit.

Redux Toolkit
Redux toolkit is a library that helps us write redux logic. It offers tools that simplify Redux setup and use, reducing boilerplate and enhancing code maintainability.

Redux Store
A redux store is a central repository that stores all the states of an application. Store is made up of slices.
To create our own store we need to install redux toolkit and react redux:

npm install @reduxjs/toolkit react-redux

Create a store.js file inside redux folder inside src folder.

In store.js we will create a redux store (store) using configureStore provided by reduxjs and export it.

import { configureStore } from "@reduxjs/toolkit";

export const store = configureStore({
  reducer: {},
});

To make the store accessible to our application, we need to wrap our App component inside Provider that allows a prop called store which we will set to our store. This is done inside our main.jsx (could be index.js if you created app using CRA)
Provider is a component that allows Redux store to be made available to all components.

Here is how our main.jsx looks like:

import React from "react";
import ReactDOM from "react-dom/client";
import App from "./App.jsx";
import "./index.css";
import { store } from "./redux/store.js";
import { Provider } from "react-redux";

ReactDOM.createRoot(document.getElementById("root")).render(
  <React.StrictMode>
    <Provider store={store}>
      <App />
    </Provider>
  </React.StrictMode>
);

Redux Slice
A slice is a part of the app's state that is managed by a specific reducer and contains actions related to the state.
For our project we'll create productsSlice.js file where we'll use createSlice function to create productsSlice.
createSlice accepts an object with the following parameters:

name -defines the slice's name.
initialState -sets up the starting state for the slice when the Redux store is first created.
reducers - these are functions that handle the logic for updating the state. We will create our first reducer addProductToCart. We will also export actions and reducer created by our createSlice.

import { createSlice } from "@reduxjs/toolkit";

const initialState = {
  products: [],
  cart: [],
};

const productsSlice = createSlice({
  name: "product",
  initialState,
  reducers: {
    addProductToCart: (state, action) => {
      state.cart.push(action.payload);
    },
  },
});

export const { addProductToCart } = productsSlice.actions;

export default productsSlice.reducer;

For our productsSlice to be available to the app, we will import reducer created by createSlice inside Store.js and add it to the reducer object of our store.

Here's how our store.js will be:

import { configureStore } from "@reduxjs/toolkit";
import productReducer from "./productsSlice";

export const store = configureStore({
  reducer: {
    products: productReducer,
  },
});

To be able to add a product to cart we will use two react-redux hooks:useSelector and*useDispatch*
useSelector allows components to get(select) part of the state that is required. useDispatch allows components to dispatch actions to the redux store.
Inside Shop.jsx we will import useDispatch from react-redux, invoke it and store in a variable dispatch. Variable dispatch will then be used to dispatch action addProductToCart when button 'Add to cart' is clicked.

Here's our Shop.jsx:

import React, { useEffect, useState } from "react";
import axios from "axios";
import { useDispatch } from "react-redux";
import { addProductToCart } from "../redux/productsSlice";

const Shop = () => {
  const [products, setProducts] = useState([]);
  const dispatch = useDispatch();
  const getProducts = async () => {
    await axios
      .get("https://fakestoreapi.com/products")
      .then((res) => setProducts(res.data))
      .catch((err) => console.log(err));
  };
  useEffect(() => {
    getProducts();
  }, []);
  return (
    <section className="shop">
      {products.map((product) => (
        <article className="card" key={product.id}>
          <img src={product.image} alt="" />
          <div className="details-div">
            <div className="title-price">
              <p>{product.title}</p>
              <p>{product.price}</p>
            </div>
            <button
              onClick={() =>
                dispatch(
                  addProductToCart({
                    id: product.id,
                    title: product.title,
                    price: product.price,
                    image: product.image,
                  })
                )
              }
            >
              Add to cart
            </button>
          </div>
        </article>
      ))}
    </section>
  );
};

export default Shop;

Now that the action is dispatched, the products are successfully added to cart which is part of the state. To display the added products, we will use useSelector inside Cart.jsx to get/extract/select cart which is part of our productsSlice.

Here's our Cart.jsx:

import React from "react";
import { useSelector } from "react-redux";

const Cart = () => {
  const cart = useSelector((state) => state.products.cart);
  console.log(cart);
  return (
    <section className="cart-component">
      {cart.map((product) => (
        <article className="cart-card" key={product.id}>
          <div>
            <img src={product.image} alt="" />
            <button>REMOVE</button>
          </div>
          <div>
            <p>{product.title}</p>
            <div className="button-in-cart">
              <button>-</button>
              <span>{product.quantity}</span>
              <button>+</button>
            </div>
            <p>$:{product.price}</p>
          </div>
        </article>
      ))}
      ;
    </section>
  );
};

export default Cart;

To display the count of products in our navbar, we will also get cart using useSelector inside Navbar.jsx. Cart being an array, we will use its length to get the count of products added to cart.

Here's our Navbar.jsx:

import React from "react";
import { useSelector } from "react-redux";

const Cart = () => {
  const cart = useSelector((state) => state.products.cart);
  console.log(cart);
  return (
    <section className="cart-component">
      {cart.map((product) => (
        <article className="cart-card" key={product.id}>
          <div>
            <img src={product.image} alt="" />
            <button>REMOVE</button>
          </div>
          <div>
            <p>{product.title}</p>
            <div className="button-in-cart">
              <button>-</button>
              <span>{product.quantity}</span>
              <button>+</button>
            </div>
            <p>$:{product.price}</p>
          </div>
        </article>
      ))}
      ;
    </section>
  );
};

export default Cart;

Using redux we have been able to create a store (source of truth 😅) allowing different components to access the state. In the next part we will ensure that when a similar product is clicked a number of times , it's not added to cart as multiple cart products by adding a quantity property. We will also add other actions such as increase quantity of product, decrease quantity of product, remove product and clear cart.

Source code:

ClarenceG01 / shopping-cart-redux

React + Vite

This template provides a minimal setup to get React working in Vite with HMR and some ESLint rules.

Currently, two official plugins are available:

@vitejs/plugin-react uses Babel for Fast Refresh
@vitejs/plugin-react-swc uses SWC for Fast Refresh

View on GitHub