String Flags

Introduction

String flags store a text value — for example "light", "stripe", or "enhanced". Use them when behavior depends on one of several named variants rather than a simple on/off decision.

Applications read String flags locally from an in-memory snapshot. Evaluation is synchronous — no network request occurs on the read path.

Common use cases:

• UI themes and layouts — switch between visual modes without redeploying
• Provider selection — route to payment, shipping, or auth backends by name
• Operational modes — legacy, standard, beta
• Copy and messaging — headline or banner text controlled from the dashboard
• Environment-specific labels — display names, support links, or legal footer variants

When to use String flags

Use a String flag when configuration is a single text value chosen from a small, known set of variants.

UI theme — select a rendering path or CSS bundle. Define allowed values in code and treat unknown dashboard values as the default.

Payment provider — switch integration backends per environment. Default to the production-safe provider so a missing flag never routes payments to an untested integration.

Checkout mode — represent mutually exclusive flow variants with one flag instead of multiple Booleans.

Maintenance message — surface operator-controlled copy. An empty default means no banner is shown.

If configuration requires multiple related fields — limits, nested options, or structured objects — use JSON flags. For numeric thresholds, use Number flags. For on/off gates, use Boolean flags.

Create a String flag

Create flags in the SOASAP dashboard. If you have not set up a project yet, start with Create Your First Flag.

1. Open your project

   Sign in to the dashboard, select your project, and open the environment where you want to configure the initial value — typically Development for local work.

2. Create the flag

   Add a new flag with the following properties:

   Key	ui-theme
   Type	String
   Initial value	light

3. Save and verify

   Save the flag. Connected SDKs receive the update over SSE. Read the flag in your application to confirm the value matches the dashboard for that environment.

Example configuration for ui-theme:

Each environment uses its own API key. The SDK bound to the Production key reads Production values only.

Evaluate a String flag

SDKs evaluate String flags locally from an in-memory snapshot. The getter returns a string synchronously — no HTTP request, no disk I/O, and no dependency on SOASAP Cloud availability at read time.

If the stored value is not a string, the SDK returns your explicit default. Getters never throw.

Method names vary by SDK; the semantics are identical.

.NET

var theme = client.GetString(
    "ui-theme",
    defaultValue: "light");

Node.js

const theme = flags.getString(
    "ui-theme",
    "light",
);

Python

theme = flags.get_string(
    "ui-theme",
    "light",
)

Kotlin

val theme = client.getString(
    "ui-theme",
    defaultValue = "light",
)

React / React Native

const theme = useSoasapString("ui-theme", "light");

Angular

readonly theme = this.soasap.string("ui-theme", "light");

Flag evaluation never performs network requests. Values are read from the local SDK snapshot. Background synchronization (SSE) updates the snapshot; subsequent reads return the new value without a redeploy. See Local Evaluation.

Explicit defaults

Always provide a default value on every String read:

client.GetString("ui-theme", defaultValue: "light");

The default is returned when:

• The flag key does not exist in the synchronized snapshot
• The flag was deleted or disabled in the dashboard for this environment
• Synchronization has not completed and no cached snapshot is available
• The restored disk or browser cache is empty or invalid
• The stored value is not a string (type mismatch — for example, a Boolean or Number flag read with GetString)

Explicit defaults are your production safety net. They define application behavior when configuration is missing, stale, or not yet synchronized — without try/catch on the hot path.

Details: Default Values.

Common usage patterns

Theme selection

Route rendering logic based on a named theme. Validate against known values in code; unknown values fall back to the default.

var theme = client.GetString("ui-theme", defaultValue: "light");

return theme switch
{
    "dark" => RenderDarkLayout(),
    "high-contrast" => RenderHighContrastLayout(),
    _ => RenderLightLayout(),
};

Provider routing

Select a backend integration by name. Default to the production-certified provider.

var provider = client.GetString("payment-provider", defaultValue: "stripe");

return provider switch
{
    "paypal" => ProcessPayPalPayment(),
    _ => ProcessStripePayment(),
};

Operational mode

Switch between flow variants with a single flag instead of multiple Booleans.

var mode = client.GetString("checkout-mode", defaultValue: "standard");

return mode switch
{
    "enhanced" => EnhancedCheckout(),
    "beta" => BetaCheckout(),
    _ => StandardCheckout(),
};

Dynamic copy

Display operator-controlled messaging. An empty default suppresses the banner.

var message = client.GetString("maintenance-message", defaultValue: "");

if (!string.IsNullOrEmpty(message))
{
    return ShowBanner(message);
}

Runtime behavior

1. An operator changes a flag value in the dashboard for a specific environment
2. SOASAP Cloud pushes the update to connected SDKs over Server-Sent Events (SSE)
3. The SDK validates the payload and atomically replaces its in-memory snapshot
4. Subsequent getString / GetString calls return the new value

No redeploy is required. No network requests occur during evaluation — only during background synchronization. Propagation is typically sub-second on healthy networks; reads during disconnect continue using the last known snapshot.

See Real-Time Synchronization and Offline Operation.

Production recommendations

Common mistakes

Storing JSON in a String flag

Avoid:

var raw = client.GetString("checkout-config", defaultValue: "{}");
var config = JsonSerializer.Deserialize<CheckoutConfig>(raw);

Prefer:

var config = client.GetJson<CheckoutConfig>(
    "checkout-config",
    defaultValue: new CheckoutConfig());

JSON flags provide typed deserialization, schema validation at read time, and deep-copy semantics. Parsing JSON from a String flag adds error paths on the hot path and bypasses SDK type checking.

Using strings for Boolean logic

Comparing GetString("feature-enabled", "false") == "true" is fragile — typos, casing differences, and type mismatches cause silent misconfiguration. Use GetBool for binary decisions.

Unvalidated magic strings

Avoid:

if (client.GetString("checkout-mode", "") == "enhanced")
{
    // ...
}

Prefer:

const string ModeStandard = "standard";
const string ModeEnhanced = "enhanced";

var mode = client.GetString("checkout-mode", ModeStandard);
if (mode == ModeEnhanced)
{
    // ...
}

Named constants make allowed values discoverable in code review and prevent silent failures from dashboard typos.

Using String flags for numeric configuration

Parsing "100" from a String flag on every request adds conversion overhead and failure modes. Use Number flags for limits, rates, and thresholds.

Related documentation

• Boolean Flags — on/off toggles and kill switches
• Number Flags — limits, rates, and thresholds
• JSON Flags — structured remote configuration
• Feature Flag Best Practices — inventory hygiene and rollout patterns
• Naming Conventions — key format and consistency
• Architecture — local evaluation, SSE, cache, and offline operation
• SDK Documentation — install and configure your platform SDK