fix: use config fallback for appName and environment #70
Conversation
| override fun getContext(): UnleashContext { | ||
| return unleashContext | ||
| return unleashContext.copy( | ||
| appName = unleashContext.appName ?: unleashConfig.appName, | ||
| environment = unleashContext.environment ?: unleashConfig.environment | ||
| ) | ||
| } |
There was a problem hiding this comment.
This will create a brand new class every time we call it, instead of using the existing field on the class. I'm wondering if we should rather do the fallback to config values on constructing the client.
There was a problem hiding this comment.
I was trying to cater for a use case when people overwrite config appName with updateContext appName in the first call and then another updateContext removes appName and then we should fall back to the config appName. So it gives you a fallback no matter how you used updateContext in the past.
There was a problem hiding this comment.
In other frontend SDKs updateContext can't update appName so we can save appName from config during construction. Since this SDK allows for appName overwrites from context it complicates the solution space a bit.
There was a problem hiding this comment.
Yeah, true. Then I think I'm fine with this. Let's merge.
About the changes
Use config appName and environment as a fallback when context values are missing.
Fixes: #67
Important files
Discussion points