golem
/
VectorGOLEM
9
0
Fork 0
Code Issues 1 Pull Requests Releases Wiki Activity
VectorGOLEM/includes/FeatureManagement/TODO.md

12 lines
687 B
Markdown
Raw Normal View History

features: Add minimalist feature manager With complex additions to Vector's codebase like the Desktop Improvement Program upcoming, it's important that we have a shared, intuitive language to talk about features and their requirements. Centralising the registration of features and creating an API satisfies does exactly this. This change introduces a greatly-reduced version of Piotr Miazga's (polishdeveloper, pmiazga) original proposed API and associated scaffolding classes for feature management in Vector, which itself was based upon his work in MobileFrontend/MinervaNeue. This is done to establish a foundation upon which we can build the more sophisticated parts of Piotr's proposal in a piecemeal basis, thereby minimising risk. Distinct from Piotr's proposed API is the ability to register sets and features that are always enabled or disabled. Additionally: - A Vector.FeatureManager service is registered but not used - A list of proposed immediate next steps is included Bug: T244481 Change-Id: Ie53c41d479eaf15559d5bb00f269774760360bde
2020-02-20 16:37:33 +00:00
TODO
====
Currently the `FeatureManager` class is a very shallow interpretation of Piotr Miazga's proposed
API and associated scaffolding classes (see https://phabricator.wikimedia.org/T244481 and
https://gerrit.wikimedia.org/r/#/c/mediawiki/skins/Vector/+/572323/). This document aims to list
the steps required to get from this system to something as powerful as Piotr's.
featureManager: Add DynamicConfigRequirement requirement We expect the vast majority of requirements and features to be defined in services as possible. However, there are some "complex" requirements that require additional application/HTTP request state. Unfortunately, service wiring is done before some of that state is available. I65702426 attempted to work around this by requiring clients of the Feature Manager to pass that additional state on every interaction with the system. Those complex requirements would then select the parts of the state that they required when it was required. However implementations of \IContextSource are God objects and their use should be limited. Whilst reviewing I65702426, Stephen Niedzielski mentioned that the application state being available is a requirement. This remarkably simple solution: - Keeps the Requirement interface and FeatureManager API free of God objects; - Is true to the nature of the Feature Manager - it makes clear and centralizes the various checks for application state being available across the codebase; and - Inject a Requirement implementations' dependencies at construction time It just so happens that the $wgFullyInitialised variable flags whether the application state is available... Changes: - Add the the FeatureManager\Requirements\DynamicConfigRequirement class and tests. The DynamicConfigRequirement lazily evaluates a single configuration value whenever ::isMet is invoked - Register an DynamicConfigRequirement instance, configured to evaluate $wgFullyInitialised while constructing the Vector.FeatureManager service Bug: T244481 Change-Id: I7a2cdc2dfdf20d78e4548f07cf53994563b234b3
2020-03-13 17:22:59 +00:00
1. Consider supporing memoization of those requirements (see https://gerrit.wikimedia.org/r/#/c/mediawiki/skins/Vector/+/573626/7/includes/FeatureManagement/FeatureManager.php@68)
2. Add support for getting all requirements
3. Add support for getting all features enabled when a requirement is enabled/disabled