Remove PROD_SHARE_DOMAIN constant and unify domain configuration

- Remove hard-coded PROD_SHARE_DOMAIN from src/constants/app.ts
- Update all sharing functionality to use environment-specific APP_SERVER
- Rewrite domain configuration documentation to reflect unified approach
- Simplify domain management with single APP_SERVER constant
- Update README.md examples to use APP_SERVER for all URL generation

This change eliminates the complexity of separate constants for different
URL types and provides consistent environment-specific configuration for
all functionality including sharing.
This commit is contained in:
Matthew Raymer
2025-08-04 03:52:21 +00:00
parent 06f3a4c7c2
commit aed16ebe94
3 changed files with 70 additions and 83 deletions

View File

@@ -2,33 +2,30 @@
**Author**: Matthew Raymer
**Date**: 2025-01-27
**Status**: ✅ **COMPLETE** - Domain configuration system implemented
**Status**: ✅ **UPDATED** - Simplified to use APP_SERVER for all functionality
## Overview
TimeSafari uses a centralized domain configuration system to ensure consistent
URL generation across all environments. This system prevents localhost URLs from
appearing in shared links during development and provides a single point of
control for domain changes.
URL generation across all environments. This system provides a single point of
control for domain changes and uses environment-specific configuration for all
functionality including sharing.
## Problem Solved
### Issue: Localhost URLs in Shared Links
### Issue: Inconsistent Domain Usage
Previously, copy link buttons and deep link generation used the environment-
specific `APP_SERVER` constant, which resulted in:
Previously, the system used separate constants for different types of URLs:
- **Development**: `http://localhost:8080/deep-link/claim/123`
- **Test**: `https://test.timesafari.app/deep-link/claim/123`
- **Production**: `https://timesafari.app/deep-link/claim/123`
- **Internal Operations**: Used `APP_SERVER` (environment-specific)
- **Sharing**: Used separate constants (removed)
This caused problems when users in development mode shared links, as the
localhost URLs wouldn't work for other users.
This created complexity and confusion about when to use which constant.
### Solution: Production Domain for Sharing
### Solution: Unified Domain Configuration
All sharing functionality now uses the `PROD_SHARE_DOMAIN` constant, which
always points to the production domain regardless of the current environment.
All functionality now uses the `APP_SERVER` constant, which provides
environment-specific URLs that can be configured per environment.
## Implementation
@@ -43,27 +40,28 @@ export enum AppString {
// ... other constants ...
}
// Production domain for sharing links (always use production URL for sharing)
export const PROD_SHARE_DOMAIN = AppString.PROD_PUSH_SERVER;
// Environment-specific server URL for all functionality
export const APP_SERVER =
import.meta.env.VITE_APP_SERVER || "https://timesafari.app";
```
### Usage Pattern
All components that generate shareable links follow this pattern:
All components that generate URLs follow this pattern:
```typescript
import { PROD_SHARE_DOMAIN } from "@/constants/app";
import { APP_SERVER } from "@/constants/app";
// In component class
PROD_SHARE_DOMAIN = PROD_SHARE_DOMAIN;
APP_SERVER = APP_SERVER;
// In methods
const deepLink = `${PROD_SHARE_DOMAIN}/deep-link/claim/${claimId}`;
const deepLink = `${APP_SERVER}/deep-link/claim/${claimId}`;
```
### Components Updated
The following components and services were updated to use `PROD_SHARE_DOMAIN`:
The following components and services use `APP_SERVER`:
#### Views
- `ClaimView.vue` - Claim and certificate links
@@ -82,17 +80,28 @@ The following components and services were updated to use `PROD_SHARE_DOMAIN`:
## Configuration Management
### Changing the Production Domain
### Environment-Specific Configuration
To change the production domain for all sharing functionality:
The system uses environment variables to configure domains:
1. **Update the constant** in `src/constants/app.ts`:
```typescript
export enum AppString {
// ... other constants ...
PROD_PUSH_SERVER = "https://your-new-domain.com",
// ... other constants ...
}
```bash
# Development
VITE_APP_SERVER=http://localhost:8080
# Test
VITE_APP_SERVER=https://test.timesafari.app
# Production
VITE_APP_SERVER=https://timesafari.app
```
### Changing the Domain
To change the domain for all functionality:
1. **Update environment variables** for the target environment:
```bash
VITE_APP_SERVER=https://your-new-domain.com
```
2. **Rebuild the application** for all platforms:
@@ -102,46 +111,32 @@ To change the production domain for all sharing functionality:
npm run build:electron
```
### Environment-Specific Configuration
The system maintains environment-specific configuration for internal operations
while using production domains for sharing:
```typescript
// Internal operations use environment-specific URLs
export const APP_SERVER =
import.meta.env.VITE_APP_SERVER || "https://timesafari.app";
// Sharing always uses production URLs
export const PROD_SHARE_DOMAIN = AppString.PROD_PUSH_SERVER;
```
## Benefits
### ✅ Consistent User Experience
### ✅ Simplified Configuration
- All shared links work for all users regardless of environment
- No more broken localhost links in development
- Consistent behavior across all platforms
- Single constant for all URL generation
- No confusion about which constant to use
- Consistent behavior across all functionality
### ✅ Environment Flexibility
- Easy to configure different domains per environment
- Support for development, test, and production environments
- Environment-specific sharing URLs when needed
### ✅ Maintainability
- Single source of truth for production domain
- Single source of truth for domain configuration
- Easy to change domain across entire application
- Clear separation between internal and sharing URLs
- Clear pattern for implementing new URL functionality
### ✅ Developer Experience
- No need to remember which environment URLs work for sharing
- Clear pattern for implementing new sharing functionality
- Simple, consistent pattern for URL generation
- Clear documentation and examples
- Type-safe configuration with TypeScript
### ✅ Security
- No accidental exposure of internal development URLs
- Controlled domain configuration
- Clear audit trail for domain changes
## Testing
### Manual Testing
@@ -150,7 +145,7 @@ export const PROD_SHARE_DOMAIN = AppString.PROD_PUSH_SERVER;
```bash
npm run dev
# Navigate to any page with copy link buttons
# Verify links use production domain, not localhost
# Verify links use configured domain
```
2. **Production Build**:
@@ -164,27 +159,19 @@ export const PROD_SHARE_DOMAIN = AppString.PROD_PUSH_SERVER;
The implementation includes comprehensive linting to ensure:
- All components properly import `PROD_SHARE_DOMAIN`
- No hardcoded URLs in sharing functionality
- All components properly import `APP_SERVER`
- No hardcoded URLs in functionality
- Consistent usage patterns across the codebase
## Migration Notes
## Implementation Pattern
### Before Implementation
### Current Approach
```typescript
// ❌ Hardcoded URLs
const deepLink = "https://timesafari.app/deep-link/claim/123";
// ❌ Environment-specific URLs
const deepLink = `${APP_SERVER}/deep-link/claim/123`;
```
### After Implementation
```typescript
// ✅ Configurable production URLs
const deepLink = `${PROD_SHARE_DOMAIN}/deep-link/claim/123`;
// ✅ Single constant for all functionality
import { APP_SERVER } from "@/constants/app";
const shareLink = `${APP_SERVER}/deep-link/claim/123`;
const apiUrl = `${APP_SERVER}/api/claim/123`;
```
## Future Enhancements
@@ -208,6 +195,7 @@ const deepLink = `${PROD_SHARE_DOMAIN}/deep-link/claim/123`;
```
3. **Platform-Specific Domains**:
```typescript
export const getPlatformShareDomain = () => {
const platform = process.env.VITE_PLATFORM;
@@ -229,5 +217,5 @@ const deepLink = `${PROD_SHARE_DOMAIN}/deep-link/claim/123`;
---
**Last Updated**: 2025-01-27
**Version**: 1.0
**Version**: 2.0
**Maintainer**: Matthew Raymer