Data Flow

Relevant source files

The following files were used as context for generating this wiki page:

• stackbit.config.ts
• server.js
• about.html
• properties.html
• contact.html
• js/script.js
• css/custom.css
• 404.html
• package.json

The data flow in the Vandore Website project is characterized by a static site generation architecture, where content is managed in structured JSON files and compiled into static HTML pages. A lightweight Node.js server is responsible for serving these static assets. The client-side enhances user experience with dynamic data interactions, such as filtering and form submissions.

This document outlines the entire data lifecycle, from content modeling and storage, through the build-time site generation process, to server-side file serving and client-side data manipulation.

Content Modeling and Storage

The core of the website's content is defined by data models configured in Stackbit. These models dictate the structure of the content, which is stored in JSON files within the content/ directory. Two primary models, Page and Property, are defined.

Sources: stackbit.config.ts:10-130

Data Models

The content structure is organized into two main types: Page for general site pages and Property for real estate listings.

The relationship between these models is that a Page can contain a list of properties.

Sources: stackbit.config.ts:14-130

Page Model

The Page model is a generic type for creating standard website pages like "About Us" or "Contact". It is stored in content/pages/{slug}.json.

Field	Type	Description
title	string	The page title, used in the <title> tag.
heroHeading	string	The main heading in the hero section.
heroSubheading	text	The subheading text in the hero section.
sections	list	A list of generic content sections, each with a heading and text.
properties	list	A list of property cards to be displayed on the page.
team	list	A list of team members with their name, role, bio, and image.
faqs	list	A list of frequently asked questions, each with a question and answer.
blogPosts	list	A list of blog post summaries.

Sources: stackbit.config.ts:16-98

Property Model

The Property model is a data-only type used for individual real estate listings. It is stored in content/properties/{slug}.json.

Field	Type	Description
title	string	The title of the property.
price	string	The asking price.
address	string	The property's address.
description	text	A detailed description of the property.
image	string	URL or path to the property's main image.
url	string	The URL for the property's detail page.
bedrooms	number	Number of bedrooms.
bathrooms	number	Number of bathrooms.
area	number	The total area of the property.
floors	number	The number of floors.

Sources: stackbit.config.ts:101-118

Build-Time Data Integration

The stackbit.config.ts file defines a siteMap function that maps the JSON content documents to the final static HTML files. This process runs at build time, generating the website's structure.

The data-sb-object-id attribute is embedded in the root <html> tag of each generated page, linking it back to its source JSON file. This allows the Stackbit visual editor to identify and manage the content for a given page. For example, about.html is linked to content/pages/about.json.

Sources: stackbit.config.ts:133-157, about.html:1

The following diagram illustrates the site mapping logic:

Sources: stackbit.config.ts:133-157

Server-Side Data Flow

The project uses a simple Node.js HTTP server to serve the generated static files. The server is started by running node server.js, as defined in the start script of package.json.

The server listens for incoming requests and performs the following steps:

1. Constructs a local file path from the request URL. The root URL / defaults to /index.html.
2. Determines the file's MIME type based on its extension.
3. Reads the file from the filesystem.
4. If the file is found, it sends the content with a 200 OK status and the correct Content-Type header.
5. If the file is not found (ENOENT error), it attempts to read and serve 404.html with a 404 Not Found status. If 404.html itself is missing, a generic 404 message is returned.

Sources: server.js, package.json:6, 404.html

This sequence diagram shows a user requesting an HTML page from the server.

Sources: server.js:28-52

Client-Side Data Interaction

The frontend uses JavaScript to create dynamic user experiences by manipulating data directly in the browser.

Property Filtering

The properties.html page features a filtering system that allows users to narrow down property listings without reloading the page. The filtering logic relies on data- attributes attached to each property card in the HTML.

• Filter UI: A filter bar allows filtering by location (text input), price range (min/max inputs), and number of bedrooms (buttons).
• Data Attributes: Each property element in the grid has attributes like data-location, data-price, and data-bedrooms.
• Filtering Logic: A client-side script (indicated by the inclusion of js/custom.js) reads the filter values and toggles the visibility of property cards based on whether their data- attributes match the selected criteria.
• UI Feedback: An #empty-state element is shown if no properties match the filters. Active filters are displayed as "chips".

Sources: properties.html:215-399, css/custom.css:3-30, 70-78

<!-- Example property item with data attributes for filtering -->
<div class="col mb-4" data-location="riga heritage lane" data-price="950000" data-bedrooms="4">
    <div class="card h-100">
        <!-- ... card content ... -->
    </div>
</div>

Source: properties.html:314-337

UI Tab Switching

A generic tab-switching functionality is implemented in js/script.js. This is used in components like the "Meet the team" section on the about.html page.

• A click event listener is attached to elements with the .tab class.
• When a tab is clicked, its data-tab attribute is read.
• The script finds the corresponding content element (e.g., #team-1) and adds the active class to display it, while removing the active class from other tabs and content panels.

Sources: js/script.js:18-28, about.html:271-325

Contact Form Submission

The contact.html page includes a form for users to send messages.

• The form uses standard HTML5 and Bootstrap validation (needs-validation).
• A script, js/submit-form.js, is included to handle the form submission process, likely via an AJAX request to prevent a full page reload.
• The HTML contains pre-styled "toast" notification elements (.success_msg, .error_msg) to provide feedback to the user after a submission attempt.

Sources: contact.html:215-263

The following diagram shows the expected flow for a contact form submission.

Sources: contact.html:215-263, about.html:437 (for script inclusion)

Summary

The data flow of the Vandore Heritage website is a well-defined process that leverages static site generation for performance and reliability, while incorporating client-side JavaScript to provide dynamic interactions. Content is decoupled from presentation, stored in structured JSON files, and processed by Stackbit at build time to generate a full set of static HTML pages. A minimal Node.js server handles the simple task of serving these files, and the frontend is enhanced with features like real-time filtering and AJAX form submissions, creating a modern and efficient user experience.