6

I have the following statements in my Lightning component's Javascript controller:

console.log(/.*/.test("asd")); // prints "false"
console.log(/(.*)/.test("asd")); // prints "true"

When I run the exact same commands in the browser's console, they both print true. Of course, since they're semantically the same.

What is happening?

Improve this question
4
  • When I check your RegEx at regexr.com, it doesn't show up as being valid; (particularly the last backslash) unless JS uses a backslash instead of a forward slash as an escape; which doesn't appear to be the case based on the rest of your RegEx pattern.
    – crmprogdev
    Feb 27, 2017 at 13:52
  • @crmprogdev The backslashes are indeed Javascript escape characters and used to escape the literal forward slashes, as forward slashes are regex delimiters in Javascript. The expressions work fine when I test them at regexr.com. Could you clarify?
    – neonblitzer
    Feb 27, 2017 at 16:02
  • I hadn't replaced the outer parens with square brackets, so it does indeed show as being valid. I did also see something at developer.salesforce.com/docs/atlas.en-us.lightning.meta/… which might apply. Not all JS can be used within lightning components. This may be one of those use cases. You may want to install the linter and check.
    – crmprogdev
    Feb 27, 2017 at 16:07
  • See below... It even mangles it inside a string.
    – Charles T
    Sep 15, 2017 at 16:01

4 Answers 4

Reset to default
8

The reason for this seems to be that the framework replaces the first line's asterisk character with the \u002A Unicode escape sequence before serving the files to the browser.

I'd report a bug if it was possible. Hopefully someone here can raise the issue!

Improve this answer
2
  • I don't have any idea why the framework would escape characters in Javascript outside of strings. Or why the parentheses stop it. Seems like overzealous XSS prevention.
    – neonblitzer
    Mar 2, 2017 at 14:09
  • I've had strange outcomes too - take a look at this one which is now solved but at the time was very puzzling. salesforce.stackexchange.com/questions/127150/…
    – Charles T
    Sep 15, 2017 at 15:58
3

Ye, as you mentioned it is framework's doing. For some reason it converts asterisk in case it is immediately followed by a slash:

new RegExp(/.*/)

would result as

new RegExp(/.\u002A/)

And the parenthesis removes the "immediately followed" situation.

Improve this answer
1

Check out how it even mangles a string...

console.log('/.*/');
console.log('/(.*)/');
debugger;

This logs correctly (because those are JS escape sequences) but the debugger call reveals it's been changed to: console.log('/.\u002A/')

I had a similar issue here which has been resolved but evidently yours hasn't: String literals with {} braces may get mangled in Lightning JS

Improve this answer
1
  • 2
    That being said, if you construct it with RegExp instead, new RegExp('.*'), then the escaping Lightning does won't hurt you anymore.
    – Charles T
    Sep 15, 2017 at 16:05
0

Has this question ever been resolved? I am having the same problem developing a component for the Lightning console.

var regex = new RegExp('.*', 'i');

gets converted to:

var regex = new RegExp('.\u002A', 'i');

It seems to however be creating the regex correctly, 

console.log(regex)
> /.*/i

but while debugging the code it can really throw you off.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.