When I first started building small JavaScript applications, I thought the main challenge was writing the JavaScript.
I later realized the harder part was understanding what happens to the data while the user interacts with the application.
A user enters information.
JavaScript reads it.
The application stores it.
The data changes.
The interface needs to reflect that change.
This is where the idea of state becomes important.
What is state?
In a web application, state is the data the application needs to remember while it is running.
For example, suppose I am building a simple farm expense tracker.
I might start with an empty array:
const expenses = [];
At this point, the application has no recorded expenses.
If the user enters:
Seeds
₦5000
JavaScript might turn that information into an object:
const expense = {
category: "Seeds",
amount: 5000
};
The object is then added to the array:
expenses.push(expense);
The state has changed.
It is now:
[
{
category: "Seeds",
amount: 5000
}
]
That array represents information the application needs to remember.
State is not the interface
This distinction has helped me understand JavaScript applications better.
The array is the data.
The HTML elements displayed on the page are the interface.
They are related, but they are not the same thing.
For example:
const expenses = [
{
category: "Seeds",
amount: 5000
}
];
does not automatically put anything on the screen.
The browser needs JavaScript to take the current state and update the DOM.
For example:
const expenseList = document.querySelector("#expense-list");
expenseList.innerHTML = "";
expenses.forEach(expense => {
const item = document.createElement("li");
item.textContent = ${expense.category}: ₦${expense.amount};
expenseList.appendChild(item);
});
The JavaScript reads the state and creates the corresponding interface.
The basic flow
The pattern I am learning to recognize is:
User action
↓
JavaScript handles the event
↓
Read input
↓
Update state
↓
Render the state
↓
UI reflects the new state
For example, when a farmer clicks an “Add Expense” button:
Click
↓
Read form values
↓
Create expense object
↓
Add object to expenses array
↓
Render expenses
↓
Updated expense appears on screen
This way of thinking is more useful to me than thinking about each line of JavaScript in isolation.
Why rendering matters
Suppose I update the array:
expenses.push(expense);
but do not update the interface.
The data has changed, but the user will not see the new expense.
This is an important distinction.
Changing the data does not automatically mean changing the DOM.
I need to explicitly render the updated state.
A simple render function might look like this:
function renderExpenses() {
expenseList.innerHTML = "";
expenses.forEach(expense => {
const item = document.createElement("li");
item.textContent = `${expense.category}: ₦${expense.amount}`;
expenseList.appendChild(item);
});
}
Then after changing the state:
expenses.push(expense);
renderExpenses();
The sequence becomes easier to follow.
First, change the data.
Then, update the interface.
Where localStorage fits
There is another part of the process when the application needs to remember data after the browser is refreshed.
An in-memory array disappears when the page is reloaded.
For example:
const expenses = [];
starts again as an empty array when the application loads.
localStorage gives the application a way to persist the data in the browser.
A simplified example:
localStorage.setItem(
"expenses",
JSON.stringify(expenses)
);
When the application starts again, the stored data can be retrieved:
const savedExpenses = localStorage.getItem("expenses");
const expenses = savedExpenses
? JSON.parse(savedExpenses)
: [];
Now the application has another part of the flow:
User action
↓
Update state
↓
Save state
↓
Render state
And when the application loads:
Load saved data
↓
Create current state
↓
Render state
What I am starting to understand
Building small applications has changed how I think about JavaScript.
Instead of asking:
“Which JavaScript method do I need?”
I am starting to ask:
“What data does the application need to remember?”
“What event changes that data?”
“How should the interface represent the current data?”
“Does the data need to survive a page refresh?”
These questions lead to better implementation decisions.
I am still building with vanilla HTML, CSS, and JavaScript, but I am beginning to see the structure behind interactive web applications.
The syntax is important.
Understanding the flow of data is equally important.
That is the part I am focusing on now.
Top comments (0)