4 ms·
It's even okay to hardcode them into code (not a config/json file). Depending on the build pipeline this is similar to preprocessor flags, and the code will be
by andix 2y ago
It's even okay to hardcode them into code (not a config/json file). Depending on the build pipeline this is similar to preprocessor flags, and the code will be removed during build.
It might be enough to test new features with a limited audience (beta build, test deployments for stakeholders/qa).
If done correctly this solution can be easily extended to use a feature flag management tool, or a config file.
PS: removing new features during build/tree-shaking/etc adds some additional security. In some cases even disabled features could pose a security risk. Disabled features are often not perfectly tested yet.
- CRConrad 2y ago> It's even okay to hardcode them into code (not a config/json file). Yes, as I understood it that was what the article was all about.
- andix 2y agoThe article suggests to put them into a config file, and considers it hardcoding. That’s how I understood it at least.
- CRConrad 2y agoAh, yes indeed, seems I'd misread it; sorry. (Sheesh, WTF is that guy talking about??? Now not only "feature flag" doesn't mean anything any more, but "hardcoded" doesn't either!)