[12.x] Add nullish check methods to Str facade

[JoeyMckenzie]

In an ode to .NET, the string.IsNullOrEmpty() and string.IsNullOrWhitespace() functions I've always found helpful and thought they could be useful for the masses using Laravel. I usually add these to my own Laravel projects in some for of helper method, but thought it was be nice to have these officially as part of the Str facade.

I find it fairly useful for high PHPStan levels that enforce strict null checks/empty checks for strings rather than truthy/falsy assertions. For those of us weirdos using it near max level, we could centralize those checks to the Str facade rather than the various flavors of is_null(), empty(), === null, === '', etc.

[shaedrich]

Honestly, I'm not sure if it brings that much benefit to spare "lazy" (no offense) devs from having to write two(!) conditions. The trim() part, though, might be helpful in some cases. The problem I see here, might be that it motivates people to add all kinds of other checks and permutations of it.

[JoeyMckenzie]

Honestly, I'm not sure if it brings that much benefit to spare "lazy" (no offense) people from having to write two(!) conditions. The trim() part, though, might be helpful in some cases. The problem I see here, might be that it motivates people to add all kinds of other checks and permutations of it.

I see your concern, but you could apply this same logic to a lot of Str methods (lower, toBase64, etc.) that are simple wrappers around built-in PHP methods. That's the whole point of centralizing simple checks like this - it allows everyone on the team to do things the same way rather than someone using truthy/falsy string assertions, someone checking only for empty strings, etc.

[shaedrich]

Thanks for using data providers—that makes the test output so much better to read and debug 🙏

[shaedrich]

Honestly, I'm not sure if it brings that much benefit to spare "lazy" (no offense) people from having to write two(!) conditions. The trim() part, though, might be helpful in some cases. The problem I see here, might be that it motivates people to add all kinds of other checks and permutations of it.

I see your concern, but you could apply this same logic to a lot of Str methods (lower, toBase64, etc.) that are simple wrappers around built-in PHP methods. That's the whole point of centralizing simple checks like this - it allows everyone on the team to do things the same way rather than someone using truthy/falsy string assertions, someone checking only for empty strings, etc.

I get your point—to a certain extend. But the decision to include case change methods into the Str facade is a separate decision than the one to include checks. These case change methods often times factor in multi-byte support than can otherwise easily be forgotten with custom implementations.

I'm not saying that I particularly like having all these very distinct sets of functions in one single facade (#52979).

[JoeyMckenzie]

Honestly, I'm not sure if it brings that much benefit to spare "lazy" (no offense) people from having to write two(!) conditions. The trim() part, though, might be helpful in some cases. The problem I see here, might be that it motivates people to add all kinds of other checks and permutations of it.

I see your concern, but you could apply this same logic to a lot of Str methods (lower, toBase64, etc.) that are simple wrappers around built-in PHP methods. That's the whole point of centralizing simple checks like this - it allows everyone on the team to do things the same way rather than someone using truthy/falsy string assertions, someone checking only for empty strings, etc.

I get your point—to a certain extend. But the decision to include case change methods into the Str facade is a separate decision than the one to include checks. These case change methods often times factor in multi-byte support than can otherwise easily be forgotten with custom implementations.

I'm not saying that I particularly like having all these very distinct sets of functions in one single facade (#52979).

I agree that casing methods justify themselves due to multibyte considerations, but I’d argue that correctness alone shouldn’t be the only metric for inclusion. Consistency and reduced cognitive load matter just as much, especially in larger teams. These additions aren’t about avoiding two lines of code; they’re about expressing intent clearly across a codebase of many developers.

When I seeStr::nullOrWhitespace(), I instantly understand what it checks without having to interpret logic or wonder how someone defined “empty.” I’ve had to fix plenty of bugs caused by inconsistent truthy/falsy string assertions. Centralizing that logic into clearly named, reviewed, and tested helpers means everyone on the team gets it right, every time.

[shaedrich]

When I seeStr::nullOrWhitespace(), I instantly understand what it checks without having to interpret logic

When I see the actual code, I can be sure what it does; when I see a method call, I can only speculate about the implementation when I don't look it up. And Laravel already has some places where methods break the principle of least astonishment by not actually doing what you would expect them to by their name.

[shaedrich]

Speaking about multi-byte support, maybe, using mb_trim() would be safer here

Suggested change

	return $string === null || trim($string) === '';
	return $string === null || mb_trim($string) === '';

[shaedrich]

Has it been a conscious decision to not support modifying the second parameter to trim(), $characters?

[taylorotwell]

Thanks for your pull request to Laravel!

Unfortunately, I'm going to delay merging this code for now. To preserve our ability to adequately maintain the framework, we need to be very careful regarding the amount of code we include.

If applicable, please consider releasing your code as a package so that the community can still take advantage of your contributions!