Introduction

Blogs need to display publishing time, restaurant websites need to display reservation time, and auction websites need to display various order times. No matter what you do, you will encounter the very common need to display time.

This problem seems simple, just display the time, right? But if it involves “time zones”, the problem will become even more complicated. Regarding time zones, there are usually several requirements:

1. The time on the website needs to be displayed in a fixed time zone. I want to see the same time on the website whether I am in the United States or in Taiwan.
2. The time on the website will be different according to the user’s browser settings. I will see different times in the United States and Taiwan.
3. PM did not consider this issue and only considered local users, so there is no need to worry about this for the time being.

And this is only the display part. There is another part that communicates with the backend. We can talk about this later, but in any case, correctly handling time and time zones is not a simple matter.

I have recently encountered related issues in one or two jobs, so I have a little experience in this area and wrote this article to share with you.

Read More

Introduction

Recently, my colleagues at work took a course on information security. As I was already interested in information security, I discussed it with my colleagues, which led me to research related topics for the past two weeks. These were things I had heard of before but had not studied seriously, such as LFI (Local File Inclusion), REC (Remote code execution), SSRF (Server-Side Request Forgery), and various magical filters in PHP. I also reviewed SQL Injection and XSS, which I was already relatively familiar with.

In CTF challenges, situations often arise where you need to bypass various restrictions, which is an opportunity to test your understanding of specific protocols or programming languages. You have to think about how to find at least one way to successfully bypass those restrictions under existing limitations.

Originally, I didn’t know what to write about this week. I wanted to write about the things mentioned above, but I hadn’t figured out how to organize them yet. The follow-up series of “I Don’t know React” was not yet organized, so I thought it would be fun to do a little challenge related to “bypassing restrictions” with everyone. That is:

In JavaScript, can you successfully execute console.log(1) without using letters and numbers?

In other words, no English letters (a-zA-Z) or numbers (0-9) can appear in the code. Everything else (various symbols) is allowed. After executing the code, console.log(1) will be executed, and 1 will be printed in the console.

If you have thought of any interesting services or libraries that can do this before, don’t mention them yet. Before that, you can think about it yourself and see if you can write it out, and then check other people’s solutions.

If you can write it all by yourself from scratch, it means that you should be quite familiar with the JS programming language and various automatic type conversions.

Below, I will provide some of my own thoughts and the process of solving this problem. There are spoilers, so don’t scroll down if you haven’t solved it yet.

== Spoiler Alert ==
== Spoiler Alert ==
== Spoiler Alert ==
== Spoiler Alert ==
== Spoiler Alert ==

Read More

Preface

Note: Currently, this blog has problems supporting JSX syntax, so it may not be easy to read the code. I will fix it as soon as possible.

This title pays tribute to a series of books that people who write JavaScript have heard of even if they haven’t read them: You Don’t Know JS by Kyle Simpson. It talks about many things about JS that many people don’t know.

And I don’t know React is a series of records I made for myself, recording some React that I don’t know, and these articles are summarized from my experience using React. Some of the errors I have encountered may be very basic and common (just like those written in the official documents, but I didn’t read them carefully, so I don’t know), and some may be relatively rare (I may encounter them only after writing for three or four years at work).

In other words, the spirit of writing this series is different from YDKJS. The former wants to tell you some things about JS that few people know, and it feels like “I will teach you how to write JS”. The reason why I wrote this series called “I don’t know” is because I want to use a series of articles to record the misunderstandings or omissions I have encountered when writing React, and what is the correct answer.

I don’t know how many articles this series will have. I will post an article every time I make a mistake. There is a big difference in this series that I think is quite large. I will try to provide the scene where the mistake was made at the beginning of the article, so that everyone has the opportunity to debug before seeing the answer and see if they can find out where the error is. I think this is actually the most essential part. This is not a standardized interview question, nor is it a React quiz randomly found on the Internet, but a real situation I have encountered at work.

Because I want everyone to immerse themselves in the situation as much as possible and think about the problems I have encountered, there will be a lot of space for “defining and reproducing problems”. If you are not interested in finding answers yourself, you can also skip this part and go directly to see the answer. But I personally recommend that you try to debug it yourself first, find out where the problem is, and then come to see the answer in the article, so that you can fully absorb what the article wants to express.

Anyway, let’s take a look at the case we want to talk about in this article!

Read More

Introduction

Recently, I came across an article on the front-end community on Facebook: Understanding React useEffect 02, which discusses the usage of useEffect. There was also some discussion in the comments section.

Initially, I found the usage in the article a bit strange, but I could somewhat understand why it was written that way. However, I still found it odd. I wanted to leave a comment, but then I thought, “Maybe I’m the one who’s mistaken,” so I decided to think about it some more. After careful consideration, I realized that I was the one who was mistaken.

Therefore, in this post, I will share my thoughts. If there are any mistakes, please feel free to leave a comment below or discuss it with me in the front-end community. Before continuing to read, I recommend reading the original article and the discussion below it to better understand the context.

Read More

Introduction

If you want to store something in the front-end of a website, which means storing it in the browser, there are basically a few options:

1. Cookie
2. LocalStorage
3. SessionStorage
4. IndexedDB
5. Web SQL

