-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Configurable camelizing type values #34
Comments
After this implementation top-level |
I don't mind but I would prefer that by defaul: |
I just don't see any case where you need to mutate values. It's clearly understood why it could be required for keys (for easier properties access), but for values it's not so obvious behavior. But maybe it's only for me. |
The thing is that I don't need this feature but I understand that others might need it. I agree that mutating value is a weird behavior in a vacuum but maybe, just maybe some folks want to be consistent here and there. |
I agree that consistency is important. And additionally there could be case when you need to compare type value with the resources stored in your local repository by their type key. And since they are both camelized by default this will be easier then. |
Thank you for the help :) |
As was discovered in PR #33 there is potential issue with camelizing type's values inside relationships data objects.
Despite camelizing option explicitly called:
camelizeKeys: true
it's affecting type values too.It will be great to have separate configurable option to camelize type values.
Input:
Output:
In my point of view this should work by this way:
And
camelizeTypeValues
should be infalse
state by default.This is breaking change
The text was updated successfully, but these errors were encountered: