Literal Patterns – JavaScript – SitePoint Forums

I was learning forms in HTML and had a set of javascript code needed (I think) to make the GET method work. I copied the javascript code and the error I got is that the template literal turns into a string for some reason.

html lang="en">



Back to form

To be honest, I have no idea what you want to achieve with your code.
Can you give more details about what you expect as output/result from your code?

For input tags to be functional I think. I’m not fully aware of the concept of this code as I had been learning javascript for about a month and then switched to HTML two weeks ago, so my knowledge is quite vague. I copied it because the guy told me to.

skip to 4:20 to see what I want to achieve.

I know this is an example from a tutorial, but in the real world never send passwords in a GET request. Intermediate proxies are allowed to cache GET requests, and you really don’t want that!


A case in point for why maintaining security standards is vital, even when it comes to sample code, comes from the recent zero-day attacks involving NGINX. They made the mistake of publishing an “LDAP reference implementation” that lacked proper security precautions, and later said that you should never use this reference implementation in the real world when people were using it.

You can read more about that in this week’s Show Notes podcast Security Now.

Things like that help reinforce for me that the “tyranny of the default” means people use it as is with little or no modification. Appropriate standards must be maintained throughout to help deal with this.


I see, I won’t do that.

Can you see why the template literals turn into a string? I copied his code, so I don’t understand half of the code.


Literal models use back-ticks (`) instead of quotes (‘) to define a string:

`Hello ${firstName}, ${lastName}!`


Form markup has a number of issues –

  1. The closure the label is just after the
    thus, none of the form fields, nor the submit button, are in the form.
  2. For a form field to include its data when the form is normally submitted, it must have a name="..." attribute. Only the ‘name’ field has one. The ‘password’ field does not.
  3. Each field must have a valid value type="..." attribute. The ‘name’ field has none, but the default is type=’text’. The ‘password’ field has an invalid type attribute, so its type is also text.
  4. The current default type=’…’ attribute for a is type=’submit’, but this has changed over time and some clients may not follow this standard. You must always specify type="submit" in the button’s tag when you use it as a submit button for a form.
  5. tags should either be bound to the field via an identifier, or simply wrap them around the field they belong to.

Unfortunately, these type of mistakes (no pun intended) happen when you’re just repeating things you’ve seen, without actually learning the meaning/requirements of what you’re doing. You don’t have the knowledge to find and fix problems when they don’t work, nor can you write original code based on what you’ve seen and can’t remember accurately. Writing code requires you to learn and internalize the meaning of keywords and syntax, so that when you write or read it, you can recognize when it’s good or bad, rather than relying on a past memory of what you think it should look like.


What do I use instead of GET?

You would use POST

Although you can no longer read these values ​​from query parameters. POST variables must be interpreted by some sort of script.

So as far as this example goes, it will only work with GET, not POST

1 like

James S. Joseph