-
Notifications
You must be signed in to change notification settings - Fork 757
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
Camelize all props that can be converted to JSON #946
Conversation
Since we're working in a Rails environment, we can assume that ActiveSupport is loaded and has defined `#as_json` on `Object`. Further, since these are react props, they can all be expected to be converted to JSON anyway.
Any opinions on this? |
It's a good upgrade over the existing params check. The doc for that methods needs to be updated to reflect this change and I need to think if this classes as a breaking change or if I can put it in a feature level patch. Good contribution, glad that GitHub added the bookmark notifications tab as to be honest this one got forgotten about a little (sorry!) Edit: |
ah, good call on version. as far as i can tell, it looks like i think putting this in a patch version is probably too risky. someone is inevitable passing in active record objects, which would get serialized as json correctly, but not camelized. then getting this update would likely break their apps. and this is kind of tricky to track down. i'll update the docs later today. is it just the README? thanks! |
@@ -3,21 +3,19 @@ module React | |||
# @param props [Object] If it's a Hash or Array, it will be recursed. Otherwise it will be returned. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Inline docs here.
Marked the inline doc as a comment. I was wondering if there was some sort of option we could put this behind to make it opt-in, thereby letting us release as a feature without breaking people's existing React apps. However since there's already code there to specifically change Params, any toggle ignoring params would be a very odd toggle indeed. Likely at this point to make it hold off for a major version bump. Need to update pre-bundled react anyway 👍 |
I think this is OK to merge as-is. @BookOfGreg @j-clark any thoughts on this? @j-clark can you please add a changelog entry? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
We need to add a CHANGELOG entry, and the PR is good to go. |
wow, this PR is a relic from the past! i'll be honest, it's unlikely that i'll get a changelog entry added any time soon. i'm a corporate drone these days and don't even have git setup on my work laptop 😞 |
@justin808 I created a separate PR with the changelog entry for this PR: #1207 Let's get this merged. |
Summary
This solves the case where we want to camelize_props, but those props aren't explicitly a hash or array (for example
ActiveModel::Serializer
,Representable
,ActionController::Parameters
, etc.As mentioned about, I'm making the assumption that ActiveSupport is loaded since this is within Rails, but let me know if that's not a valid assumption
Also, thoughts on simplifying it even further? If we know that ActiveSupport is defined, we could just use
#deep_transform_keys
as so