Due to caching, it's likely that there'll be discrepancies between the two different representations of the feature manager state, the classes added to the body element and the mw.config, when a feature is enabled or disabled on the backend. The client-side feature manager should detect this discrepancy.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | • Jhernandez | T104319 [GOAL]: Feature flag features on MobileFrontend | |||
| Resolved | None | T141087 [EPIC] Add feature management | |||
| Resolved | Jdlrobson | T147641 [EPIC] Improve top of the article user experience - mobile | |||
| Duplicate | None | T141124 Handle promoting feature from beta to stable | |||
| Duplicate | phuedx | T141121 Implement basic feature management |
@phuedx forwarded state if it is in mw.config as I've suggested in T141121 would be tied to the HTML, so hydrating the feature manager would be the same in cached HTML or fresh ones, given that config variable is cached in the html page.
Then the only discrepancies would be RL modules to be loaded if not there, but I'm not sure this feature management should be concerned with that (I'm probably wrong though). See comments on T141087#2491693
I'd love to see a proposal of api (in the epic as a comment) if this is going to be involved with loading missing RL modules to see how it would work.