Skip to content
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

Merged
merged 1 commit into from
Oct 12, 2022

Conversation

j-clark
Copy link
Contributor

@j-clark j-clark commented Oct 18, 2018

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

def self.camelize_props(props)
  props_as_json = props.as_json

  case props_as_json
  when Hash
    props_as_json.deep_transform_keys { |key| key.to_s.camelize(:lower) }
  when Array
    props.map { |prop| camelize_props(props) }
  else
    props
  end
end

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.
@j-clark
Copy link
Contributor Author

j-clark commented Nov 5, 2018

Any opinions on this?

@BookOfGreg
Copy link
Member

BookOfGreg commented Nov 5, 2018

It's a good upgrade over the existing params check.
Was thinking if there were any negative side effects of calling as_json on everything but can't think of one, all major Ruby and Rails enumerable objects likely to be passed in do declare that method as far as I know.

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:
ActiveSupport will be defined but we can't guarantee the version, was deep_transform_keys added after RoR v3.2?

@j-clark
Copy link
Contributor Author

j-clark commented Nov 5, 2018

ah, good call on version. as far as i can tell, it looks like deep_transform_keys was added in rails 4. i think as_json goes back to 2.3 (according to apidock). i don't know if they were necessarily added at the same time, but i'm pretty sure that anything responding to to_json (which is already called in the view helper) will also respond to as_json

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Inline docs here.

@BookOfGreg
Copy link
Member

Marked the inline doc as a comment.
Additions to the readme and/or wiki are always very welcome as they do talk about camelization in general which would be changing.

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 👍

@justin808
Copy link
Collaborator

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?

Copy link
Collaborator

@justin808 justin808 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@alkesh26
Copy link
Collaborator

alkesh26 commented Oct 7, 2022

We need to add a CHANGELOG entry, and the PR is good to go.

@j-clark
Copy link
Contributor Author

j-clark commented Oct 7, 2022

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 😞

Judahmeek added a commit to Judahmeek/react-rails that referenced this pull request Oct 12, 2022
@Judahmeek
Copy link
Collaborator

@justin808 I created a separate PR with the changelog entry for this PR: #1207

Let's get this merged.

@justin808 justin808 merged commit 3f00063 into reactjs:master Oct 12, 2022
justin808 added a commit that referenced this pull request Oct 12, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants