How to model and manage global site settings

Introduction

When building composable digital experiences, managing site-level settings like cookie policies, Google Tag Manager (GTM) configurations, and other global application settings is a common requirement. These settings need to be easily accessible, maintainable, and performant across your entire application.

This article explores two primary approaches for implementing site-level settings in Uniform, each with distinct advantages depending on your specific use case and architectural requirements.

Solution

Option 1: Component Pattern Approach

Implementation: Use a component pattern that is part of all compositions, such as a global header component, where site settings are modeled as parameters.

Setup Process:

1. Extend Existing Global Components: If you already have a global header or footer component, add site settings as parameters to this component.
2. Create Dedicated Settings Component: Alternatively, create a dedicated "Site Settings" component and place it inside a global header slot.
3. Configure Parameters: Model your settings (GTM ID, cookie policy flags, etc.) as component parameters.

Code Example:

Pros:

1. Seamless Integration: Fits naturally with existing global component architecture
2. Performance Optimized: Settings are included in the composition response with no additional API calls
3. Flexible Overrides: Leverage pattern parameter overriding to customize settings per page
4. Conditional Logic: Use visibility rules to apply different settings based on context

Cons:

1. Limited Access Control: Harder to restrict parameter-level permissions
2. Payload Impact: Increases composition JSON size, affecting every page load
3. Governance Complexity: Less elegant from a content governance perspective

Option 2: Content Entry Approach

Implementation: Model site settings as a dedicated Content Type entry in Uniform and fetch it during application build or runtime.

Setup Process:

1. Create Content Type: Define a "Site Settings" content type with fields for all global settings
2. Build-Time Integration: Fetch settings during build process and materialize as static JSON
3. Runtime Access: Import the generated settings file throughout your application

Code Example:

Package.json Integration:

Pros:

1. Clean Architecture: Dedicated content management for global settings
2. Enhanced Security: Content Type-level access control and governance
3. Separation of Concerns: Settings management is isolated from component logic

Cons:

1. Performance Consideration: Additional fetch operation increases SSR time
2. Build Dependency: Requires application rebuild for setting changes to take effect
3. Limited Flexibility: Per-page customization becomes more complex to manage

Recommendation

Choose Option 1 if you:

• Already have global components (header/footer) in your architecture
• Need frequent setting updates without rebuilds
• Require per-page setting customization
• Prioritize performance with minimal API calls

Choose Option 2 if you:

• Need strong governance and access control over site settings
• Have infrequent setting changes
• Prefer clean separation between content and configuration
• Don't have existing global component patterns

Summary

Both approaches provide viable solutions for managing site-level settings in Uniform. The component pattern approach offers better performance and flexibility for frequent changes, while the content entry approach provides superior governance and architectural clarity. Consider your team's workflow, security requirements, and performance priorities when selecting the most appropriate strategy for your implementation.