The last two are rarely used, and the last one, Web SQL, was declared deprecated a few years ago. Therefore, when it comes to storing data, most people mention the first three, with the first two being the most commonly used.

After all, when storing data in the front-end, most data is expected to be stored for a period of time, and cookies and localStorage are designed for this purpose. However, sessionStorage is not, as it is only suitable for storing very short-term data.

I don’t know if your understanding of sessionStorage is the same as mine, so let me explain my understanding:

The biggest difference between sessionStorage and localStorage is that the former only exists in one tab. When you close the tab, the data is cleared, so a new tab will have a new sessionStorage, and different tabs will not share the same sessionStorage. However, if it is the same website, the same localStorage can be shared.

But let me ask you this: Is it possible that in a certain scenario, I store something in sessionStorage in tab A, and then a new tab B can also read the sessionStorage in tab A?

You might think it’s impossible, and I used to think so too, as did my colleagues.

But it turns out that it is possible.

Read More

Introduction

Have you ever heard of vite? With a name starting with “v”, you might guess that it’s related to Vue. Yes, it’s another tool developed by the creator of Vue, Evan You. Originally intended for use with VuePress, it has proven to be much more versatile.

On the GitHub page for Vite, there are only two sentences:

Native-ESM powered web dev build tool. It’s fast.

If you’ve tried it, you’ll know that it really is fast. Vite is a combination of a build tool and a dev server. In this article, we’ll briefly introduce how to use Vite, then talk about ES modules, and finally explore the magic of Vite.

Read More

Introduction

While making some performance adjustments at work, I accidentally discovered a strange phenomenon. After investigating further, I found a bug that seemed to have gone unnoticed by anyone, and I found the cause quite interesting. So I thought I’d write a post to share it with everyone.

This post is not very technical, so you can read it with a story-telling mindset, which will make it more interesting.

The Beginning of the Story

The origin of the story is that I was making some adjustments to a website at work, trying to improve its loading speed. When it comes to performance optimization, there are many things that can be done. For example, with regard to the server, the following are more relevant:

1. Use HTTP/2
2. Use gzip or brotli for compression
3. Use Cache (to speed up revisits)
4. Use CDN
5. Reduce TTFB time

However, all of the above require assistance from the backend or SRE, and are not very relevant to the frontend. With regard to the frontend, there are many aspects to consider. For example, from the perspective of “reducing resources,” the following can be done:

1. Image format adjustment (compression + webp or other formats)
2. JS size (ugligy, code splitting, dynamic import)
3. CSS size (minify, remove unnecessary CSS)

From the perspective of “accelerating the loading of important resources,” preload or preconnect hints can be added to indicate to the browser which things should be loaded first.

You can also look at it from the perspective of “reducing JS execution time.” For example, if you are writing React, you can use shouldComponentUpdate, PureComponent, or memo to reduce unnecessary re-renders.

Since the title of this post is “styled components,” the main topic is, of course, centered around CSS.

Read More

Introduction

To learn something new, it’s not very useful to just read about it. The best way is to get your hands dirty and start doing it. Since React hooks had just come out when I was about to leave my previous job, I had never written hooks before, only seen some basic tutorials. But after starting my new job, I finally started writing function components + hooks.

Although I initially missed the class syntax, I found hooks to be quite good after writing them for a while. In the process of using hooks, I also encountered some common problems that people who are new to them often face. After careful study, I found that the case I want to discuss in this article is quite good. If you can understand this case, you should be able to grasp the fundamental differences between class and function components. Therefore, I wrote this article to record my experience.

By the way, if you have been writing function components for a while, are quite used to hooks, and have read the official documentation and Dan Abramov’s articles carefully, you probably won’t gain any new knowledge from this article. This article is suitable for those who have just switched to function components and are not sure what the differences are between them and class components.

Read More

Introduction

Recently, I came across a great tutorial on Regular Expressions for Regular Folk, which is well-written and beautifully designed. Since Regular Expressions are commonly used in development, but not covered in my course, I decided to write a simple article on this topic.

This article is intended for beginners who have no idea what Regular Expressions are. Therefore, the explanations will be relatively simple, and the examples will be relatively easy to understand. The patterns will also be relatively fixed, with fewer boundary conditions to consider, making it easier to learn.

Alright, let’s get started!

Read More

Introduction

If you have written functions in other programming languages that are not first-class, you may experience some pain when writing JavaScript and wonder what you are doing - at least that’s how I feel.

When I first discovered that functions can be passed around as parameters, I had to think hard about more complex code, and other behaviors of functions also confused me, such as the fact that functions are also objects, and what exactly is this.

This article mainly wants to share some interesting aspects of functions. However, it is too boring to start talking about a lot of knowledge directly. I hope to arouse everyone’s curiosity about this knowledge. The best way to arouse curiosity is to provide a “question that you will also be interested in”. You will have the motivation to continue reading.

Therefore, the following uses a few small questions as the opening. Although they are in the form of questions, it doesn’t matter if you can’t answer them. If you are interested in the answers to these questions, please continue reading. If you are not interested, just go straight ahead and turn left at the end.

By the way, the title of this article was originally intended to be called “How much do you know about JavaScript functions” or “Interesting JavaScript functions”, but these titles are too boring, so I thought of this light novel-style (?) title.

Read More