Autoconfig Requirement API discussion #217
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I'm opening this Draft PR hoping to get some feedback and spark discussion on the user-facing annotation API, hopefully before I spend too much time implementing the backend for it...
Each commit takes a slightly different approach. I also have some other examples in some different branches (see below)...
1
The first commit takes a simplistic approach.
All requirement annotations must reference a handler method and optionally provide arguments to it.
Additionally,
DefaultRequirements
handlers are provided to prevent users needing to re-implement common requirement handlers such as simple equality checks.This can lead to somewhat clunky annotation declarations to do fairly simple requirements:
2
The second commit attempts to improve the UX by introducing a concept of "simple" requirements. These are requirements that reference a Config Entry GUI instead of an actual handler method.
Simple requirements would be built into actual requirements during dependency setup. We would need to follow the requirement reference looking for a method handler, and then try again looking for a config entry field if no method exists.
3
The third commit removes the separate
@Requirement
annotation that was used by both@EnableIf
and@DisplayIf
and instead moves all of its parameters into each of those.This is a bit of a painful compromise since it leads to having to maintain the same interface in two places, however it significantly improves the user experience by reducing boilerplate from dependency annotations.
In my opinion it's well worth it:
Other work
Other examples are in the original draft PR and my newer autoconfig dependencies branch