ux
ux copied to clipboard
symfony
[Icons] Expose IconRendererInterface
As the renderer won't change without BC (at least via the twig function/component).. i think it's ok to expose an interface here, allowing people to use it / decorate / etc..
Only thing i think we don't want (for now): add other public methods (like exposing the Icon object)
| Q | A |
|---|---|
| Bug fix? | no |
| New feature? | yes |
| Issues | Fix #... |
| License | MIT |
Why do you think we need an interface?
I prefer exposing an interface than a Twig Extension + TwigComponent to be fair ... it's more future-proof. And the contract is already ensured so that would not change a thing i guess.
We don't have any plant for other IconRenderer?
No, same for the Router, Serializer, FormBuilder, etc.. it makes testing and autowiring easier for users :)
And why user would need to create their own Renderer?
Not create their own... but decorate :) I personnaly would like to do it easily (as i prefer to wrap my icons in span for instance)
I think this a bit to early for this abstraction
Again, as we offer a form of contract with the TwigExtension, i think we should make this official (i mean, only one method is not much ^^)
In my packages, I'd make IconRenderer autowireable but in Symfony core, I believe interfaces are preferred, even if there's only 1 implementation. It's easier for someone to decorate.
@smnandre, is an implementation that handles aliases in config (like requested in #1767) what we'd add? I'd like to implement #1800 at some point, does this interface prevent this?
Nope it does not !
Alias/config handling is on the way (started on one of my branches) and the interface is perfect to abstract this implementation i guess
Regardind SVG symbol / sprites / reuses / etc... It can be either coded via this interface or a new explicit method call but nothing blocking here
Let's merge this one because the given arguments were compelling.
Thanks @smnandre!
