feat: allow custom output via formatters

[jaulz]

This PR will let developers define custom templates for the different parts that can be generated. I am not sure about the template syntax (i.e. ":key") but that's the Laravel translation syntax.

This PR will let developers define custom formatters for the different parts that can be generated.

[jaulz]

@bakerkretzmar I am not sure why the tests fail since I do not have the PHP version locally and there are no error messages in the output. With php@8.0 all tests are running fine:

[bakerkretzmar]

@jaulz I think the test failures were because of the string typed properties, which weren't in PHP 7.3.

This is a really cool idea... I'm going to think about it for a bit 😄 I like the flexibility it adds but I'm not sure how many people would actually use it. Can you give some more examples of what you're hoping to do? The example in the test you added just leaves out the typeof window !== 'undefined' && typeof window.Ziggy !== 'undefined' check, which doesn't feel worth it to me.

Thanks!

[jaulz]

The idea that floats in my head is to also expose the payload schema to have local validations (as far as it's possible) and thus this would be the initial feature that would allow me to hook into the generation of the route definitions. I am not yet sure how it will look like and when I will work on it but it would be handy to be ready at any time :)

[Tofandel]

Awesome idea and PR, I would for sure use it

I just have one remark for the test unit though, instead of modifying the existing test, just copy it and then apply your modification to avoid 2 features overlapping in the same test

[jaulz]

Yeah, I could do that but I don't want to spend any time on it as long as @bakerkretzmar does not consider it to be merged. Just let me know in case it gets relevant 😊

[bakerkretzmar]

Okay looking at this again, I like it a lot, let's do it 😎 couple questions before I take a final pass and merge it in:

• I think I have a slight preference for resolving the formatters out of the application container, instead of listing classes in the config. So rather than config()->get('ziggy.formatters.file', FileFormatter::class), something like app(FileFormatter::class, $ziggy). We could register our default ones in our service provider, and then to override them, users would bind their custom ones in their own service provider instead of publishing and filling in our config file. What do you think of that approach? Any drawbacks you can see?
• I think it would be cool if we didn't need to call ->format() and the Script classes were stringable/htmlable. In theory they could then go directly in Blade templates and they would get cast to strings/HTML during render. This feels a tiny bit more flexible to me, and basically makes the formatters more into 'payload objects' that could do formatting or potentially other stuff too. I don't mind making this change myself. Maybe I'm over thinking this, curious to know what you think though!

[jaulz]

Great to hear 😊 Regarding your points:

• I haven't seen such an approach in a Laravel extension so far (but that doesn't mean anything since I am fairly new) and actually I took the approach from Typescript transformer (https://github.com/spatie/laravel-typescript-transformer/blob/main/config/typescript-transformer.php). In terms of drawbacks I think there are none since it does the same but just in a different way 😊
• That sounds like a reasonable approach and I just pushed the change for it 😊

[jaulz]

Nice, that looks good 👍

[bakerkretzmar]

@jaulz thought about it some more and decided to keep your original implementation and get the classes from the config. Thanks for your patience!