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

Quirk with LiveScript's dash-to-camelCase conversion in cursor paths #81

Open
chrisvfritz opened this issue Jul 6, 2015 · 2 comments
Open

Comments

@chrisvfritz
Copy link
Contributor

# Given a cursor where a key is defined with dashes
data = arch.cursor do
  name-with-dashes: 'value'

# Trying to grab the name using a string with dashes will not work, because 
# although non-literal object keys are transformed to camelCase in LiveScript, 
# dashes in string literals are not
data.get \name-with-dashes .deref! # => null

# To correctly find the name, you have to use the camelCased string that 
# LiveScript converts the key to:
data.get \nameWithDashes .deref! # => "value"

This isn't technically a bug - just how LiveScript works. But I can see a lot of people, especially those new to LiveScript (which may even be most people using LiveScript in Arch), tripping over it. I think a good solution might be to always camelCase the string passed to get unless a non-null value exists for the non-camelCased version. Thoughts?

@charypar
Copy link
Member

charypar commented Jul 6, 2015

Yes, that has been bugging me for a while. I'm not sure it's correct to assume name-with-dashes and nameWithDashes are the same key, though.

@charypar charypar changed the title Quirk with LiveScript's dash-to-camelCase conversion in cursors Quirk with LiveScript's dash-to-camelCase conversion in cursor paths Jul 6, 2015
@chrisvfritz
Copy link
Contributor Author

I can see more issues the more I think about it.

For example, let's say someone is using UUIDs as keys. de305d54-75b4-431b-adb2-eb6b9e546014 would be turned into de305d5475b4431bAdb2Eb6b9e546014. And the slightly but meaningfully different de305d54-75b4-431b-Adb2-b6b9e546014 would be converted to the same string.

And then if a user wanted to get a list of UUIDs from the cursor, and they happened to be stored as keys, they'd all be corrupted. The camelCased UUIDs wouldn't be recognized (or worse, could be _mis_recognized) in the database.

I can start thinking of potential workarounds, but the added complexity is a little scary and I'd still be worried there'd be more edge cases I wouldn't be thinking of. I can imagine some problems caused by this could also be really difficult to debug.

Maybe as a compromise, if an application's initial state has any keys with capital letters, we can assume there might have been automatic camelCasing going on. In this case, Arch can just raise a warning about this quirk. We can suggest that if they're using LiveScript, that they should convert their keys with dashes to string literals, in order to avoid confusion. Then maybe also include instructions for easily turning off this warning with a flag in package.json or a yet-to-exist config file.

Fair workaround?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants