host: Add handling for Unicode in file/class names #1198
Conversation
This seems like it might create chaos…!
Can’t the display name be left alone? And minimally processed to produce the class name?
This should let us more easily know whether encoding is or isn’t present.
This reverts commit d663797.
|
Shall we put a default classname, when all characters are invalid, eg 123. EDIT: Actually, I can also see how this is also confusing. Ideally, we wud just put the modal in an error state using some input validation. Im impartial atm. I think it is ok as is |
| function convertToClassName(input: string) { | ||
| // \p{L}: a letter | ||
| let invalidLeadingCharactersRemoved = camelCase( | ||
| input.replace(/^[^\p{L}_$]+/u, ''), | ||
| { pascalCase: true }, | ||
| ); | ||
|
|
||
| let className = invalidLeadingCharactersRemoved.replace( | ||
| // \p{N}: a number | ||
| /[^\p{L}\p{N}_$]+/gu, | ||
| '', | ||
| ); | ||
|
|
||
| // make sure we don't collide with a javascript built-in object | ||
| if (typeof (globalThis as any)[className] !== 'undefined') { | ||
| className = `${className}0`; | ||
| } | ||
|
|
||
| return className; |
There was a problem hiding this comment.
have you considered using lodash.deburr. i think it might do the thing we want here https://lodash.com/docs/4.17.15#deburr
There was a problem hiding this comment.
I wanted to preserve the accented characters etc, which that strips out. That’s also why I switched away from Lodash’s camel-casing function, because it does the same. I looked all over for something that would sanitise to produce valid identifiers but I couldn’t find a package 😞
hmm well if you use 
So it does seem like something to protect against, thanks 🤔 |
This fixes file creation to support characters that are valid as part of file and identifier names that were previously being stripped. It also leaves the display name alone.
Since URL handling and display is scattered across the application, this introduces a convention for consistency:
…/hébecomes…/h%C3%A9LocalPath) it’s the result ofdecodeURIThis does mean that conversions from URL to string need to include that, if we find that it’s not being used properly, we can look into how to enforce it more consistently, maybe with a type. But
RealmPathsnow only accepts URLs which should help facilitate this.