Open joshrainwater opened 3 months ago
Thanks, @joshrainwater.
I wrote up a big reply with my thinking on this behaviour and where would could and shouldn't change things...and in the process I think I convinced myself we may want ease restrictions across the board on Pennant ha!
Think I just need to sit on this one for a day or two to process my thoughts on the potential changes.
I think I've come around to the idea that we should not throw exceptions when you try to pass a scope value to a feature definition that does not support it. Instead, we should just return false
and trigger an event.
Feature::defined('user-feature', fn (User $user) => true);
//
Feature::for(User::first()->active('user-feature'); // true
Feature::for(Team::first()->active('user-feature'); // false
That solves the values
issue, as they would just show up as false
.
However, it would be best if the all
function only returned features that are supported by the type.
Feature::defined('user-feature', fn (User $user) => true);
Feature::defined('team-feature', fn (Team $team) => true);
Feature::for(Team::first())->values([
'user-feature',
'team-feature',
]);
// [
// 'user-feature' => false,
// 'team-feature' => true,
// ]
Feature::for(Team::first())->all();
// [
// 'team-feature' => true,
// ]
What do you think, @joshrainwater?
Yeah I like this; let's me still use some of the shortcut functions in cases where I just want to grab a list of all Team-level features in the few cases that it's the best thing to do.
Also adding an event trigger for trying to get a feature for the wrong scope eliminates some of the hesitation around ignoring a mistake being made.
My project requires scoping features across multiple different models. Quick example:
When I configure this a Service provider, all calls to
all()
orvalues()
functions throw 500 errors with incorrect parameter types. A call toFeature::for($user)->all()
also throws errors.I think my ideal in this situation would be instead to return a list of all features under the current model type scope, rather than throwing an error and checking them. The other alternative would be to return false for all features that are not under the scope of the model being tested. So either Feature::all() would not return any value for
beta-design
in this case, or it would returnfalse
.I am happy to code this up and add a Reflection into PendingScopedFeatureInteraction (or drivers, if that makes more sense) but wanted to confirm which expected behavior seems better. Either way, I don't like working with a system where both of these functions are completely disabled.