Improving the Javascript representer

Programming JavaScript
,
1

Starting a thread so I can have other more experienced people chime in on this.

the problem

Currently, the javascript representer doesn’t seem to mind quotation marks, ‘singe’ or “double”.
Since they’re used interchangeably in almost all scenarios, I’d like to maybe normalize quotation marks in a solution so there aren’t duplicate representations that only differ in quotes like this

export const twoFer = (name = 'you') => `One for ${name}, one for me.` //single
export const twoFer = (name = "you") => `One for ${name}, one for me.` //double
// these are functionally the same but are two different representations

the (eventual) solution

My rather simple and naive approach was/is to have a regex replace of all quotes in a solution with `backticks`, since nesting of different types of quotes works when using backticks.
The problem with that is the regex - currently I’m testing with this /\B'|'\B/g which is probably very far from ideal. I’m also doing the whole replacing before the file is given to the representer as an input, in the Bootstrap.call() method that I think prepared the inputs.

a better approach

Maybe finding out a way to change all Literals to TemplateLiterals in the AST would be a better, or at least more consistent approach, but I’m not that confident manipulating the AST yet.

feedback?

Well, any feedback is appreciated. Do you think any of the approaches will work or can you suggest something different? Also, a better regex suggestion?

2

I’d be quite hesitant to use regular expressions, as it is very hard to get them right. Using the AST should be the way to go, although I’m not sure you want to convert Literals to TemplateLiterals. I think you “just” want to normalize the regular literal (either 'you' or "you") and leave the template literals untouched. Right?

3

My idea was to just normalize all double and all single quotes in the solution to backticks, since this way I’m avoiding the obvious elephant in the room that is nesting.

Then to pass it to the AST parser, so I wouldn’t have to change any of those bits, since my knowledge of ASTs and AST parsing is limited at best.

EDIT: By all quotes, I mean all matched opening and closing quotes, so things like single quotes in the middle of a word won’t count

4

Right. I’d still prefer it if this was done via the AST, as I think it might be hard to get this right via a regex.

5

Okay, so upon closer inspection, there might be a way to do it with the AST, at the step where it’s converted back to code. I’ll read into it more.

On the actual normalization tho, what should get normalized and to what? I’m currently thinking about this:

  • Either ‘single’ quotes get normalized to “double” when they enclose a string
  • Or all quotes get normalized to `backticks` when they enclose a string
  • Or should there be an option for the representer to just pass it whatever kind you want to use
6

I believe I got it working.

Turns out that the astring library used to turn the AST back into code can be easily extended with custom generation functions for different types of Nodes.

I made a custom generator that takes the parsed value of a Literal type node and encloses it in `backticks`. Seems to work okay.

If there’s any maintainers of the repo here, may I get your review on this PR?

1 Like
7

Exciting! I imagine it’ll be @ErikSchierboom as DJ isn’t around atm.

8

Thanks for the time and patience @ErikSchierboom
PR merged!

Now, I suspect the representer might need to be ran again for new representations to everything, but I dare not ask

1 Like
9

It will! One for @ErikSchierboom come Monday :slight_smile:

(@ErikSchierboom Bash an extra 20 servers on again to get through it, and remember to run in background :slight_smile:)

10

I was kind of wondering if the typescript representer might need the same treatment but that’s a task for another day, I suppose.

1 Like
11

If anyone still follows this, I’ve opened this topic for TS. The discussion there might be interesting for JS as well (I’m suggesting three additional transformations and explain why I would prefer to take a different approach to what has been done in JS).

Happy to chat ;-)