Diary Of Insights: A Documentation Of My Discoveries

Introduction

Occasionally, as I work on projects, I discover things that I haven't previously encountered. I'm certain you've experienced similar moments during your own work.

I am starting this article to start documenting some of them. I'll continue to update the list as I encounter new insights or recall old ones. Feel free to subscribe [↗] to receive notifications whenever I make updates to this article.

This article will be expanded as I learn new facts. So subscribe [↗] if you would like to be notified when I update the list.

Now let's get into it.

HTML Element IDs VS Javascript global variables.

Whenever you add an ID attribute to an HTML tag this is converted into a valid variable name (not entirely accurate, don't @ me anywhere please).

Here is an example:


01: <p id="namedPTag">some text</p>
02: 
03: <script>
04:     console.log(window['namedPTag'].innerText, namedPTag.innerText) // some text some text
05: </script>

This might seem like a convenient way to access an HTML element in Javascript but the problem is this pollutes the Javascript global name space and you might not be aware.

If you have a variable with the same name there is a chance it could be overridden. Thankfully this handly happens since HTML is rendered first before any Javascript is executed, which means if you have a declaration with the same name in Javascript it will override the one generated by the HTML element ID


01: <p id="namedPTag">some text</p>
02: 
03: <script>
04:     var namedPTag = 'variable declaration';
05: 
06:     // references HTML element
07:     console.log(document.getElementById('namedPTag').innerText) // some text
08: 
09:     // references variable
10:     console.log(window['namedPTag'], namedPTag) // variable declaration variable declaration
11: </script>

So I would say this is one of the cases where you are safe even if you don't know this fact. To be safe though you can stick to using invalid variable names for your IDs. For example named-tag instead of namedTag

Example with invalid variable name
01: <p id="named-tag">some text</p>
02: 
03: <script>
04: // Its still there as a variable
05: console.log(window['named-tag']) // p#named-tag
06: </script>

As you can see on line 05 [→] it's still accessible as a variable but you should probably stick to query selectors to access them instead of using the window object.

Most backend will fail this validation test

It's standard practice to validate user input on the backend before processing or storing the data.

Validations range from checking if a user-provided email is of the correct format, to ensuring a user fills out a required field.

The latter is of interest in this section.

Let's say you have a form where a user is forced to provide a first name and last name or one field to collect both. This field is required and you check to make sure the user provides at least 3 characters.

As a user let's say I want to leave this field empty. Most backend validation implementations are good enough to detect if a user just types out spaces.

Let me introduce you to the Zero Width Non-Joiner [↗] character. This character has no visual form just like spaces and even better does not create any visible spacing.

When copied and pasted into most fields, it will be handled like most Unicode characters.

If the field has a minimum requirement of 3 characters, well pasting this character in three times will fulfill this requirement.

Here it is, go ahead and paste this into the name section of your LinkedIn profile and see what happens. (As of the time of writing this worked).

Zero Width Non
$ ‌

Fun fact: Introducing a Zero-Width Non-Joiner character is a fun way to mess with a developer's code.

Introducing this character into URLs however has very little effect as they resolve into an encoded format eg: (https://xn--0ug.com). Try it: https://‌.com [→].

One form two submit buttons

If you are familiar with the good ol structure of forms you know within the form body you typically have several input fields and a button that when clicked sends the value of all the input fields over to the server.

But did you know if you attached a name and value attribute to the submit button itself the name-value pair will be sent over to the server as an input?


01: <form method="POST" action="http://localhost:3000">
02:     <input name="name" placeholder="please enter your name">
03:     <button type="submit" name="submit-button" value="first button">Submit</button>
04:     <button type="submit" name="submit-button" value="second button">Submit 2</button>
05: </form>

The example above shows a form with two submit buttons and depending on which one you click the key an input value of either first button or second button will be sent to the server.

Of what use is this I hear you ask? Personally, I have used this to simplify form submissions when I have users with different roles.

For example, if you have a writer and admin user roles, typically you would identify who is submitting the form by adding a hidden field with a unique identifier i.e.: writer or admin well you can just have two submit buttons with the writer and admin values respectively and skip the hidden field altogether. On the backend, you will handle it just like you would with a hidden field.

Also, of course, you will only show the right button depending on which user is logged in.

𝕏 unicode

For anyone looking for a quick way to update their Twitter social links to the new logo, you should know that thge design is based on the Mathematical Double-Struck Capital X synbol which is available as a unicode:


01: 𝕏

Honey pot filter for form submissions

One of the annoying things about having a public form is the number of useless submissions you end up getting from spambots. The honey pot technique can help cut this down.


01: <style>    
02:     input[name="message2"] {
03:         display: none;
04:     }
05: </style>
06: 
07: <form method="POST" action="http://localhost:3000">
08:     <input name="name" placeholder="please enter your name">
09:     <input name="message2" > <!-- hidden field-->
10:     <button type="submit">Submit</button>
11: </form>

The idea is to throw in a hidden field (ideally hidden from the user using CSS instead of the hidden HTML attribute). Since a user can't see the field, they won't fill it out, on the other hand, bots are likely to fill them out. You can then ignore all submissions with that field filled out.

Bots with rendering enabled might be able to get around this since, the form will be rendered just like it would for a normal user.

Alternative to backspace/delete on the terminal

If your backspace/delete key ever dies on you, don't worry. Ctrl+h does the same job on the terminal.

And that's all I have for today. As mentioned at the beginning of the article I hope to expand on it as more of these things come to mind and you can follow along by getting notified [↗] when I expand the article.

Here is another article you might like 😊 "Converting Bootstrap 5 Styles To Tailwind (WIP)"

Tech Jobs | Newsletter [↗] 🗯️ Got a question? 🔗 Share on 𝕏