Conversation
FeatureFlag centralizes how we check for feature availability in a specific build
There was a problem hiding this comment.
On the PR description you say that the checks pass from compile to run time, but this looks to be set on compile time?
There was a problem hiding this comment.
I think that bit wasn't clear. The build type is still defined by build parameters, but using this code does the check at runtime. For instance:
#if DEBUG
doStuff() // this isn't included in the final binary
#endifif build(.Debug) {
doStuff() // this is included in the binary, but it's never reached
}|
@koke I like the PR, but are we sure we want to be limited to the build type only? I know that in some parts of the app we where previous using a special URL scheme to activate features. Do you plan to support this? |
It's not limited. In |
|
|
Instead of having a bunch of checks for
DEBUGandINTERNAL_BUILDspread across the app, I suggest we keep them contained and actually check for enabled features.This moves the checks from compile time to run time, so it might not be best for all scenarios:
Despite all this, I think this approach is interesting so we can easily start using more feature flags. Ideally we'd start work on a new feature by flagging it and enabling only on Debug builds. This way, we can make smaller PRs and only release the feature when it's ready.
I've only added the FeatureFlag code (+tests), I'll start using it on a separate PR
Needs Review: @SergioEstevao