Open shaedrich opened 7 months ago
I definitely think it should be its own independent helper, and maybe there's a Str
wrapper for it. I think you're on the right track with WritingStyle
. Maybe the package is called "Writer" and you're interacting with a Style
class.
So if I was to use this on it's own I'd want to be able to do stuff like:
// Style a title
$title = Style::title('This is my title');
// Style a date
$date = Style::date('2024-01-01 14:00:00');
// Style a date from a Carbon/DateTime instance
$date = Style::date($carbonInstance);
// Override the format
$chicagoTitle = Style::title('This is my title', StyleFormat::Chicago);
The defaults would be set in the service provider:
new StyleFactory(
style: config('writer.style'),
language: config('writer.lang')
)
Yep, sounds good 👍🏻
I totally forgot to list service provider as a configuration option 😅
Yeah, that's why the package name might not be ideal
I think, Writer
might be too ambigious :thinking: (see #6)
Another thing, we have to address, is how we approach designing the API (no, not the REST one):
Maybe the
Str
helper is not the right place, because it is quite generic and should be its own helper (WritingStyle
?) instead.Does that mean, there would need to be a versioning like with the
ramsey/uuid
package? For example,(new ApaStyle(version: 7))->apply($text)
(implementsWritingStyle
interface)Another possibility than the one mentioned above would be to combine different styling options into their respective methods like this:
Str::title($title, style: WritingStyle::APA)
As for the rules, this could even made entirely configurable by adding a new configuration file (
config/writing_style.php
, similar to larastan) with rules like eitheror
Optionally, overwrites could be passed to
Str::style($text, [ 'serial_comma' => true ])
(orWritingStyle::apply()
)