jreij
commented
4 weeks ago Hi @wrozwad, thanks for reaching out. This is actually on our roadmap but, as you mentioned, the introduction of breaking changes makes it complicated. Especially that these changes will not cause a build error to alert devs that something needs to be fixed, but instead the strings they are overriding will "silently" stop working and revert back to our default values.
We tried to find a solution that involves deprecation and duplication or that will cause a build error when upgrading but xml resources are not very flexible there. And highlighting these changes in the release notes and UI customization guide will help but we cannot assume that everyone will read and notice these changes before upgrading. So unfortunately it will have to wait until the next major release (v6) where we usually introduce breaking changes.
As for your suggestion with creating duplicates, I believe it will not prevent the issues mentioned above. Unless I am missing something, please let me know.
Is your feature request related to a problem? Please describe. After implementing the SDK, we noticed several unwanted resource name collisions in your SDK, for example, for
payment_methods_header.Describe the solution you'd like Based on Development considerations for library modules # Avoid resource merge conflicts article, a good practice when creating public resources in libraries is to add custom prefixes that clearly indicate the specific library. Here, it could have been
adyen_*, so for example, the problematic string would be namedadyen_payment_methods_header.To avoid introducing breaking changes immediately, I suggest first creating duplicates with a prefix and clearly marking this change in the UI customization Guide, indicating from which version the old resources will no longer be supported.