Closed joakimbergros closed 1 month ago
I just noticed it's available as a standalone dependency as well with illuminate/conditionable
.
It would follow the same structure as illuminate/collection
and illuminate/contracts
currently in the comsposer.json
.
Edit: Seems the illuminate/collection
already has the dependency.
Hey @joakimbergros!
I think adding the trait sounds good to me -- though unfortunately it doesn't have a v8 version which is the minimum we currently target in the composer.json
:
We'll have to drop support for v8.0 versions, to be able to add this trait.
I see, that's a bummer. Thanks for taking the time to check at the very least, appreciate it!
Decorator pattern to the rescue :)
No worries @joakimbergros! On the next major release I'll be removing support for these versions, so we can add the trait then 👍
If you'd like, you can add this trait directly onto the query builder by using your own model and then your own Builder
instance (the same way you can do with Laravel's Eloquent):
namespace App\Ldap\Models;
use App\Ldap\Builders\UserBuilder;
use LdapRecord\Models\ActiveDirectory\User as BaseUser;
class User extends BaseUser
{
/**
* Create a new query builder.
*/
public function newQueryBuilder(Connection $connection): UserBuilder
{
return new UserBuilder($connection);
}
}
namespace App\Ldap\Builders;
use LdapRecord\Query\Model\Builder;
use Illuminate\Support\Traits\Conditionable;
class UserBuilder extends Builder
{
use Conditionable;
}
User::query()->when('...');
That's a great solution for now, thanks for the suggestion!
Happy to help! 🙏
Hey,
I'd like to see if adding the
Illuminate\Support\Traits\Conditionable
trait to theLdapRecord\Query\Builder
class would be of interest?I find myself liking the fluent syntax over saving the builder to a variable and then use conditionals to mutate the builder if necessary.
vs
I'd love to hear your thoughts!
I tested this on my own fork and it works nicely, so a PR is ready if you decide it's something you'd want.
Cheers