Feature: Bootstrapping

[FredrikOseberg]

Describe the feature request

In other Unleash SDKs, we support boostrapping the SDK from a file or in-memory JSON structure. This can allow you to use the SDK before the initial fetch towards the API completes, or if the API is unavailable at startup.

Android supports in-memory boostrap structure and filebased: https://github.com/Unleash/unleash-android?tab=readme-ov-file#step-4-option-2-provide-an-initial-state

Javascript SDK Support: https://github.com/Unleash/unleash-android?tab=readme-ov-file#step-4-option-2-provide-an-initial-state

If the SDK receives a bootstrapped structure or file, it should put those toggles into the internal cache and set the SDK status to ready (and emit the ready event).

[benjamin-es-hall]

Just took a look to see what expected json is if reading from a file and I believe this is correct (also included default values in Android SDK):

{
    "toggles": [
        {
            "name": <toggle_name: STRING>, // REQUIRED
            "enabled": <BOOL>, // REQUIRED
            "variant": { // DEFAULT - given in next code block
                "name": <variant_name: STRING>, // REQUIRED 
                "enabled": <BOOL>, // REQUIRED - DEFAULT: true
                "feature_enabled": <BOOL>, // REQUIRED - DEFAULT: false
                "payload": { // OPTIONAL - DEFAULT: null
                    "type": <payload_type: STRING>, // REQUIRED 
                    "value": <payload_value: STRING>, // REQUIRED
                }
            },
            "impressionData": <BOOL> // REQUIRED - DEFAULT: false
        },
        ....
    ]
}

In Android SDK variant defaults to:

{
    "name": "disabled",
    "enabled": true,
    "payload": null
}

Android JSON data classes found here:

• Toggle
• Variant
• Payload

Payload seems to have some helped functions to convert payload string to int, double, or boolean. These are likely mapped to optional type in swift.

@FredrikOseberg does the above look correct?

Also, general question, what is the difference between enabled and feature_enabled in the Variant object?

[kwasniew]

Hey @benjamin-es-hall

Regarding a default variant I'd follow our JS SDK example and default enabled to false: https://github.com/Unleash/unleash-proxy-client-js/blob/main/src/index.ts#L99. We've also changed our Android example to have the same default Unleash/unleash-android#93.

Regarding the shape of the variant payload the payload itself can be modelled as optional (https://github.com/Unleash/unleash-proxy-client-js/blob/main/src/index.ts#L71). However once the payload is there the type and value have to be provided. In the JS SDK we have type and value of the payload as strings and it's up to the userland code to convert them. Android SDK adds type conversion utilities in the library code.

Regarding the enabled vs feature_enabled it was added to distinguish 2 scenarios:

• variant disabled because feature is disabled
• variant disabled because there is no matching variant
  More: UnleashClient().get_variant() returns the same result when the feature is disabled vs enabled and there are no variants defined unleash-client-python#284

[benjamin-es-hall]

Hey @benjamin-es-hall

Regarding a default variant I'd follow our JS SDK example and default enabled to false: https://github.com/Unleash/unleash-proxy-client-js/blob/main/src/index.ts#L99. We've also changed our Android example to have the same default Unleash/unleash-android#93.

Ah perfect thank you, it was unexpected to me having the default being true!

Regarding the shape of the variant payload the payload itself can be modelled as optional (https://github.com/Unleash/unleash-proxy-client-js/blob/main/src/index.ts#L71). However once the payload is there the type and value have to be provided. In the JS SDK we have type and value of the payload as strings and it's up to the userland code to convert them. Android SDK adds type conversion utilities in the library code.

Regarding the enabled vs feature_enabled it was added to distinguish 2 scenarios:

• variant disabled because feature is disabled
• variant disabled because there is no matching variant
  More: UnleashClient().get_variant() returns the same result when the feature is disabled vs enabled and there are no variants defined unleash-client-python#284

This is really useful! Thank you!

[benjamin-es-hall]

@kwasniew I'm looking at this now (almost finished with main code, adding/updating tests), but I noticed that at least on the backend client of Unleash we are using (4.17.2) that the feature_enabled field doesn't exist in the response. I've marked it as optional as otherwise the swift decoder will fail. Was this added in a more recent version of Unleash?

[kwasniew]

@benjamin-es-hall yes, it was added in 5.9.0 https://github.com/Unleash/unleash/releases/tag/v5.9.0 by this PR: Unleash/unleash#5800