lintaojlu/submarine_cable_information

1. This repository is a single RedwoodJS web application, not a full client/server app. The architecture is dominated by a static data-driven frontend that renders TeleGeography’s submarine cable map from files in web/public.

2. The primary “data layer” is the web/public/api/v3 tree. It contains prebuilt JSON resources for cables, landing points, countries, suppliers, statuses, ready-for-service years, and search/config metadata. These files are served as static assets from the same origin and are the app’s effective backend.

3. Two GeoJSON datasets are the core map inputs:

- web/public/api/v3/cable/cable-geo.json for cable routes

- web/public/api/v3/landing-point/landing-point-geo.json for landing stations

The README explains these were exported from Illustrator/MAPublisher, so the runtime app consumes curated geography rather than querying a live spatial service.

4. web/src/modules/SubmarineCableMap is the main visualization subsystem. It is the map engine that likely loads the GeoJSON, draws routes and landing points, and reacts to filters/selections. ZoomControl is a supporting map-specific UI component.

5. Application routing is centered in web/src/Routes.js and web/src/App.js. The app is organized into page-level views for the major lookup dimensions: HomePage, SubmarineCablePage, LandingPointPage, CountryPage, SupplierPage, StatusPage, ReadyForServicePage, MultiselectPage, plus error handling pages.

6. Shared state is split into three React contexts:

- MapContext for map viewport/interaction state

- ResultsContext for selected results and filtering/output state

- SearchContext for search and multi-select query state

These contexts are the main in-app data flow mechanism connecting the map, search, and result panels.

7. The “results/search” experience is a second major subsystem beside the map. Components like Search, Multiselect, SelectionList, ResultsHeader, LandingPointList, SubmarineCableList, SupplierList, and SelectAnotherCable work together to let users filter the dataset and browse entity lists.

8. Presentation is layered through reusable layouts:

- AppLayout provides the general shell

- ResultsLayout is used for filtered/detail-result views

Shared chrome components such as Header, Navigation, Share, Sponsors, About, and LastUpdated sit around the main content and make the app feel like a content product rather than a generic dashboard.

9. The repository is content-heavy and largely static at runtime. Individual entity pages almost certainly render from the JSON documents under web/public/api/v3/*, rather than calling external APIs. That means the main data flow is: static JSON → page/context state → map and lists.

10. The search.json and the directory-based entity JSON files imply client-side lookup/indexing. In architecture terms, search is not a remote service; it is a static dataset that the frontend can read and transform locally.

11. Styling/build tooling is standard RedwoodJS frontend infrastructure: Babel, Webpack, PostCSS, Tailwind, Jest, Prettier, and Redwood configuration files. These affect how the app is built and tested, but they do not add extra runtime services.

12. From a diagram perspective, the key boundary is between the static public data package and the interactive React app. Everything user-facing flows from those JSON assets into the route/page layer, through contexts, and into the map, lists, and detail views.