search

arch-js / arch

Web application framework for React by Red Badger
BSD 3-Clause "New" or "Revised" License
170 stars 13 forks source link

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

Open chrisvfritz opened 9 years ago

chrisvfritz commented 9 years ago 
# 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 commented 9 years ago

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.

chrisvfritz commented 9 years ago

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?