DEV Community: Dubaguntla Charan Sai

Building a Trip Planner with Vanilla JS and JSON: How I Structured Travel Sync's Data

Dubaguntla Charan Sai — Sun, 23 Aug 2026 12:48:59 +0000

Not every project needs a database and a backend framework. When I built Travel Sync, a trip planning and itinerary management web app, I used plain HTML, CSS, and JavaScript with JSON for data — no backend, no build tools. Here's how I structured the data so the app stayed manageable as features grew, and what I'd suggest if you're building something similar.

The Stack

Frontend: HTML, CSS, JavaScript (no framework)
Data: JSON, structured and persisted client-side
Deployment: Render, with version control on GitHub

Step 1: Model Your Data Before Writing UI Code

The core challenge in a trip planner is nesting: a trip has multiple destinations, each destination has multiple days, and each day has multiple activities. It's tempting to just start building forms and figure out storage later — don't. I started by writing out the shape of the data first:

{
  "tripId": "t1",
  "tripName": "Goa Weekend",
  "destinations": [
    {
      "name": "Goa",
      "days": [
        {
          "date": "2026-09-12",
          "activities": [
            { "time": "09:00", "title": "Beach visit", "notes": "Bring sunscreen" }
          ]
        }
      ]
    }
  ]
}

Lesson: once you know the nesting, the UI components almost design themselves — a trip list, a destination view, a day view, an activity list. Data shape drives component shape.

Step 2: Keep One Source of Truth

Early versions of Travel Sync had trip data scattered across multiple JS variables that got out of sync — editing an activity in one place didn't update the summary view elsewhere. The fix was boring but important: one JSON object in memory as the single source of truth, with every UI update reading from and writing back to it.

let tripData = loadTripsFromStorage();

function updateActivity(tripId, dayIndex, activityIndex, newActivity) {
  const trip = tripData.find(t => t.tripId === tripId);
  trip.destinations[0].days[dayIndex].activities[activityIndex] = newActivity;
  saveTripsToStorage(tripData);
  renderTrip(tripId);
}

Lesson: in any app without a backend, decide early where the "truth" lives, and make every function read/write through it instead of touching the DOM directly.

Step 3: Re-render Instead of Patching the DOM by Hand

Without a framework, it's tempting to manually update individual DOM elements when data changes. This gets unmanageable fast once you have nested lists (trips → destinations → days → activities). Instead, I rendered each section from the current data state every time something changed:

function renderTrip(tripId) {
  const trip = tripData.find(t => t.tripId === tripId);
  const container = document.getElementById("trip-view");
  container.innerHTML = trip.destinations
    .map(d => renderDestination(d))
    .join("");
}

It's less "efficient" than surgical DOM updates, but for an app this size, it's far easier to reason about — the UI always matches the data because it's rebuilt from the data.

Lesson: for small-to-medium apps, "re-render the whole section from data" beats hand-patching the DOM. Optimize only if you actually hit a performance problem.

Step 4: Design Mobile-First from the Start

Since people plan trips on their phones as much as on desktops, I built the layout mobile-first — single-column day views, collapsible destination sections — then expanded the CSS for larger screens rather than the reverse. Retrofitting mobile support onto a desktop-first layout is almost always more painful than starting mobile-first.

What I'd Tell Someone Starting This Today

Model your nested data structure before writing any UI.
Keep a single source of truth and update everything through it.
Re-render from data instead of manually patching the DOM.
Build mobile-first, especially for anything travel-related.

You don't need a framework or a backend to build something real — you just need a clear data model and some discipline about where state lives.

Travel Sync is a trip planning and itinerary management web app built with HTML, CSS, JavaScript, and JSON. Live demo here.

Connecting a React Dashboard to a Spring Boot Backend: Lessons from Building CropCare AI

Dubaguntla Charan Sai — Sun, 23 Aug 2026 12:44:27 +0000

When I set out to build CropCare — a full-stack platform that helps farmers detect crop diseases and get support — the hardest part wasn't the AI or the database. It was something a lot of tutorials skip over: getting a React dashboard to reliably talk to a Spring Boot backend and render live, changing data without breaking.

If you're building your first full-stack app and want your frontend and backend to actually work together smoothly, here's what I learned — and how you can set yours up the same way.

The Stack

Backend: Java, Spring Boot, MySQL, REST APIs, JWT authentication
Frontend: React.js
Goal: Dashboards showing bar charts, pie charts, and analytics reports that update based on real backend data — not hardcoded values

Step 1: Design Your API Before Your UI

The first mistake I almost made was designing the dashboard UI first and figuring out the data later. That's backwards. Before writing a single React component, I mapped out exactly what data each chart needed:

Disease detection counts by crop type → needed a GET /api/reports/disease-summary endpoint
Support ticket status breakdown → needed GET /api/tickets/status-summary

Each endpoint returned a clean, predictable JSON shape — no nested surprises the frontend would have to untangle.

Lesson: decide your JSON shape first. It saves you from rewriting chart logic later.

@GetMapping("/api/reports/disease-summary")
public ResponseEntity<List<DiseaseSummaryDTO>> getDiseaseSummary() {
    return ResponseEntity.ok(reportService.getDiseaseSummary());
}

Step 2: Secure the Endpoints Without Blocking Yourself

Since CropCare uses JWT authentication with role-based access, every dashboard call needed a valid token attached.

Early on, I kept getting silent failures — the dashboard would just show blank charts with no error.

The fix was to centralize the API calls through a single Axios instance that automatically attaches the token and handles 401s consistently:

const api = axios.create({ baseURL: "/api" });

api.interceptors.request.use((config) => {
  const token = localStorage.getItem("token");

  if (token) {
    config.headers.Authorization = `Bearer ${token}`;
  }

  return config;
});

Lesson: don't attach auth headers manually in every component. Centralize it once, or you'll spend hours debugging "blank chart" bugs that are actually silent 401 errors.

Step 3: Keep the Frontend Dumb, the Backend Smart

My first version tried to do data aggregation — counting diseases per crop type and calculating percentages — inside React.

It worked, but it was messy and slow to change.

I moved that logic to the backend instead. The API returns data already shaped for the chart library, and React just renders it:

[
  {
    "cropType": "Wheat",
    "diseaseCount": 12
  },
  {
    "cropType": "Rice",
    "diseaseCount": 7
  }
]

Lesson: if your frontend is doing math or aggregation, ask whether that logic belongs on the server instead. It usually does.

Step 4: Handle the Loading/Empty/Error States Explicitly

The dashboards felt broken during demos until I added three explicit UI states for every chart:

Loading — skeleton or spinner
Empty — no data yet, with a friendly message instead of a blank chart
Error — something went wrong, with a retry button instead of a silent failure

if (loading) return <Spinner />;

if (error) {
  return <ErrorMessage onRetry={fetchData} />;
}

if (!data.length) {
  return <EmptyState message="No disease reports yet." />;
}

return <BarChart data={data} />;

This one change made the dashboards feel production-ready instead of like a student project.

What I'd Tell Someone Starting This Today

If you're building something similar:

Design your API response shape before touching the frontend.
Centralize auth handling — don't repeat it per component.
Push aggregation logic to the backend.
Always design for loading, empty, and error states, not just the "happy path."

None of this is complicated once you know it — but I didn't know it until I'd rebuilt the CropCare dashboards twice.

Hopefully this saves you a round trip.

CropCare is a full-stack crop disease detection and farmer support platform built with Java, Spring Boot, React.js, and MySQL.

Live demo