You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
# Given a cursor where a key is defined with dashesdata=arch.cursor doname-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 notdata.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?
The text was updated successfully, but these errors were encountered:
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
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
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.
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?The text was updated successfully, but these errors were encountered: