The web team often builds features that must take into account the caching constraints of Wikimedia sites. We do this use a feature flagging system.
Recommendations edit
- Limit DOM changes [1] The web team believes we should limit DOM changes inside feature flags where possible. It's preferable to make DOM changes across the page rather than constrained to a feature flag (particularly where it comes to containers).
- Fork CSS where possible [1] When building features that will make impact one component, it's preferable to manage CSS in separate files wrapped in the feature class (see example)
- Separate body classes for state[1] We have a feature enabled and disabled class on the body element. This allows us to distinguish between the three states for a feature flag: 1) doesn't exist 2) exists and is disabled and 3) exists and is enabled.
Current challenges edit
- HTML is cached separately with a different time to live, compared to JavaScript and CSS assets. This means HTML representing older deploys is often shipping with JS/CSS from recent deploys.
- The use of feature branches is discouraged in Wikimedia deployment because 1) Members outside the team have expectations that any merged code will be deployed with the train 2) Merging feature branches into master is complicated and cumbersome as the master branch evolves due to i18n and dependency updates. 3) It's difficult to revert entire feature branches unless feature branches are condensed into a single commit (losing git history in the process).
Timeline edit
November 14th 2022 edit
The web team discussed how we use feature branches in development.
Examples edit
Using feature flags in CSS edit
.vector-feature-grid-enabled { @import "grid.less"; }
.vector-feature-grid-disabled { @import "legacyLayout.less"; }