This content originally appeared on DEV Community and was authored by ri ki
Today’s Work: Refining Seasonal Logic and Purchase Structure
Today I focused on rebuilding the logic that changes content based on the current date.
Instead of patching the old version, I decided to revisit the core structure and start clean.
I began by clarifying three essential elements:
- Seasons
- Product types
- Purchase types
Should Campaigns Be Mentioned?
One major question was whether to include seasonal campaign mentions in the display logic.
Pros:
- Clearly boosts user motivation to purchase
- Highlights limited-time offers and urgency
Cons:
- Campaign periods are often pretty short
- Timing depends on unpredictable factors like harvest volume
- There’s a risk of displaying outdated or misleading info
Given those risks, I decided to hold off on campaign mentions for now.
The structure will allow for it in the future, if it’s deemed safe and clear enough to present.
New Structure for Purchase Methods
I restructured the purchasing options into three clear types:
- Immediate Shipment
- Scheduled Delivery
- Subscription (Regular Delivery)
This clarity also helped reshape the season-detector, season-config, and seasonal-contents files for better maintainability and flexibility.
Shared Components and Reusability
To reduce duplication and inconsistencies, I created a shared button.tsx file for use across components.
I also built a shared ec-sites.tsx component, since at least two different sections now display the same external e-commerce information.
This will help maintain consistency across the landing page and detail sections.
Content Explosion and File Organization
As the information displayed in the purchase section grew, I decided to split it into multiple files for better clarity and separation of concerns.
This will also help future contributors (or future me) understand and modify each part more easily.
Tomorrow’s Plan
I’ll continue refining the structure of the purchase section.
The goal is to balance flexibility and clarity while ensuring the user sees the right message at the right time, depending on both season and purchase method.
Each rebuild feels like a small step backward, but ultimately it allows for cleaner, more scalable progress forward.
tags: portfolio, frontend, nextjs, typescript, ux
This content originally appeared on DEV Community and was authored by ri ki