[RFC] ContextResolveEvent to allow context customization

[ajgarlag]

With this feature, a user can write a listener to allow context customization when checking for a feature.

The dependency on the event dispatcher instance is optional, so it is backward compatible. Maybe it could be required in the next major version.

WDYT?

[coveralls]

Pull Request Test Coverage Report for Build 223

• 26 of 28 (92.86%) changed or added relevant lines in 4 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.4%) to 98.812%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/Listener/AnnotationSubscriber.php	9	11	81.82%

Totals
Change from base Build 222:	-0.4%
Covered Lines:	499
Relevant Lines:	505

---

💛 - Coveralls

[coveralls]

Pull Request Test Coverage Report for Build 223

• 26 of 28 (92.86%) changed or added relevant lines in 4 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.4%) to 98.812%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/Listener/AnnotationSubscriber.php	9	11	81.82%

Totals
Change from base Build 222:	-0.4%
Covered Lines:	499
Relevant Lines:	505

---

💛 - Coveralls

[coveralls]

Pull Request Test Coverage Report for Build 223

• 26 of 28 (92.86%) changed or added relevant lines in 4 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.4%) to 98.812%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/Listener/AnnotationSubscriber.php	9	11	81.82%

Totals
Change from base Build 222:	-0.4%
Covered Lines:	499
Relevant Lines:	505

---

💛 - Coveralls

[ajgarlag]

Another option to allow context customization without the event stuff is always passing a Context instance to the isActive check and leverage the ContextDecoratorInterface objects to decorate the context.

The main problem with this option is that the context decorator has no access to the feature name.

[migo315]

I think this could be solved by a simple $context->replace('_feature', $name) here?
https://github.com/bestit/flagception-sdk/blob/master/src/Manager/FeatureManager.php#L51

Then you can create and tag your context decorator which has the feature name in $context->get('_feature').?
https://github.com/bestit/flagception-bundle/blob/master/src/DependencyInjection/CompilerPass/ContextDecoratorPass.php#L25

Then the feature name would always be present in the context and could be accessed everywhere.
Although the interface allows "Context" to be null, the FeatureManager always provides a context object. So as long as you use the services of the Flagception SDK, this should fit.

[ajgarlag]

I think this could be solved by a simple $context->replace('_feature', $name) here?
https://github.com/bestit/flagception-sdk/blob/master/src/Manager/FeatureManager.php#L51

I like your proposition, PR open: bestit/flagception-sdk#24

[migo315]

I've merged and released it. So we can close this PR?

[ajgarlag]

You're right. Not needed anymore. Thanks.