You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a developer, I want to reverse-engineer existing *.resx into typealized interfaces, to start leveraging the code-first approach in existing codebases.
The text was updated successfully, but these errors were encountered:
Easy for genarating simple properties.
Not so easy for formatted strings.
Assuming resource-keys or - values may contain format parameters like {0}, etc, the generator may use this as a foundation to generate the interface. It's very unprobable that those parameters are in a notation understood well by TypealizR in order to generate meaningful method names.
Another problematic scenario to follow is when devs would start to manipulate the reverse-engineered Interfaces, which would result in new keys, with no way to detect the original key/value when exporting.
Maybe this would need to introduce some kind of a annotation (probably an attribute) to "lock-in" to a certain key 🤔, which would be generated over method names.
This attribute may then even be used in pure code-first approaches to let people influence names during export.
[TypealizedKey("SomeKeyName) ] or something similar.
As a developer, I want to reverse-engineer existing
*.resx
into typealized interfaces, to start leveraging the code-first approach in existing codebases.The text was updated successfully, but these errors were encountered: