feat(provider-options): add provider-specific option filtering #772
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.
Description
Motivation
I'm working on a project where I need to set OpenAI's
storeparameter tofalse. Since this isn't currently supported, I created #766. Today I discovered I also need theincludeoption, which isn't available yet either.This made me think whether there could be a way to make this a bit more open for developers.
Additions
To accomplish this, I've introduced a new value object,
ProviderOption, which is just a simple wrapper where you can specify thekey,value, and optionally aprovider.Changes
The main change is in the
HasProviderOptions.phptrait, where$providerOptionsnow stores<int, ProviderOption>instead of<string, mixed>.The main change in behavior is that developers would be able to supply provider options even without them being explicitly supported by Prism. Though, if the guarding is by design, I can still imagine a version where, for example, the
ProviderOptionwould have aforceparameter, and the developer would have to set it totruewhen not explicitly supported.I think it could save a lot of time when you stumble upon an unsupported custom option and you just need to use it to move forward.
Examples
Below are a couple of examples of what this approach would enable.
Ensuring options are used only for a specified provider
In this example, since OpenAI is used as the provider, the
cacheTypeoption is automatically skipped.Reusing options
In case you find yourself repeating options, or you have some custom logic to determine the value, you can extend the
ProviderOption.Current syntax
Or you can use the same syntax as you're used to. This is equivalent to using
ProviderOptionwhere provider is set tonull.In closing
For demonstration purposes, I've changed only the Text handler for OpenAI. I would have to go through the rest if we decide to follow through. Also, the current implementation does not take into account the
forceparameter suggestion. For now, it assumes we'd let developers fully control the custom options.Breaking Changes
The public interface remains the same, so there should be no breaking changes, but I would have to look into this a bit more should we decide to follow through.