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

Rethink snake_case to camelCase prop conversion #1160

Open
Archmonger opened this issue Nov 4, 2023 · 1 comment
Open

Rethink snake_case to camelCase prop conversion #1160

Archmonger opened this issue Nov 4, 2023 · 1 comment
Labels
priority-2-moderate Should be resolved on a reasonable timeline. type-revision About a change in functionality or behavior

Comments

@Archmonger
Copy link
Contributor

Current Situation

The snake_case to camelCase prop conversion was created with the theory that it should be zero impact.

Related PR:

However, we've received our first report of this behavior causing incompatibilities with third party libraries. In this case, it was related to the Google auth library.

Proposed Actions

Either revert this change, or make it togglable through configuration settings.

@Archmonger Archmonger added priority-2-moderate Should be resolved on a reasonable timeline. type-revision About a change in functionality or behavior labels Nov 4, 2023
@JamesHutchison
Copy link

JamesHutchison commented Nov 9, 2023

my opinion is that, in general, magic changes like renaming things aren't preferable. There's a couple things to consider about this:

  1. These are key values in a dictionary so there's no obligation to change the name to match a naming convention, because there is no naming convention
  2. Keeping values identical to the naming convention of React makes knowledge more transferrable. For example, GPT-4's first assumption is that the keys use camelCase. Reverting the change would align things with how one would intuitively expect them to behave
  3. Renaming breaks "grepability". If I wanted to see all references to where something comes from, from the perspective of the front-end, I now need to know ahead of time that a different name is used. Maintaining grepability is a huge plus to the developer experience and efficiency.
  4. As we saw, renaming creates a point of friction when using 3rd party libraries that expect things to be named exactly like their script expects.

As far as implementing the updated behavior if you move forward with the reversion - one could use a new keyword argument that doesn't make the mutation, and the position argument could be deprecated. Once the old positional argument is removed, the keyword argument could become the new positional one at a later minor version.

I suppose you could also introduce a class that inherits from TypedDict and do a type check on the first arg. I haven't used TypeDict much but it appears so that you'd need to silence custom keys so I'm not sure how I feel about that. Since they are usually a known set, maybe that's a good thing?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority-2-moderate Should be resolved on a reasonable timeline. type-revision About a change in functionality or behavior
Projects
None yet
Development

No branches or pull requests

2 participants