feat: Add support for waiting for non-cached values. #160
Conversation
| _dataSourceManager.identify(_context, completer); | ||
|
|
||
| if (loadedFromCache) { | ||
| if (loadedFromCache && !waitForNonCachedValues) { |
There was a problem hiding this comment.
The actual change to identify and start logic.
|
|
||
| typedef DataSourceFactoriesFn = Map<ConnectionMode, DataSourceFactory> Function(LDCommonConfig config, LDLogger logger, HttpProperties httpProperties); | ||
|
|
||
| Map<ConnectionMode, DataSourceFactory> _defaultFactories(LDCommonConfig config, LDLogger logger, HttpProperties httpProperties) { |
There was a problem hiding this comment.
Moved the default factories into a function. Now it will choose between provided and defaults.
| /// option should NOT be used and instead flag changes should be listened to. | ||
| /// If [waitForNonCachedValues] is true, and an error is encountered, then | ||
| /// false may be returned even if cached values were loaded. | ||
| Future<bool> start({bool waitForNonCachedValues = false}) { |
There was a problem hiding this comment.
So, if you want to use cached values on app start, but not on identify, then this supports that.
If you want to identify multiple contexts sequentially, and you want to ensure your cache gets updated, you can do that. You can also choose to use the cached values for the last context, being as that one would be updated in the background.
If you want to ensure you have "fresh" values when navigating to specific sections of your app, you could do that.
What this does not solve is the situation where someone wants to identify multiple contexts sequentially, wants the cache to be updated, but doesn't want the performance penalty. (One request was basically to allow the identify to continue and update the cache in the background, but concurrently start identifying a new context.)
There was a problem hiding this comment.
If you want flag values to "not change", then you can evaluate all relevant flags after the identify and use those values.
Alternatively, you could set the SDK to offline after completing the identify, and then only go online again when you want to specifically update values.
🤖 I have created a release *beep* *boop* --- ## [1.3.0](launchdarkly_common_client-v1.2.0...launchdarkly_common_client-v1.3.0) (2024-07-31) ### Features * Add support for waiting for non-cached values. ([#160](#160)) ([28f7efa](28f7efa)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).
🤖 I have created a release *beep* *boop* --- ## [4.7.0](4.6.0...4.7.0) (2024-08-01) ### Features * Add support for waiting for non-cached values. ([#160](#160)) ([28f7efa](28f7efa)) * Update to common client 1.3.0 ([#164](#164)) ([3189d51](3189d51)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).
startandidentifyto wait for values from LaunchDarkly instead of resolving with cached values when available.With the previous wrapper SDK this behavior was controlled by the underlying SDK and those would operate similar to the new, optional, behavior.
For most uses cases it is both safer and higher performance to used cached values when they are available instead of only using those cached values as a fallback.
Ideally we would add new return values to start and identify. Next major version we should consider:
Cached,Timeout. While retaining the current value for completing via data from LD.