It's gonna be a long article with many boring things all about me, I believe it's fair to think that some of you just want to see my portfolio. So here you go:
* [Old version](https://khang-nd.github.io/)
* [New version](https://khang-nd.vercel.app/)

----

So, after 2 years in the software industry, I officially hit the first milestone of pursuing my passion for front-end development. I was offered the front-end developer role at an [Australia-based company](https://unios.com/) at the beginning of this year. It was a pleasant coincidence for which I neither searched nor applied for the role I was offered, and the guy who reached out to me was neither an HR nor recruiter, he was a fellow developer who was simply impressed by my silly [pet](https://github.com/khang-nd/7.css) [projects](https://github.com/khang-nd/win7). He is now a colleague and a senior who is always supportive and proactively helps me out in my work. And even better, the working culture here is surprisingly flexible and respectful, I have full control over my time and save a lot of commuting cost and time, as I'm working remotely from home, connecting with the Aussie team via MS Teams, or whenever I feel like to, I'm always welcome at the local office in Vietnam. Lucky me!

Anyway, that was a little bit sharing of my current status, and you may be wondering, why the hell did I rebuild my portfolio if I wasn't looking for a change of job? Yep, that's a valid question, I rebuilt my personal portfolio website after 2 years, not to impress the recruiters, not to find a new job, but to pick up the new tech stack I use at my current job, a whole lot of things that I have never used before, and because it's enjoyable. So in this blog post, I would like to share with you the experience, and of course, to show off the [final product](https://khang-nd.vercel.app/) which I feel so proud and happy to realize how far I have progressed with my skills 😊.

## A little bragging/motivation

Back when I joined DEV community in late October of 2020, I made my entrance by leaving a comment on the 96th Welcome Thread to introduce myself with my portfolio.

{%embed https://dev.to/khangnd/comment/173o9 %}

And it turned out, people enjoyed my portfolio, [the github repo](https://github.com/khang-nd/khang-nd.github.io/tree/v1) received around 20⭐, my comment received the most ❤ reactions at that time, and in the end, I was awarded the [Beloved Comment badge](https://dev.to/badge/beloved-comment). Totally unexpected, I was super excited, what an epic entrance I had!

![Davie504 Epico](https://c.tenor.com/wCUmKO7goKcAAAAC/davie504-epic.gif)

But yeah, that's that. Just to say I built the first version of my portfolio nearly 2 years ago, and again, it was not to impress the recruiters as I was already working at my [former company](https://www.bosch.com/), but rather, I was learning React and tried to find something to practice its fundamental concepts. I had no experience with React prior to joining that company, all I knew was HTML, CSS, JS, and some jQuery, just basic stuff huh. React at that time was something foreign, something fancy to me. In fact, even during the whole time I worked at the former company, we rarely needed to build anything that was complex enough to apply any library or framework, other than jQuery, as most of those things we worked on were just automation scripts and simple plugins. But anyhow, we were still allowed the freedom to apply any new library/framework we preferred in our work per our team's competency skills development policies. And that was the motivation for me to build my first portfolio in React.

Now at the new workplace, in the role I have been yearning for, having a chance to build UI stuff from the beautiful designs prepped by a strong and professional design team, I'm really enjoying myself here. However, at the same time, I also feel overwhelmed, due to the fact that those 2 years of experience I had barely fit in the new workplace. I'm now helping build a bigger thing, using more advanced and complex web techs, minding about responsiveness and accessibility while sticking to the designs. All brand new experience to me, which is why I need to keep striving, little by little, and the idea of rewriting my portfolio from scratch using the same tech stack the project is using is part of the effort (FYI, our project is using React/NextJS, TypeScript, Theme UI, Framer Motion for the front-end, Storybook for component documentation, and PostgreSQL as the database, Strapi, Prisma, GraphQL for the back-end, and dozens of other packages). Therefore, for this second incarnation of my portfolio, I applied [NextJS](https://nextjs.org/), [TypeScript](https://www.typescriptlang.org/), [Theme UI](https://theme-ui.com/) and [Framer Motion](https://www.framer.com/motion/).

## The process and experience

[Getting started with NextJS](https://nextjs.org/docs/getting-started) was simple and straightforward, just like any other frameworks whose existence is to ease our life as developers. With just a few commands, I got the all the necessary stuff up and running.

[TypeScript](https://nextjs.org/docs/basic-features/typescript) came integrated with NextJS, I didn't have to worry about anything like the steps to set up or config TS. By enabling the `--ts` flag in the `create-next-app` command, NextJS did all the necessary stuff, simple as that.

Deciding the file/folder structure is probably not a bothersome thing to consider for this kind of project, if not worthless. But still, as someone who prefers things organized and tidy, I did spend quite some time looking up guidelines, best practices and some reference resources. In the end, this is the final structure as of this writing:

![Winport's project structure](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/a8qlqchfpammsoolup5t.png)

For simplicity, the direction I went for was **file separation by types**, React components were placed in the `components` folder, hooks grouped together in the `hooks` folder, contexts in `contexts` and so on. Anything else that didn't make sense to group with the others was dumped in `misc`. The `components` folder was further divided using [Brad Frost's Atomic Design method](https://atomicdesign.bradfrost.com/chapter-2/). I can imagine this is a subjective matter with a never-ending argument when working in a team, as even if it was just me with this project, I still had trouble being firm and decisive and sometimes ended up moving files around. I suppose [**this**](http://react-file-structure.surge.sh/) makes so much sense after experiencing it myself. All in all, my takeaway is that just pick one template/boilerplate of a project with the same type as yours (there are plenty out there) and get right onto it, or don't waste time defending your ideal if it's not a big deal or causes major refactoring. We have 💩 to do, a lot of it.

Working with TypeScript turned out to be surprisingly pleasant. Surprising in a sense that I actually have learned and tried static-typed languages before (Java, C# back in the days I was still in college) and didn't quite like those languages due to their complexity from my **personal** perspective. I grew attached to JavaScript after learning about web dev as it offered the freedom to define and use variables in any way I wanted, I didn't have to worry about what type I should assign or no longer the nightmares of trying to understand the concepts associated to those static types (OOP, polymorphism, abstraction, anyone?). I guess at that point, my brain was not mature enough to accept them as well as the great advantages they bring. As a result, I never expected that I would come back to like static type one day. However, TypeScript changed my mind, the longer I worked with it, the more benefits I could realize and enjoy. There are just way too many benefits that I could easily get obsessed with. But again, this is still my **personal** experience, it may not be the case for everyone, the key takeaway is that, to learn and realize the benefits of something fully and thoroughly, the only way is to see it for yourself, experience it, and feel.

[Theme UI](https://theme-ui.com/getting-started/) was an awesome toy to play the "organized" game. All the styling variables, such as spacings, sizes, colors, breakpoints were centrally defined in [one place](https://github.com/khang-nd/khang-nd.github.io/blob/main/src/themes/index.ts) and they could be used across all our components, making a constraint to enforce the consistency. Even better, the almighty [`sx` prop](https://theme-ui.com/sx-prop) brought a lot of benefits, such as inline styling for our components, and made the pain of coming up with the class names disappear. And as the name implies, Theme UI is perfect for, you know, [theming the UI](https://theme-ui.com/theme-spec), it was designed for that and did that job flawlessly. It supported dark/light mode out of the box and offered the hooks to manipulate the color modes so easily. However, my portfolio was slightly unique in the way that it offered several different themes that didn't simply rely on the color mode, but also on some features of the UI.

| Flat | Soft
|----|----
|![Flat theme](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ksdbpfugmrvygkupy4pc.png) | ![Soft theme](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0n1er1xc5wve7gxms0g2.png)

_The Flat theme has the navigation link in a square shape, while the Soft theme has it mildly rounded with some shadow shades_

To solve this, I made a super simple hook that validated the current theme and use it to style the component correspondingly as below:

```ts
// useMatchTheme
import { useContext } from "react";
import { GlobalContext } from "../contexts/GlobalContext";
import { ThemeMode } from "../themes";

export default function useMatchTheme(target: ThemeMode) {
  const { theme } = useContext(GlobalContext);
  return theme.val === target;
}
```

```ts
// NavLink.tsx
const linkStyle: ThemeUICSSObject = {
    bg: "primary",
    color: "textReverse",
    display: "flex",
    // some more styles here

    ...(useMatchTheme(ThemeMode.Soft) && {
      fontSize: isHomePage ? "2px" : "1px",
      borderRadius: "10%",
      boxShadow: (theme) => `inset 3em 3em 3em rgba(255, 255, 255, 0.5), 1em 1em 4em 3em ${theme.colors?.shadow}`,
    }),

    ...(useMatchTheme(ThemeMode.Classic) && {
      fontSize: isHomePage ? "2px" : "1px",
      borderRadius: "8%",
      boxShadow: "inset 0 0 0 2em #000, 3em 3em 0 #000",
    }),
  };
```

[Framer Motion](https://www.framer.com/docs/introduction/) was another animation library designed specifically for React and it did it job really well. It was a little tough to get a hang onto at the beginning since I had little experience with React and literally zero experience with any animation library. But once I got a hang of it, I absolutely loved it. The animations are super clean and realistic, I guess it was thanks to these so-called spring and bouncing physics (don't talk to me so deep into Math 😢). The API was simple to use as well as the good documentation with practical examples. (Staring at the old animations in my old porfolio, so fkn 💩). What made Framer Motion even more extreme, from my experience, were these [Layout animation](https://www.framer.com/docs/animation/#layout-animations) which manipulated the animations on components as if they transitioned from one position to another, and [AnimatePresence component](https://www.framer.com/docs/animate-presence/) which allows animations on components as they were removed from the React tree.

![Magic](https://i.pinimg.com/originals/73/e5/53/73e55358e7b0703f20602b01b408e9e6.gif)

As the goal at the beginning was simply to apply a different tech stack to rebuild my portfolio and learn a thing or two out of it, I didn't want to deviate much from the existing core design, but in the end, I felt that there could have been a lot of improvements from the old version, so I think it's interesting to share the look of those differences:

| Old | New
|---  | ---
|![Flat old](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/c5setkk5r8vv0a827831.png) | ![Flat new](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/yb0i052968qmo2oisypo.png)
|![Neumorphism old](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4casxddwzs04npx47pw3.png) |![Soft new](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/yex2z4g3cjhlku1wx5mv.png)
|![Classic old](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zo3od84unipobzchv55p.png)|![Classic new](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/n084yvdvii1ehccb0mdo.png)
|![Old config panel](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qaaexff0c1961udu1pf1.png)|![New config panel](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/itsuny7wcj9wj52kjnwu.png)

Aside from the improvements on how it looked. There were a couple of other improvements behind the scene, including accessibility, new config options (hide taskbar, reduce motion), hiding the config panel on unfocused, and an entire Blog section which pulls the article lists from my contributed blogging platforms using their public APIs.

## Final words

I've got a confession to make. All of this blog was just to _brag_ about my new portfolio, to make a big fuss out of it as I invested a lot of my spare time doing it 😋 But I still hope it's  helpful and somehow serves as an inspiration for your new portfolio or your next one. Thank you for reading.

* [Old version of my portfolio](https://khang-nd.github.io/) ([source code](https://github.com/khang-nd/khang-nd.github.io/tree/v1))
* [New version of my portfolio](https://khang-nd.vercel.app/) ([source code](https://github.com/khang-nd/khang-nd.github.io/))

It's gonna be a long article with many boring things all about me, I believe it's fair to think that...

showdev

I rebuilt my portfolio after 2 years

Khang

Have you ever failed to understand how the percentages work in CSS? Ever wondered why it's so messed up and has zero logic sometimes? Well, I do. That's why I'm writing this post to share my understanding through my researches and readings with you.

## Percentage of what?

As a percentage, obviously there should be a target taken as a reference source. Most answers to this are the **parent block** of the element we assign the percentage. This is correct, but does not entirely cover all the cases. The most correct answer should be the **containing block**, meaning the block that contains our element and it doesn't have to be the direct parent.

Let's take a look at the below example:
{% codepen https://codepen.io/khangnd/pen/powbjEL %}

In this example, I created 3 nested `div`s, which are 3 squares with the following characteristics:

* The outmost **grandparent** div has a lightgray color with a size of **4x4**
* The **parent** div has a darker gray with a size of **2x2**
* And the red **child** div which I assigned the size of **50%**

If the percentage unit took the **parent** as the source, the size of the **child** should have been 1/2 of it, but no, the **child** actually has the size equals to the **parent** and 1/2 of the **grandparent** as you can see. The reason is the **grandparent** div is the true **containing block** of the **child** div, due to the fact that the **child** has `position: absolute`, corresponding to `position: relative` I have set in the **grandparent**.

Therefore, to identify which is the actual **containing block** of an element, it's entirely based on the `position` property of the element itself. *You can read more on [MDN](https://developer.mozilla.org/en-US/docs/Web/CSS/Containing_block#identifying_the_containing_block).*

However, for certain properties, the reference source for the percentage unit is neither the *parent* nor the *containing block*, instead, it is itself - **self element**.

## Percentage by property

### `width`/`height`

Pretty straightforward, as you have seen in the example above, when an element is assigned a percentage value to its `width`, the `width` of the **containing block** is taken as the reference source. Likewise, `height` of the element refers to the `height` of the **containing block**.

### `padding`

For `padding`, either vertical (`padding-top`/`padding-bottom`) or horizontal (`padding-left`/`padding-right`) refers to the `width` of the **containing block**.

Example:
{% codepen https://codepen.io/khangnd/pen/YzQWWRG %}

In this example,

* The **parent** div has a size of **6x4**.
* The **child** div has a size of **0**, but with `padding-top` and `padding-left` given **50%**

The result is that the **child** has a size equivalent to 1/2 `width` of the **parent**, which is a **3x3** square.

### `margin`

Similar to `padding`, the percentage of `margin` (both vertical and horizontal) refers to the `width` of the **containing block**.

Example:
{% codepen https://codepen.io/khangnd/pen/MWoejWd %}

In this example,

* The **parent** div has a size of **6x4**.
* The **child** div with `margin-top` and `margin-left` given **50%**

The result is that the **child** is positioned **3** units away from the top and left margins of the **parent** (1/2 `width` of the **parent**).

### `top`/`bottom`/`left`/`right`

For these properties (usually come with `position`), the vertical ones (`top`/`bottom`) refer to the `height` and the horizontal ones (`left`/`right`) refer to the `width` of the **containing block**.

Example:
{% codepen https://codepen.io/khangnd/pen/MWoerzw %}

In this example,

* The **parent** div has a size of **6x4**.
* The **child** div has `position: absolute` with `top` and `left` given **50%**

The result is that the **child** div is positioned **2** units away from the **parent**'s top edge (1/2 `height` of the **parent**), and positioned **3** units away from the **parent**'s left edge (1/2 `width` of the **parent**).

### `transform: translate()`

An incredible property for animation/transition, it also supports percentage value. However, this one does not refer to its **containing block**, but instead refers to **itself**.

Example:
{% codepen https://codepen.io/khangnd/pen/QWgEQvy %}

In this example,

* The **parent** div has a size of **6x4**.
* The **child** div has a size of **2x1** with `transform: translate(50%, 50%)`

The result is that the **child** div is positioned **0.5** unit away from the **parent**'s top edge (1/2 `height` of **itself**), and positioned **1** unit away from the **parent**'s left edge (1/2 `width` of **itself**).

### `background-size`

The `background-size` property brings the complexity of percentage unit to a new level 😄
The percentage value of this property now refers to the **background positioning area**, which I interpret as similar to the **containing block**, but with an addition of these 3 factors:

* Block with only content (`content-box`)
* Block with content and padding (`padding-box`)
* Block with content, padding and border (`border-box`)

The 3 factors are given by the `background-origin` property. **You can read more on [MDN](https://developer.mozilla.org/en-US/docs/Web/CSS/background-origin).**

Example:
{% codepen https://codepen.io/khangnd/pen/rNwLdMZ %}

In this example,

* The **parent** div has a size of **6x4**.
* The **child** div has a size of **3x2**, no `padding`, no `border`
* I used a DEV logo (with the ratio of a square **1:1**) as a `background-image` for the **child** div, with the `background-size` property set to **50% 50%**

The result is that the background image has been stretched to have a size of **1.5x1**, corresponding to 1/2 size of the **child**.

### `background-position`

Similar to `background-size`, the percentage of the `background-position` property also relies on the **background positioning area**.

Example:
{% codepen https://codepen.io/khangnd/pen/JjJKLaP %}

In this example, the same image and layout was used as the previous. As we changed the value of `background-position`, some observations we can see:

* Without any value (by default, the value is `0 0`), the background image is positioned at the **top left** corner.
* With `background-position: 0 50%`, the background image is positioned **left center**.
* With `background-position: 50% 50%`, the background image is positioned in the **center**.
* With `background-position: 100% 100%`, the background image is positioned **right bottom**.

> **Note**: `background-position: 0 50%` is equivalent to:
>
> * `background-position-x: 0`
> * `background-position-y: 50%`

Apparently, there are some calculations behind the percentage of this property, instead of just the distance between the image's top and left edges to the **child**'s. Through some researching and testing, it appears that the `background-position` property relies on the following calculation before yielding an actual value:

> offset X = (container's width - image's width) * background-position-x
>
> offset Y = (container's height - image's height) * background-position-y

In this case, with

* *container* as the **child** div
* *image's width/height* is the resulting size of `background-size`

### `font-size`

For `font-size`, the percentage value solely refers to its direct **parent block**.

Example:
{% codepen https://codepen.io/khangnd/pen/MWoeXMO %}

In this example, I use the same layout as the very first example, with the `font-size` assigned as below:

* **13px** for **grandparent**
* **26px** for **parent**
* **50%** for **child**

As a result, we can clearly see that the `font-size` of the **child** is now equivalent to the **grandparent** and is 1/2 of the **parent**, ignoring the fact that the `position: relative` is assigned to the **grandparent**, not the **parent**.

### `line-height`

While might not be as popular, I also mention this property as it also supports percentage. The percentage value of `line-height` relies on the `font-size` of **itself**.

Example:
{% codepen https://codepen.io/khangnd/pen/oNwLMXR %}

In this example,

* The paragraph has **11** lines
* `font-size` is set **20px**
* `line-height` is set **150%**

The actual `height` of the whole block is **~329px**,

* The `line-height` in this case is: 20 * 150% = **30px**.
* The `height` is then: 30 * 11 = **330px**, approximate to the actual `height`.

## Takeaways

Hope the article cleared up some of your understanding regarding the **percentage value** in CSS instead of making things worse 😅

I also tweeted a cheatsheet to summarize what is written so far, maybe it will come in handy to remember the meanings at first:

{% tweet 1433999937365164032 %}

And this is a collection of all the examples in the article: https://codepen.io/collection/xKwgdW

## References

* [Containing block (MDN)](https://developer.mozilla.org/en-US/docs/Web/CSS/Containing_block)
* [Percentage (MDN)](https://developer.mozilla.org/en-US/docs/Web/CSS/percentage)
* [Background position's percentages (MDN)](https://developer.mozilla.org/en-US/docs/Web/CSS/background-position#regarding_percentages)
* [What are CSS percentages? - Jim Fisher](https://jameshfisher.com/2019/12/29/what-are-css-percentages/)
* [What does 100% mean in CSS? - Amelia Wattenberger](https://wattenberger.com/blog/css-percents)

Have you ever failed to understand how the percentages work in CSS? Ever wondered why it's so messed...

Understanding CSS Percentage


Hello everyone, welcome to another article in the series [Let's build something!](https://dev.to/khangnd/series/11440), a series dedicated to building, well, *something* that involves several techs (techniques and technologies) mostly in JavaScript. In this article, I would like to share my first experience building a desktop app with [Electron](https://www.electronjs.org/) (with the support from [Electron Builder](https://www.electron.build/)) and [Svelte](https://svelte.dev/). If you have never heard of any of them, simply click on the links to get to know the awesomeness. Now, let's just dive in.

# 1. Setup

The setup step is pretty simple and straightforward, we're going to start from a Svelte template as it already contains a lot of dependencies gathered in one boilerplate, then we integrate Electron into our app to get started.

## 1.1. Initiate a Svelte project

If you have seen my previous post with the browser extension, you should be familiar with this step already. From the CLI, run `npx degit sveltejs/template electron-app-svelte`. This will make a copy of the Svelte template to your machine with the name `electron-app-svelte`, and a basic structure as seen in the repository.

![](https://dev-to-uploads.s3.amazonaws.com/i/0qk48rw1f4at61vo91mb.png)

Run `npm install` to install all necessary dependencies in the template's `package.json`.

## 1.2. Integrate Electron

Now we install the Electron package by running `npm install electron --save-dev`. Once done, let's create our `index.js` file at the root with the following content:

```javascript
const { app, BrowserWindow } = require("electron");
const path = require("path");

app.on("ready", () => {
  const mainWindow = new BrowserWindow();
  mainWindow.loadFile(path.join(__dirname, "public/index.html"));
  mainWindow.webContents.openDevTools();
});
```

This is the minimum content required for Electron to create a window and attempt to load our entry HTML file from the `public` folder.

Next, let's make some changes in our `package.json` to get it to work:

```json
{
  ...
  "main": "index.js"
  "scripts": {
    "build": "rollup -c",
    "dev": "rollup -c -w",
    "start": "electron .",
  }
}
```

So, what I did was adding a new field `main` and pointing it to the `index.js` file we've just created, and also modifying the `start` script to invoke Electron to load our compiled code in the app's window. Now, we just need to run `npm run dev` to compile our Svelte source code, and subsequently, the start script will be called automatically (as predefined in our Rollup config). Let's try it to see if it already works:

![](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kncxosyx3ewvg3zrmxnn.png)

Nope, our app appears blank with some errors in the Dev Console. Apparently, the relevant resources could not be loaded due to the incorrect path, this is due to the fact that we are not serving our resources through any kind of host. The workaround is fairly simple, let's open our `index.html` file and remove all the **/** at the start of the links, this should fix it. Try running it again:

![](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7nzh9o5xqgd4so7ox9ua.png)

Awesome, we now have our Electron + Svelte app ready for development 🎉

# 2. Development

Once done with the setup, you can now continue the development just like you do with the web apps. The only difference is that our app is now run inside a window instead of a web browser (though they're still partially the same as the window is also using the V8 JavaScript engine under the hood to render web content).

Simply run `npm run dev` to start the development. Any changes in our source code are tracked and automatically re-compiled, we only need to press `Ctrl+R` to refresh our window and reflect the changes.

# 3. Build and distribute

After finishing the development, the next thing we must care about is obviously how to distribute our desktop app, how different it might be from the usual distribution of a web app?

For sure it is different, but not so hard at all. Let's see how this works:

Literally, all we need is an `electron-builder` package, so let's install it first with `npm install electron-builder --save-dev`. Next, in our `package.json`, add a new script as below:

```json
{
  scripts: {
    ...
    "dist": "npm run build && electron-builder"
  }
}
```

And that's it. Our `dist` script will produce a built version of our Svelte source code and trigger the `electron-builder` command to produce a complete distributable desktop app. Let's try it now and see what it gives us, run `npm run dist`:

![](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hy002c4kh20cmqa8eded.png)

Look, a `dist` folder appears as a result, and inside of it, there are a lot of things, but we only need to concern ourselves with those 2 highlights:
* The `.exe` installer package (as Windows was my target OS), which is what we need to distribute our app to the users.
* Upon installing, the `.exe` package will just extract exactly what is inside the `win-unpacked` folder to the users' machine and the app can then be used. Therefore, alternatively, you may also compress this folder and distribute it to the users, which still delivers the same outcome.

*A complete repository you can find at: https://github.com/khang-nd/electron-app-svelte*

And that is all in this sharing article, thank you for reading and see you in the next one.

Hello everyone, welcome to another article in the series Let's build something!, a series dedicated t...

Build a desktop app with Electron and Svelte

So, I'm back again with another pet project I have just finished and would like to share with everyone in this article:

![Khang's DEV stats](https://dev-stats.vercel.app/?background=efefef)

👆 This is it, an image generated dynamically from a RESTful service that allows me to easily display my statistics from DEV.to anywhere. Interesting? Read on to see some background and what I learned from making this, or if you want yours, head right to my repo for instructions on how to deploy one for your own:

{% github https://github.com/khang-nd/DEV-stats %}

# The inspiration

Yes, I believe some people should have realized it, this was inspired by the [amazing idea](https://github.com/anuraghazra/github-readme-stats/) from [anuraghazra](https://dev.to/anuraghazra) which allows us to dynamically generate our Github stats and display it easily anywhere as an SVG image. I find it interesting how he could manage it, so I went and checked out his source code, and attempted the same method for my DEV stats.

# The techs

As a developer with little experience in backend, I'm just simply amazed by the idea of using the RESTful API as such, to generate an SVG image that is capable of dynamically display your data from other sources.

This is also a great start for me to get into the world of server-side JS, powered by [NodeJS](https://nodejs.org/en/) and [Express](https://expressjs.com/). So thanks to the love for JS, I was familiar with most of the things already, and after taking some hours to learn the basics about Node from a [1-hour course by Mosh](https://youtu.be/TlB_eWDSMt4) (which I really recommend), and read through some docs and articles, I got things up and running without so much trouble.

The data for my DEV stats are provided thanks to the [DEV API](https://docs.forem.com/api/). Though still in a beta stage, the API is already capable of providing a handful of information that, after some simple processing, can be displayed as statistics.

The key factor for the success of this idea is how to represent the data dynamically, in the simplest way where it may be used anywhere, and that factor is by using SVG. I also went through some guides and articles about SVG to proceed and in the end, from making this, I got to learn the basic structure of an SVG document and some common elements. The pie chart, which shows the most commonly used tags in the articles, is a little tough for my current capability, so I went and picked a simpler workaround by using the awesome [QuickChart](https://quickchart.io/) service offered by [Ian Webster](https://dev.to/iwebst). QuickChart is really convenient, be sure to check it out.

Deploying to Vercel/Heroku was also not so bad of an experience for a beginner. I also created 2 buttons for convenient instant deployment in the repository. So in summary, check out the repo and I would welcome any contribution to improve or extend it. Thank you for reading, and see you in the next post.

So, I'm back again with another pet project I have just finished and would like to share with everyon...

A simple RESTful service to display DEV.to stats

In this article, I'm going to share with you how I built an **Android app with web techs using [WebView](https://developer.android.com/reference/android/webkit/WebView)**.

Yes, there are other alternative approaches, like [PWA](https://web.dev/progressive-web-apps/) or [React Native](https://reactnative.dev/) where web techs or the likes are involved to possibly achieve the same outcome, but due to the fact that a solution or approach may have the upperhand over the other depending on the context, it's always good to know more than just one solution. In this case, WebView provides us more interaction with our Android through the [Javascript Interface](https://developer.android.com/reference/android/webkit/JavascriptInterface) and the learning path for this solution might be flatter if you already have some basic knowledge in Java/Kotlin and proficient in web development. Now let's get started:

# 1. Basic setup

## 1.1. The Android app

Download and install [Android Studio](https://developer.android.com/studio).

Start Android Studio and create a new project with an empty activity:
![android project template](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ns94v0kq2yeukvmhoocj.png)

Select *Java* as the development language (or Kotlin if you are familiar with it)

Once done, the main structure of our app is as follows:
![android project structure](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1eamu00q7v8ygwposvus.png)

A lot of things, but let's just put our focus on the **`MainActivity`** class, where we write our code and the **`activity_main.xml`**, where we construct the app's layout.

In **`activity_main.xml`**, remove everything under the root and add:

```xml
<WebView
    android:id="@+id/webapp"
    android:layout_width="match_parent"
    android:layout_height="match_parent" />
```

This creates a `WebView` container which will display a web page in our app. The width and height are set to `match_parent` which fills up the whole screen.

In the **`MainActivity`** class, add the following lines to `onCreate`:

```java
WebView webView = (WebView) findViewById(R.id.webapp);
webView.getSettings().setJavaScriptEnabled(true);
```

This searches for the WebView with the id `webapp` from our layout that we defined and enables its JavaScript.

Now create an `assets` folder under the root `app` as shown in the screenshots below:

![create assets](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/dbt0zsfmqp6b05aa42pk.png)

The `assets` folder will contain the web resources we use in our app.

> If the web resources are composed of plain HTML, CSS and JS, you can add them directly here, if they have a more complex composition such as some frameworks and bundlers, you might need to put the **built version** here instead, so the app will be of an optimal size.

## 1.2. The web page

Now that we had our Android app ready to display a web page, we need a web page. I keep this guide simple and easy by just adding an HTML file directly in the `assets` folder with the following content:

```html
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
</head>
<body>
    <h1>Good day!</h1>
    <p>You are viewing this web page from Android!</p>
</body>
</html>
```

Then add the following line to your **`MainActivity`** class to load this page locally:

```java
webView.loadUrl("file:///android_asset/index.html");
```

If you are going to serve the web page on a host, you may then replace the URL to point to the target host:

```java
webView.loadUrl("https://mydomain.com");
```

Now try running your app on a simulator or connected device, you should be able to see the result:

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/802h6fwe701okeg4seac.png)

And that's it, we have just finished creating our Android app which is mainly constructed with web contents.

# 2. Interacting with Android

I did mention that using this WebView approach, our web page has the possibility to interact with our Android through the JavaScript Interface, correct? Let's see how it works:

Under the same package as the `MainActivity`, create a new class called `WebAppInterface` with the following contents:

```java
package com.example.androidwebapp;

import android.os.Build;
import android.webkit.JavascriptInterface;

public class WebAppInterface {
  @JavascriptInterface
  public String getAndroidVersion() {
    return Build.VERSION.RELEASE;
  }
}
```

Our function to get the Android version is marked with the `@JavaScriptInterface` annotation and will be available to our web page in a few more steps.

In our `MainActivity` class, add:

```java
webView.addJavascriptInterface(new WebAppInterface(), "Android");
```

This exposes any function we defined in the `WebAppInterface` class to the web page's JavaScript under the "Android" alias.

And finally, in our HTML page, add the following script:

```html
<script>
document.body.append("Your device is using Android " + Android.getAndroidVersion());
</script>
```

Try running again and you should be able to see the Android version of your simulator or device.

> A thing to note about this technique is that, due to the differences between Java/Kotlin and JavaScript, only **primitive** data types may be shared through the interface. For instance, exposing the function that returns a Java array as follows will resolve to `undefined` in JavaScript:

```java
@JavascriptInterface
public int[] getJavaArray() {
  return new int[] { 0, 1, 2 };
}
```

A complete repository you can find at: https://github.com/khang-nd/android-web

And this concludes my sharing article, thank you for reading, see you in the next one.


In this article, I'm going to share with you how I built an Android app with web techs using WebView....

Build an Android app with web techs


I have been learning *Svelte*. I find it extremely easy to work with. It is lightweight and fast, a suitable option for building small-scaled apps and websites. I've also been learning about how a *browser extension* is made. Then I find it a perfect playmate for Svelte, and the learning paths crossed. So today I would like to share my process of **building a complete cross-browser extension with Svelte**.

Before reading on, make sure that you're familiar with a browser extension and how to construct one with pure HTML/CSS/JS, and how to work with a front-end library/framework in a NodeJS environment. Otherwise, here are some resources to get you started:

* [Chrome Extension - Getting started](https://developer.chrome.com/docs/extensions/mv2/getstarted/) (Manifest v2)
* [Svelte - Getting started](https://svelte.dev/blog/the-easiest-way-to-get-started)
* [Build a cross-browser extension](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Build_a_cross_browser_extension)
* [Extensionizr](http://extensionizr.com/) - Chrome extension structure generator

# 1. Setup

## 1.1. Initiate a Svelte project

From the CLI, run `npx degit sveltejs/template my-extension`. This will make a copy of the [Svelte template](https://github.com/sveltejs/template) to your machine with the name `my-extension`, and a basic structure as seen in the repository.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/0qk48rw1f4at61vo91mb.png)

## 1.2. Install dependencies

Run `npm install` to install all necessary dependencies in the template's `package.json`.

To build a cross-browser extension, the [webextension-polyfill](https://github.com/mozilla/webextension-polyfill/) is required. Therefore, run `npm install --save-dev webextension-polyfill` to install it.

# 2. Prepare the Manifest

Now that we have things ready. Let's create the heart of a browser extension, the **`manifest.json`**.

Create `manifest.json` and place it inside the `public` folder. A bare minimum content of a manifest is:

```json
{
  "manifest_version": 2,
  "name": "My Extension",
  "version": "1.0.0",
}
```

And depending on the purpose and functionality of the extension, other fields may be specified. For a complete list of supported fields, refer to [Chrome's manifest file format](https://developer.chrome.com/docs/extensions/mv2/manifest/).

# 3. Add functionalities

Silly things that our extension will be capable of:

* Say hello when somebody installs our extension ([background page](https://developer.chrome.com/docs/extensions/mv2/background_pages/))
* "Hack" the website's background ([content script](https://developer.chrome.com/docs/extensions/mv2/content_scripts/))
* Configure the desired background ([popup page](https://developer.chrome.com/docs/extensions/reference/browserAction/#popup))

Now let's dig through.

## 3.1. Background page

The background page will be loaded whenever the extension is active, and react to the events we set. In our case, the extension reacts "say hello" to the event "somebody installs the extension".

Create `background.js` inside the `src` folder and add the following script:

```javascript
import browser from "webextension-polyfill";

browser.runtime.onInstalled.addListener(({ reason }) => {
  if (reason === "install") {
    alert("Hello");
  }
});
```

*More about the `runtime.onInstalled` event: [MDN](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/runtime/onInstalled).*

## 3.2. Content script

The content script has direct access to the current web page. Therefore, it is a perfect solution to "hack the website's background".

Create `injection.js` inside the `src` folder and add the following script:

```javascript
import browser from "webextension-polyfill";

const key = "background";
browser.storage.local.get(key).then((data) => {
  document.body.style = `background: url(${data[key]})`;
});
```

*More about the `storage.local` API: [MDN](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/storage/local).*

## 3.3. Popup page

The popup page is literally the front end of the extension, where users can interact with our extension. In our case, we give users the possibility to "configure the desired background". And this is where Svelte comes into the play.

Remove `props: { name: 'world' }` from `main.js`.

Replace content in `App.svelte` with the following script:

```html
<script>
  import browser from "webextension-polyfill";

  let image = "https://images.unsplash.com/photo-1586074299757-dc655f18518c?fit=crop&w=1268&q=80";

  function change() {
    browser.storage.local.set({ background: image });
  }
</script>

<main>
  Image URL: <input type="text" bind:value={image} />
  <button on:click={change}>Change</button>
</main>
```

## 3.4. Add to the Manifest

Now modify the `manifest.json` we created earlier to include these functionalities:

```json
{
  ...
  "permissions": ["storage"],
  "background": {
    "scripts": ["build/background.js"],
    "persistent": false
  },
  "browser_action": {
    "default_popup": "index.html"
  },
  "content_scripts": [
    {
      "matches": ["https://*/*"],
      "js": ["build/injection.js"]
    }
  ]
}
```

# 4. Config Rollup and build

The final step involves some configuration for Rollup to generate the `background.js` and `injection.js` to the `build` folder, so that the Manifest could recognize.

By default, the `rollup.config.js` file only outputs the `main.js` entry to the `build` folder under the alias `bundle.js`. To include the other scripts, modify the config as follows:

```javascript
export default [
  {
    input: "src/main.js",
    ...
  },
  {
    input: "src/background.js",
    output: {
      sourcemap: true,
      format: "iife",
      file: "public/build/background.js",
    },
    plugins: [resolve(), commonjs()],
    watch: {
      clearScreen: false,
    },
  },
  {
    input: "src/injection.js",
    output: {
      sourcemap: true,
      format: "iife",
      file: "public/build/injection.js",
    },
    plugins: [resolve(), commonjs()],
    watch: {
      clearScreen: false,
    },
  },
]
```

This will output multiple entries, including the `background.js` and `injection.js` to the `build` folder, and resolve any dependencies in our scripts.

And finally, run `npm run build` to compile our project and everything will be available in the `public` folder. We may then load our extension in Chrome and see the result:

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/unardrhpmbqcq78zoevm.png)

*A complete repo you can find at: https://github.com/khang-nd/browser-extension-svelte*

Thank you for reading, and see you in the next post.


I have been learning Svelte. I find it extremely easy to work with. It is lightweight and fast, a sui...

Build a browser extension with Svelte

There is a clever way to create a whole website with just *a single* HTML, some CSS, and *no* JS. Did you know?

# Step 1
Create an empty HTML5 website:
```html
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
</head>
<body>
    
</body>
</html>
```

# Step 2
Add some `anchors` and `sections` with `ids` for the pages:
```html
...
<body>
    <nav>
        <a href="#home">Home</a>
        <a href="#blog">Blog</a>
        <a href="#about">About</a>
    </nav>

    <main>
        <section id="home">
            <h1>Home</h1>
            <p>This is the homepage!</p>
        </section>
        <section id="blog">
            <h1>My Blog</h1>
        </section>
        <section id="about">
            <h1>About Me</h1>
        </section>
    </main>
</body>
```

# Step 3
Add some CSS to toggle the pages:
```html
<head>
...
    <style>
        section {
            display: none;
        }

        section:target {
            display: block;
        }
    </style>
</head>
```

# Step 4
There is no step 4. All that left is to customize it.

----

And that's it. You have a website ready in just a few steps, no JS used, no complex framework, just an HTML file, and a text editor. The magic behind this is by utilizing the anchor links and the `:target` pseudo selector to switch between the pages without the help of any JS.

> The `:target` pseudo selector matches when the hash in the URL and the id of an element are the same.

*Reference: [CSS-Tricks](https://css-tricks.com/a-whole-website-in-a-single-html-file/)*

There is a clever way to create a whole website with just a single HTML, some CSS, and no JS. Did you...

Make a website with a single HTML file

Prank your friends or colleagues, build a retro-looking portfolio for yourself, entertain visitors to your websites with old-school themes, or most importantly, let your creativity run wild, have fun with coding and relive your childhood with these amazing Retro CSS frameworks.

# NES.css ([Demo](https://nostalgic-css.github.io/NES.css/))
{% github https://github.com/nostalgic-css/NES.css %}

# 98.css ([Demo](https://jdan.github.io/98.css/))
{% github https://github.com/jdan/98.css %}

# BOOTSTRA.386 ([Demo](https://kristopolous.github.io/BOOTSTRA.386/))
{% github https://github.com/kristopolous/BOOTSTRA.386 %}

# Geo ([Demo](http://divshot.github.com/geo-bootstrap/))
{% github https://github.com/divshot/geo-bootstrap %}

# XP.css ([Demo](https://botoxparty.github.io/XP.css/))
{% github https://github.com/botoxparty/XP.css %}

# PSone.css ([Demo](https://micah5.github.io/PSone.css/))
{% github https://github.com/micah5/PSone.css %}

# RPGUI ([Demo](https://RonenNess.github.io/RPGUI/))
{% github https://github.com/RonenNess/RPGUI %}

# Win95.css ([Demo](https://alexbsoft.github.io/win95.css/))
{% github https://github.com/AlexBSoft/win95.css %}

# 7.css ([Demo](https://khang-nd.github.io/7.css/))
{% github https://github.com/khang-nd/7.css %}

# Pokémon GameBoy CSS ([Demo](https://timothywalter.github.io/css-pokemon-gameboy/))
{% github https://github.com/timothywalter/css-pokemon-gameboy %}

Prank your friends or colleagues, build a retro-looking portfolio for yourself, entertain visitors to...

10 Retro CSS frameworks to relive your childhood

In case you missed it, last week I wrote a post about a recent side project I worked on and submitted to the DOHackathon:
{% link https://dev.to/khangnd/7-css-my-first-published-package-21fd %}

I tweeted to share it, tagging [the original creator](https://twitter.com/jdan) of [98.css](https://github.com/jdan/98.css), who was the initiator. Apparently, he would notice but surprisingly, he seemed to be amused by how I did it and asked me to blog about it. {% twitter 1345190754369593344 %}

So here I am today, blogging about how I did it, and what I learned from following in his footsteps, and the awesome [creator](https://twitter.com/adamhamdev) of [XP.css](https://github.com/botoxparty/XP.css) as well. Hope this is useful to you in some ways.

# The inspiration

I first coincidentally came across the [XP.css](https://github.com/botoxparty/XP.css) repository of [Adam](https://twitter.com/adamhamdev) as I was exploring Github. And I was totally absorbed by the uniqueness and creativity of the idea, to recreate the UI system of Windows XP on the web. Then I also got to know about [98.css](https://github.com/jdan/98.css) which was the repo where the idea originated. And as a fellow loyal fan of Windows, I started a similar project of my own for Windows 7, from a clone of XP.css.

# The way I did

After cloning XP.css to my machine, I gave my repo a new name. Some ideas were *W7.css* or *Win7.css*, but I finally decided that it should be a name as simple as its predecessors, so I went with **7.css**.

From the 98.css design system that was all wrapped up in just one CSS file, Adam scaled up XP.css to an SCSS skeleton and named it the GUI framework. It was extremely easy to work with as each SCSS file acted as a UI component where I can quickly find which file I need to modify for a certain component. So, I started "upgrading" the styles from Windows XP to Windows 7.

![GUI framework](https://dev-to-uploads.s3.amazonaws.com/i/a36sw4uaxgoxr3p30wyu.png)

## Button

The components were all basically the same as those in the formers, only one new component that I added was the Progress Bar. However, the adaptation to Windows 7 style was quite challenging and required a lot of attention to details to make it somewhat resemble the actual UI. The key factors to recreate the design of Windows 7 (which I think was known as **Skeuomorphism**, a popular design trend at the time) were **`gradient background`** and **`box-shadow`**. For instance, a Windows 7 `button` would look like this:

![A Windows 7 button](https://dev-to-uploads.s3.amazonaws.com/i/494s3kmnny9d657ik99h.png)

Notice how the gradient cut at about halfway, from a light gray to a darker gray, and a slim white border around the edges of the button. So to recreate this, the key CSS properties used were:

```css
button {
    ...
    background: linear-gradient(to bottom, #eee 45%, #ddd 45%, #bbb);
    box-shadow: inset 0 -1px 1px #fff, inset 0 1px 1px #fff;
}
```

## Radio Button

For a `radio button`, it was quite trickier as the design was like this:

![A Windows 7 radio button](https://dev-to-uploads.s3.amazonaws.com/i/d5xs4jlf1btqek0gxfl3.png)

As a common method, to override the browser's default styling of radio buttons, one has to hide the actual `input` and have the `label` handle all the tough work. So in my case, I also had to use a `label`, with a `::before` pseudo-element to create the outer circle, and an `::after` to create the inner mark. Notice how there was a gray inset shadow in the outer circle, and some glowing in the upper left side of the blue inner mark. So the CSS rules and key properties used were:

```css
input[type=radio] + label::before {
    ...
    border-radius: 50%;
    background: #fff;
    box-shadow: inset 0 0 0 1.5px #ddd, inset 1px 3px 4px #888;
}

input[type=radio]:checked + label::after {
    ...
    background: #7cd3eb;
    box-shadow: inset -1px -1px 0 0.5px #16638f, inset -1px -1px 0 1px #1985c0;
}
```

## Progress Bar

The looks of a `progress bar` seemed a little bit similar to a button's due to some cutting gradient, so I thought at first, it would be easy to recreate:

![A Windows 7 progress bar](https://dev-to-uploads.s3.amazonaws.com/i/flfizx2d207lry8n6z9j.png)

But hell no, it was absolutely not. Look at the CSS I had to set up and you will see:

```css
[role="progressbar"] {
    ...
    background: linear-gradient(
      to right,
      rgba(0, 0, 0, 0.1),
      transparent 20%,
      transparent 80%,
      rgba(0, 0, 0, 0.1)
    ),
    linear-gradient(
      to bottom,
      rgba(255, 255, 255, 0.6) 25%,
      rgba(0, 0, 0, 0.05) 35%,
      rgba(0, 0, 0, 0.05) 90%,
      rgba(255, 255, 255, 0.2) 95%
    ),
    #ddd;
}

[role="progressbar"] > div {
    ...
    background-color: #0bd82c;
    background-image: linear-gradient(
        to right,
        rgba(0, 0, 0, 0.2),
        transparent 20%,
        transparent 80%,
        rgba(0, 0, 0, 0.2)
      ),
      linear-gradient(
        to bottom,
        rgba(255, 255, 255, 0.6) 30%,
        rgba(0, 0, 0, 0.05) 30%,
        rgba(0, 0, 0, 0.05) 90%,
        rgba(255, 255, 255, 0.2) 95%
      );
}
```

Told you... So what I did was, set up two `divs`, one for the outer container, the other for the inner bar (I know some might think of using the `::before` pseudo-element for the inner bar, but you cannot dynamically progress it this way). Notice how both `divs` had the same gradient, from a lighter shade to a darker shade, only the colors are different. So to apply this flexibility, I added a `background-image` as the mask (with a lot of transparency) on them for the gradient, and add the respective `background-colors` underneath.

## Window components

And how this would be a CSS recreation of the Windows 7 design if it missed the Window components? So let's take a look:

![A complete Windows 7 window](https://dev-to-uploads.s3.amazonaws.com/i/sr89hhmq62nljhcwbe0q.png)

This was probably the most challenging part of all, I would not address all the things I did to put together a complete Window but just some major points that you might find interesting. If curious, please feel free to take a look at the code directly in [the repo](https://github.com/khang-nd/7.css/blob/main/gui/_window.scss).

In principle, it was still mostly all about **`gradient background`** and **`box-shadow`**, but more advanced, as I had to use different angles of the gradient for the glassy effect of the frame. A raw look without content would then look like this:

![A raw Windows 7 window frame](https://dev-to-uploads.s3.amazonaws.com/i/04vfwi9d9hblhrk2m5o0.png)

For the title bar's controls, the key factor was again, you've guessed it, the `gradient background`, but this time, with a combination with the `radial-gradient` to create the glowing effect at the bottom of the controls when they are hovered or active.

![A Windows 7 title bar](https://dev-to-uploads.s3.amazonaws.com/i/2w1mqxb924z3wj7tjrjx.png)

And that is some insight I could give you in the context of this article. Drop a comment if there are certain things you want to know more in detail.

# The things I learned

As the first open-sourced package I have published, I got to learn quite a lot from this side project including but not limited to the following things:

* EJS and PostCSS are wonderful techs. (But I did not know before. Shame...)
* Receiving stars to my repository is really *addictive*, it motivates me to keep working on the project, although I cannot spend the stars...
* Publishing a package to `npm` is not as hard as I thought.
* You may think of your side projects as silly things you do just for fun, but *sometimes* they turn out even more popular than the stuff you do for real.
* Share your work with the public, either via social networks, or any sites that you can promote or post about it, so that it can reach as many people as possible, to see the actual value of your work; otherwise, it remains a silly thing forever.
* [Hacker News](https://news.ycombinator.com/) was the most successful media to draw audiences to this project. (And I just got to know about it shortly before, it's not popular from where I live.)

That is all folks. Thank you for reading!


In case you missed it, last week I wrote a post about a recent side project I worked on and submitted...

todayilearned

7.css - My Case Study

🎉 Happy New Year 🎉 and welcome to another post of mine. This time, a hackathon submission and a showcase of my recent work of **7.css** - a CSS design system for building components in Windows 7's flair.

## What I built

### Category Submission: 
Program for the People

### App Link
* https://win7-css-i5fco.ondigitalocean.app
* https://khang-nd.github.io/7.css

### Screenshots
![1](https://dev-to-uploads.s3.amazonaws.com/i/d7jv5q0dc6tohqjengkp.png)
![2](https://dev-to-uploads.s3.amazonaws.com/i/gvc511w7u2xjvoxoindb.png)

### Link to Source Code
https://github.com/khang-nd/7.css

### Permissive License
MIT

## Background
I happened to come across these 2 awesome projects: [98.css](https://jdan.github.io/98.css) and [XP.css](https://botoxparty.github.io/XP.css), and as a loyal fan of Windows, this inspired and triggered my enthusiasm to work on a similar project. And here we are.

### How I built it 
The backbone and system are technically there already in the former 2 projects, I just developed on top of them. However, I got to know some cool techs they used in the projects such as the [EJS](https://ejs.co/), which is used to generate examples with embedded  JS templating, or the [PostCSS](https://postcss.org/), which is used to transform CSS with some JS plugins. Also, this is my very first open-sourced package published for use.

Enjoy :)

🎉 Happy New Year 🎉 and welcome to another post of mine. This time, a hackathon submission and a showc...

7.css - My first published package

Heya, welcome to another brief article of mine.

This time I would like to share a silly, just-for-fun, unfinished, and never-to-be-finished pen I wrote back when I first started learning web dev - a simulation of the Nokia 1100 in pure HTML, CSS, and JS. Enjoy.

{% codepen https://codepen.io/khangnd/pen/abmWpaY %}

Heya, welcome to another brief article of mine.  This time I would like to share a silly, just-for-fu...

Nokia 1100 Simulation

*Bài viết được dịch từ dev.to. Truy cập bài viết gốc: [**About criticism**](https://dev.to/lexlohr/about-criticism-12f3).*

Sau khi rời xa chiếc ghế giảng đường, bước chân vào cuộc sống bộn bề của xã hội, mỗi chúng ta đều sẽ phải tiếp tục đối mặt với nhiều vấn đề, nhất là trong môi trường làm việc, nơi mà chúng ta phải dành phần lớn thời gian mỗi ngày để học hỏi và phát triển bản thân trên con đường sự nghiệp. Do đó, có lẽ ai đi làm cũng mong muốn được phát triển thật nhiều với hi vọng có thể thăng tiến, cùng những đồng lương tỷ lệ thuận với kiến thức, công sức mình bỏ ra. Và để phát triển, những lời phê bình, chỉ trích đóng vai trò không hề nhỏ, chúng giúp chúng ta nhìn nhận lại mình, thấy được những quan điểm sai lệch để khắc phục và cải thiện bản thân.

Nhưng có phải ai cũng có thái độ đúng đắn khi **đi chỉ trích** người khác hoặc khi **tiếp nhận sự chỉ trích** từ người khác? Dưới đây là bài dịch của mình từ một bài chia sẻ khá hay của một anh dev đã có nhiều năm kinh nghiệm trong ngành IT về vấn đề này.

---

![Anton Ego Ratatouille](https://images.viblo.asia/a7e83c36-9918-44db-ada9-dd851c696478.png)
*Nhân vật Anton Ego trong Ratatouille - một nhà phê bình nổi tiếng trong giới ẩm thực*

Ai cũng có quyền chỉ trích. Mọi lập trình viên ít nhiều đều phải trả qua cả hai phía: chịu sự chỉ trích và đưa ra những lời chi trích. Điều này rất bình thường, đi làm ai cũng sẽ phải trả qua, có thể là trong những buổi meeting, những lần review code hay kể cả khi chúng ta đi comment dạo trên mạng xã hội. Chúng ta hãy cùng xem xét về việc này từ cả hai phía nhé:

# Khi bị chỉ trích

Đầu tiên, chúng ta phải phân biệt rõ giữa một **lời chỉ trích** thực sự và một **lời ngụy biện** (những lập luận không hợp lý). Những lập luận ngụy biện thường có dạng *công kích cá nhân* (không đưa ra quan điểm về một đoạn code hoặc bài viết, mà chỉ comment kiểu: "*Tấm chiếu mới nên chưa đủ trình hiểu được đâu*") hay *song đề sai* (chỉ đưa ra hai lựa chọn trong khi còn rất nhiều cách, vd như: "*Một là dùng React, không thì dùng Vue*"). Trong trường hợp này, chúng ta phải chỉ ra:

> "Bạn làm ơn nhận xét về đoạn code đi, bình luận kiểu công kích đó không có ích gì cả."
>
> "Đâu phải chỉ có React với Vue, còn vô số framework/library mình có thể sử dụng mà!"

Kế đến là hãy **tiếp thu** nếu đó là một lời chỉ trích hợp lý, cho dù lời chỉ trích đó có khó nghe đi chăng nữa, vì những lời chỉ trích như vậy ít nhiều cũng đều có ích, giúp cho bạn có cách nhìn khác về giải pháp/lựa chọn của mình. Và quan trọng nhất là cố gắng dẹp bỏ cái tôi của mình trong những cuộc tranh luận vì những lợi ích to lớn hơn.

> "Cảm ơn anh đã cho ý kiến"

Chả có gì đáng xấu hổ khi thừa nhận việc mình sai, quan trọng là bạn biết sửa chữa để không tiếp tục sai. Như khi bạn bị một anh mentor hay đồng nghiệp chỉ trích về lỗi sai của mình, hãy vui vẻ:

> "Cảm ơn anh đã chỉ ra lỗi đó giúp em"

Đây là một nước đi đỉnh của chóp thể hiện bạn là một người biết lắng nghe, sẵn sàng đảm nhận những trọng trách quan trọng hơn.

Cuối cùng, hãy **tìm cách** khắc phục: từ những lời phê bình, chỉ trích đó thì chúng ta có thể làm gì để cải thiện, không còn phạm phải lỗi đó nữa? Nếu chưa thể tìm ra cách, bạn có thể trực tiếp xin lời khuyên từ người chỉ trích mình:

> "Anh có suggestion gì để giải quyết vấn đề này không?"

Chỉ qua 3 bước trên, bạn sẽ khiến người chỉ trích mình phải, hoặc là câm họng, hoặc là đưa ra những biện pháp để cải thiện, kiểu gì thì bạn cũng là người có lợi. Và vậy là bạn đã xử lý việc bị người khác phê bình, chỉ trích một cách thật chuyên nghiệp và hợp lý. Xứng đáng tăng lương! 😉

# Khi đưa ra lời chỉ trích

Khi đưa ra những lời chỉ trích thì bạn đang muốn đạt được điều gì? Có phải chỉ để chứng minh là mình đúng? Hay muốn thuyết phục người khác phải làm theo ý mình? Hay bạn muốn được mọi người công nhận mình là một "expert" trong mảng đó?

Dù mục đích của bạn là gì thì cũng nên tránh những cuộc tranh luận mà bạn chắc chắn sẽ chẳng đạt được lợi ích gì. Đừng để lún sâu vào tình trạng phải tiêu tốn quá nhiều thời gian, công sức vào một việc mà chắc chắn sẽ không đem lại kết quả. Việc chấm dứt một cuộc tranh luận đơn giản hơn bạn nghĩ: cứ "say goodbye" và đừng nói gì thêm. Cho dù có ai không hài lòng và đi nói xấu bạn thì bạn cũng **đừng** tìm cách trả đũa, không đáng tẹo nào đâu, cứ nhớ là những người đi nói xấu người khác sẽ chẳng tốt đẹp gì trong mắt mọi người đâu.

Nhưng lưu ý là, nếu bạn có thể đưa ra những lời chỉ trích **có tính xây dựng** (thẳng thắn, rõ ràng, có hướng giải quyết cụ thể) thì sẽ tốt hơn cho cả bạn và người phải chịu những lời chỉ trích từ bạn. Một lời chỉ trích tốt sẽ thỏa 3 tiêu chí sau:

## 1. Nghe phải hợp lý

Như đã đề cập ở trên, lập luận của những lời chỉ trích phải hợp lý chứ đừng ngụy biện.

> 👎 "Người người, nhà nhà đều dùng React thì mày cũng nên dùng."
> 
> 👍 "Cưng nên dùng React vì nó có hệ sinh thái đồ sộ (nhiều tool, nhiều package), giúp cho cưng làm dễ và nhanh hơn."

## 2. Đừng thể hiện cái tôi

Lời chỉ trích nên có tính khách quan, cả về nội dung lẫn hình thức.

> 👎 "Chỗ này gặp tao là tao dùng đệ quy chứ không dùng cách của mày."
> 
> 👍 "Chỗ này chế nghĩ dùng đệ quy sẽ thích hợp hơn, cưng thử đi."

## 3. Có hướng giải quyết

Một lời chỉ trích đỉnh của chóp là khi người nghe tiếp thu và có được hướng giải quyết.

> 👎 "Code dở như hạch, không có cách nào cải thiện đâu."
> 
> 👍 "Cưng có thể áp dụng builder pattern nếu cần phải viết lại chỗ code này."

Ngoài ra, bạn cũng có thể đưa ra những nguồn tư liệu bên ngoài để củng cố luận điểm của mình, đồng thời giúp cho đối phương có thể dễ tiếp nhận lời chỉ trích hơn và cũng để có thêm kiến thức.

Và sau khi đã đưa ra những lời chỉ trích thì hãy sẵn sàng tâm thế và thái độ tích cực, vì những lời đó rất có thể sẽ lại trở thành chủ đề để những người khác chỉ trích.

----
@khangnd<br>[![Github](https://images.viblo.asia/20x20/81dd12f0-a8c9-403f-ae51-27b92828ca22.png)](https://github.com/khang-nd) [![Linkedin](https://images.viblo.asia/20x20/4981766e-5e57-401a-8623-d3657a3148e5.png)](https://www.linkedin.com/in/khangnd/) [![Dev.to](https://images.viblo.asia/20x20/3921db2e-e4e5-45d7-acc8-e8b92e02d47d.png)](https://dev.to/khangnd) [![Fandom](https://images.viblo.asia/20x20/fad64df3-0be8-4481-b810-8995f18f71ea.png)](https://dev.fandom.com/wiki/User:KhangND)

Bài viết được dịch từ dev.to. Truy cập bài viết gốc: *About criticism*.

Sau khi rời xa chiếc ghế giảng đường, bước chân vào cuộc sống bộn bề của xã hội, mỗi chúng ta đều sẽ phải tiếp tục đối mặt với nhiều vấn đề, nhất là trong môi trường làm việc, nơi mà chúng ta phải dành phần lớn thời gian mỗi ngày để học hỏi và phát triển bản thân trên con đường sự nghiệp. Do đó, có lẽ ai đi làm cũng mong m...

Criticism - Sự phê bình, chỉ trích

Phạm Duy Vũ

Bạn là một tech lead chuyên về web nhưng bỗng một ngày bị bắt phải triển khai sản phẩm cho nền tảng di động trong thời gian ngắn? Hay là một front-end/back-end/full-stack web dev đang muốn lấn sân sang mobile nhưng không biết bắt đầu từ đâu? Hoặc bạn đang có một ý tưởng độc đáo về mobile app có thể kiếm 🍚 cho mình nhưng chỉ biết mỗi HTML, CSS và JS? Hay chỉ là một cốt đơ quèn, muốn khám phá, mở rộng kiến thức nhưng năng lực có hạn, không thể nhồi nhét được nhiều thứ giống mình 😔

**Capacitor** chính là giải pháp cho anh em ta. Cùng mình tìm hiểu về **Capacitor** và những ưu thế mà nó mang lại cho dân web trong việc phát triển một ứng dụng di động qua bài viết này nhé.

> Disclaimer: Capacitor cũng chỉ là một trong nhiều giải pháp giúp anh em dev có nhiều lựa chọn để giải quyết các vấn đề tùy yêu cầu, trường hợp, hoàn cảnh và resources. Nên trong bài viết này, mình chỉ tập trung giới thiệu, hướng dẫn về Capacitor chứ không chỉ ra những ưu, nhược điểm so với các giải pháp tương tự như Cordova, PWA, hay React Native...

# Một ít lý thuyết

![capacitorjs.jpg](https://images.viblo.asia/1d405b53-b753-418a-aa6c-b11bd51b6e93.jpg)

> A cross-platform native runtime for web apps.

Tạm dịch: Thời gian chạy bẩm sinh đa nền tảng dành cho ứng dụng web??? Wtf??? Đọc tiếng Anh thì khó hiểu, mà dịch ra nghe vừa củ chuối, vừa khó hiểu hơn 😂 Nhưng đó là dòng chữ to bự ngay trên [trang chủ](https://capacitorjs.com) để giới thiệu về **Capacitor**, một sản phẩm thuộc nền tảng [Ionic](https://ionic.io/) do bộ đôi [Max Lynch](https://github.com/mlynch) và [Ben Sperry](https://github.com/bensperry) đồng sáng lập và phát triển. Giải thích đơn giản thì Capacitor là một công cụ cho phép anh em dev có thể xây dựng những ứng dụng di động trên Android và iOS chỉ với công nghệ web cơ bản như HTML, CSS, JS, hoặc cao hơn là Angular, React, Vue..., hoặc cao hơn nữa là Nextjs, Nuxt, Quasar...

## Cơ chế làm việc

> Đoạn này mình cũng chỉ dịch một phần từ bài blog của Max Lynch, các bạn gút tiếng Anh có thể đọc trực tiếp bài blog của anh để hiểu rõ hơn tại [đây](https://capacitorjs.com/blog/how-capacitor-works).

![How capacitor works - basic](https://images.viblo.asia/40052ed9-275d-4b76-b2c7-6bb420e201e2.png)

Về cơ bản, Capacitor là cầu nối giúp cho ứng dụng web được viết từ HTML, CSS, JS có thể chạy và giao tiếp với các nền tảng mobile như Android hay iOS. Đi sâu hơn chút thì các bạn có thể thấy Capacitor gồm những thành phần sau:

![How capacitor works - advanced](https://images.viblo.asia/58b84cc1-a9d3-4262-94b9-0d23a0e4ee45.png)

Trong sơ đồ trên, các bạn hãy chú ý đến một thành phần quan trọng là **Web View**, nó là một phần không thể thiếu của hệ điều hành Android và iOS. Web View cho phép hiển thị trang web giống như một web browser nên các web app cũng sẽ hoạt động tốt. Tận dụng điều này, Capacitor gói gọn web app của chúng ta trong Web View, rồi hoạt động như một cầu nối giúp tương tác với các tính năng "native" (tức các tính năng đặc thù của hệ điều hành, ví dụ để mở một dialog, Android sẽ có cách implement khác, iOS có cách implement khác), khi cần sử dụng tính năng nào, chỉ cần gọi đến tính năng đó thông qua API.

Đối với những bạn đã có kinh nghiệm trong mảng mobile thì chắc không còn xa lạ với mô hình này, đây còn được gọi là mô hình ứng dụng **Hybrid**.

Với cách thức trên, chúng ta có thể phát triển mobile app cho nhiều nền tảng chỉ với một codebase viết từ ngôn ngữ web, bằng bất kì công nghệ web nào mà team đã lựa chọn, hoặc thậm chí là một web app đã hoàn thiện vẫn có thể tích hợp Capacitor để trở thành một mobile app mà không phải thay đổi nhiều về codebase.

## Hệ sinh thái plugin

Như đã kể trên, các tính năng "native" của mobile được Capacitor "bridge" để web app của chúng ta có thể gọi bất kì lúc nào thông qua API. Những tính năng native tồn tại dưới dạng "plugin". Ví dụ như app của mình cần chức năng rung để tương tác với người dùng, mình có thể cài đặt plugin [Haptics](https://capacitorjs.com/docs/apis/haptics), rồi từ code JS gọi `Haptics.vibrate()` để rung thiết bị của người dùng 📳 Quá ư là đơn giản.

Ngoài Haptics thì còn rất rất nhiều plugin được cả team core của Capacitor lẫn cộng đồng dev phát triển để chúng ta có thể sử dụng ngay và luôn. Các bạn có thể xem danh sách các plugin như bên dưới:

* Plugin chính thống của team core: https://capacitorjs.com/docs/apis
* Plugin của cộng đồng: https://github.com/capacitor-community

Những plugin này thực chất được viết bằng ngôn ngữ đặc thù của hệ điều hành, ví dụ đối với plugin Haptics, để xây dựng API rung thiết bị là `Haptics.vibrate()`, team Capacitor đã phải viết cả 2 ngôn ngữ cho 2 nền tảng là Android (bằng Java) và iOS (bằng Swift) như các bạn có thể thấy tại github [repo này](https://github.com/ionic-team/capacitor-plugins/tree/main/haptics). Tưởng đơn giản nhưng lại không hề giản đơn, nhưng các bạn cứ yên tâm, chắc 99% trường hợp các plugin có sẵn đã đủ để phục vụ nhu cầu của chúng ta, 1% còn lại thì ~~khó quá bỏ qua~~ chúng ta có thể tự tạo plugin cho riêng mình 😂

Ngoài ra, trong 99% đó còn có cả các plugin từ Cordova, Capacitor được thiết kế để tương thích với khá nhiều plugin của Cordova/PhoneGap (tiền bối của Capacitor, cùng ý tưởng và cách thức ứng dụng mô hình Hybrid apps). Cách cài đặt và sử dụng cũng tương đối đơn giản. Tiện hơn nữa là, do đa số các plugin của Cordova được viết bằng JS nên cộng đồng dev còn xây dựng các TypeScript wrapper được tập hợp tại [repo này](https://github.com/danielsogl/awesome-cordova-plugins), giúp các plugin này càng dễ sử dụng và tường minh hơn.

# Biến web app thành mobile app

Ở đây mình chọn một web app [To-do list](https://github.com/ha-manel/Todo-list) ngẫu nhiên trên github:

![Capacitor todo app demo](https://images.viblo.asia/ac4cb4b1-f3a3-4aa5-b81d-dbc376e43bee.png)

App này đã được code đầy đủ các chức năng cơ bản, giờ mình thử tích hợp Capacitor để biến nó thành một Android app có thể sử dụng các tính năng "native" như sau:

* Khi user thêm, sửa hay xóa một item, sẽ có một thông báo toast hiện ra - dùng [Toast plugin](https://capacitorjs.com/docs/apis/toast)
* Khi user tick hoàn thành một item, thiết bị của họ sẽ rung lên - dùng [Haptics plugin](https://capacitorjs.com/docs/apis/haptics)

Chỉ với 3 bước như trên trang chủ, chúng ta cùng bắt tay thực hiện.

## 1. Cài đặt CLI + core package và khởi tạo

```sh
npm install @capacitor/cli @capacitor/core
npx cap init
```

Terminal sau đó sẽ yêu cầu nhập các thông tin cần thiết để khởi tạo, như tên app, package ID của app trên Play Store/App Store, và thư mục sau khi build có chứa file `index.html` để Capacitor nhận diện. Trong ví dụ này mình đã điền như sau:

![Capacitor todo app init](https://images.viblo.asia/95836b17-9d74-4027-aecb-fb7f44877cdd.png)

## 2. Cài đặt platform package

Do mình chỉ muốn tạo một Android app nên mình chỉ cần chạy lệnh sau để cài đặt cho Android:

```sh
npm install @capacitor/android
npx cap add android
```

Để cài đặt cho cả 2 nền tảng, các bạn có thể thêm package `@capacitor/ios` rồi gọi `npx cap add ios` tương tự.

## 3. Sửa code để dùng tính năng "native" và build app

Như đã kể trên, mình sẽ cài thêm 2 plugin là Toast và Haptics để tích hợp tính năng "native":

```sh
npm install @capacitor/toast @capacitor/haptics
```

Trong [`src/tasks.js`](https://github.com/khang-nd/Todo-list-capacitor/commit/5afd736e3b36392a88d504aac4e25e296f10108a#diff-c1d699dd6ae4e4cefe908d90f96a49b3558667f84b81ec5e1d503dae12530786), mình import Toast plugin và gọi hàm `Toast.show()` để hiện thông báo mỗi khi user add/update/remove một item.

Trong [`src/status.js`](https://github.com/khang-nd/Todo-list-capacitor/commit/5afd736e3b36392a88d504aac4e25e296f10108a#diff-80a15cbd42e84124b3fcd0e2c35058874b26dc1e702f1db24387e20e999e6646), mình import Haptics plugin và gọi hàm `Haptics.vibrate()` để rung thiết bị của user khi họ tick hoàn thành một item.

Sau đó, build source và đồng bộ với thư mục `android` bằng lệnh:

```sh
npm run build
npx cap sync
```


### 3.x. Dùng Android Studio để đóng gói source code thành app

Ở bước này có thể sẽ có bạn thắc mắc: sao phải dùng Android Studio? tưởng Capacitor hô biến web app thành mobile app luôn mà không cần IDE đặc thù của nền tảng/hệ điều hành đó chứ? Lý do là vì Capacitor không hoạt động như vậy. Như đã nói trên, Capacitor chỉ đóng vai trò là cầu nối giữa codebase web của bạn với môi trường "native" của hệ điều hành, đơn giản hóa các bước trong quy trình phát triển mobile app, tuy nhiên, việc đóng gói code và build thành một mobile app vẫn phải do các IDE là **Android Studio** (đối với Android) hay **Xcode** (đối với iOS) đảm nhận. Nhưng bước này cũng không quá phức tạp nên các bạn không phải lo lắng.

Để cài đặt Android Studio, các bạn cứ lên [trang chủ](https://developer.android.com/studio) tải về rồi tiến hành cài đặt bình thường. Sau khi cài đặt, các bạn có thể mở Android Studio cùng với project của mình bằng lệnh `npx cap open android`. Đợi tí để gradle tự động cài đặt các package cần thiết cho app. Cuối cùng, các bạn có thể chạy app trực tiếp trên simulator hoặc điện thoại của mình để trải nghiệm, hay build source thành file apk hoặc bundle để deploy lên store.

![Android Studio run](https://images.viblo.asia/5f36d20d-32bc-4afe-b691-08f49ef2d008.png)

Trường hợp của mình, sau khi chạy app trên điện thoại, mình nhập một item mới thì một Toast hiện kết quả như code mình đã sửa:

![Capacitor todo app success](https://images.viblo.asia/d9b198e2-503e-4aca-8366-3b5c420c8653.png)

Vậy là mình đã có một Android app được xây dựng từ ngôn ngữ web, cực kỳ dễ dàng và nhanh chóng 🥳

# Tự tạo một plugin

Trường hợp app của bạn nằm trong số 1% đen đủi, phải sử dụng một tính năng "native" nào đó mà chưa có plugin nào có sẵn, thì Capacitor cũng có hỗ trợ tận răng các bước để bạn có thể tự tay tạo một plugin cho app của mình. Vấn đề còn lại không quá khó khăn, chỉ việc tìm một khóa học nào đó để học thêm về Java/Kotlin hay Swift/Objective-C thôi 😂

Ở đây mình thử tạo một Capacitor plugin cho Android (lại là Android, ước được viết bài hướng dẫn về iOS... 😢). Giả sử use case là app todo của mình muốn truy xuất được thông tin ngôn ngữ của thiết bị mà chưa có plugin nào cung cấp, mình sẽ tự tạo một plugin `locale` theo các bước sau:

## 1. Khởi tạo từ template plugin

Đầu tiên mình dùng bộ [generator](https://github.com/ionic-team/create-capacitor-plugin/) mà team Capacitor đã phát triển để tạo một khung sườn plugin:

```sh
npm init @capacitor/plugin
```

Nhập các thông tin cần thiết cho plugin generator, sau khi hoàn tất, các bạn sẽ có một project có cấu trúc thư mục tương tự như sau:

![Capacitor plugin structure](https://images.viblo.asia/4a9dc186-b114-422c-bc2b-a55349921dc9.png)

Ở đây mình sẽ chỉ quan tâm 2 thư mục `android` và `src`:

* `android` - Chứa source code của plugin cho Android (trong `android/src/main/java/com/.../LocalePlugin.java`)
* `src` - Chứa source code của plugin cho web và một bộ definition bằng TS để bridge với source code phía Android hoặc iOS.

## 2. Code xử lý phía Android

Truy cập theo [đường dẫn dài ngoằng đến source code của plugin phía Android](https://github.com/khang-nd/Todo-list-capacitor/tree/main/plugins/capacitor-plugin-locale/android/src/main/java/com/khangnd/todoapp/plugins/locale), các bạn sẽ thấy 2 file:

* `Locale.java` - chứa phần code xử lý logic của plugin
* `LocalePlugin.java` - chứa phần code để giao tiếp với web

Việc tổ chức file như trên giúp cho logic code của mình được tách ra rõ ràng và dễ maintain hơn nếu plugin của mình tương đối bự, nhưng do plugin mình dự định viết rất nhỏ nên mình sẽ chỉ viết code trong file `LocalePlugin.java`. Trong file này đã có sẵn một đoạn code mẫu tuy ngắn nhưng đầy đủ logic xử lý của một plugin API như sau:

```java
@CapacitorPlugin(name = "Locale") // <-- tên của plugin để bên phía web nhận diện được khai báo bằng decorator annotation
public class LocalePlugin extends Plugin {

    private Locale implementation = new Locale(); // <-- phần code xử lý logic nếu cần tách

    @PluginMethod // <-- annotation để khai báo hàm echo là một API của plugin
    public void echo(PluginCall call) { // <-- PluginCall là cục data nhận từ phía web
        String value = call.getString("value"); // <-- PluginCall chứa các hàm để nhận và chuyển đổi kiểu dữ liệu tương ứng

        JSObject ret = new JSObject(); // <-- tạo một cục data mới để trả về phía web
        ret.put("value", implementation.echo(value));
        call.resolve(ret); // <-- gọi hàm resolve của PluginCall để trả cục data về khổ chủ
    }
}
```

Mình sẽ sửa đoạn code này để làm nhiệm lấy thông tin locale của thiết bị như sau:

```java
@CapacitorPlugin(name = "Locale")
public class LocalePlugin extends Plugin {

    @PluginMethod
    public void getLocale(PluginCall call) {
        Locale locale = Locale.getDefault();
        call.resolve(locale);
    }
}
```

Quàooooo, logic xịn xò thía...

## 3. Định nghĩa interface

Ở bước này, mình sẽ định nghĩa hàm `getLocale` đã code ở phía Android trong [`src/definitions.ts`](https://github.com/khang-nd/Todo-list-capacitor/blob/main/plugins/capacitor-plugin-locale/src/definitions.ts):

```ts
export interface LocalePlugin {
  /**
   * Return the device's locale information.
   */
  getLocale(): Promise<string>;
}
```

Interface này sẽ giúp bạn hoặc một ai khác sử dụng plugin này có thể dễ dàng tận dụng type checking hay code completion của intellisense. Việc comment code là optional, nhưng chắc hẳn các bạn cũng đã quá rõ những lợi ích từ việc comment code, huống chi là tầm quan trọng của nó khi xây dựng API. Hơn nữa, các comment tại đây đóng vai trò là documentation comment và sẽ được generate ra cùng với file README khi các bạn chạy câu lệnh `npm run docgen` đã được tích hợp sẵn với template plugin.

## 4. Code xử lý phía Web

Ở bước này, mình chỉ cần tạo một hàm `getLocale` tương ứng bên phía web để kết nối với phía Android là có thể bắt đầu sử dụng plugin. Tại file [`src/web.ts`](https://github.com/khang-nd/Todo-list-capacitor/blob/main/plugins/capacitor-plugin-locale/src/web.ts), các bạn cũng có thể thấy một đoạn code mẫu đã có sẵn tương tự như bên Android. Mình sửa lại để trả thông tin ngôn ngữ của trình duyệt như sau:

```ts
export class LocaleWeb extends WebPlugin implements LocalePlugin {
  async getLocale(): Promise<string> {
      return navigator.language;
  }
}
```

> Lưu ý là nếu app của bạn đang nhắm tới nhiều nền tảng cùng lúc, cả Web, cả Android hoặc iOS, thì việc bạn phải viết code xử lý cho nhiều nền tảng là cần thiết, nhưng nếu app của bạn chỉ nhắm tới các nền tảng di động thì tại file này, các bạn có thể implement hàm rỗng mà không cần viết code xử lý bên trong.

Cuối cùng, chỉ việc build source bằng câu lệnh `npm run build` rồi đẩy lên npm để chia sẻ với cộng đồng hoặc import package vào project của mình để sử dụng thôi. Vậy là mình đã có một Capacitor plugin đơn giản.

# Kết

**Capacitor** quả thực là một vũ khí lợi hại cho anh em web dev, sự đơn giản, tiện lợi và nhanh chóng mà nó mang lại là cực kỳ giá trị. Nếu kết hợp với những bộ framework chuyên dụng để phát triển các cross-platform app như [Ionic](https://ionicframework.com/) (cùng cha đẻ), [Framework7](https://framework7.io/), [Quasar](https://quasar.dev/)... thì trông chuyên nghiệp bá cháy con bà bảy, không khác gì một "native" app thực thụ. Tuy vậy, rõ ràng không có công nghệ nào là "silver bullet" để giải quyết mọi vấn đề. Mỗi loại công nghệ đều có những ưu, khuyết điểm trong những trường hợp nhất định (về yêu cầu, quy mô, nhân lực, timeline, bảo mật, ông lead, bà PM, vân vân mây mây...). Nên cần đặt câu hỏi, trao đổi và đánh giá trước khi quyết định lựa chọn.

Hi vọng bài chia sẻ phần nào giúp ích cho các bạn, cảm ơn các bạn đã theo dõi bài viết 🙂

----
@khangnd<br>[![Github](https://images.viblo.asia/20x20/81dd12f0-a8c9-403f-ae51-27b92828ca22.png)](https://github.com/khang-nd) [![Linkedin](https://images.viblo.asia/20x20/4981766e-5e57-401a-8623-d3657a3148e5.png)](https://www.linkedin.com/in/khangnd/) [![Dev.to](https://images.viblo.asia/20x20/3921db2e-e4e5-45d7-acc8-e8b92e02d47d.png)](https://dev.to/khangnd) [![Fandom](https://images.viblo.asia/20x20/fad64df3-0be8-4481-b810-8995f18f71ea.png)](https://dev.fandom.com/wiki/User:KhangND)

Bạn là một tech lead chuyên về web nhưng bỗng một ngày bị bắt phải triển khai sản phẩm cho nền tảng di động trong thời gian ngắn? Hay là một front-end/back-end/full-stack web dev đang muốn lấn sân sang mobile nhưng không biết bắt đầu từ đâu? Hoặc bạn đang có một ý tưởng độc đáo về mobile app có thể kiếm 🍚 cho mình nhưng chỉ biết mỗi HTML, CSS và JS? Hay chỉ là một cốt đơ quèn, muốn khám phá, mở...

Capacitor - Xâm lược thế giới mobile chỉ với HTML, CSS, JS

Trương Thanh Tùng

Bạn đã chán ngấy khi làm việc với những trang web bất động? Bạn muốn thổi hồn vào những ứng dụng web của mình? Bạn muốn làm cái gì đó sinh động hơn, sáng tạo hơn. Vậy còn chờ gì mà không dùng [**Framer Motion**](https://www.framer.com/motion/)? 🥳 Cùng mình khám phá vài sự thú vị với thư viện này nhé.

![Framer Motion](https://images.viblo.asia/d3d2c44a-7833-4002-8291-1aa4990c2ce6.png)

# Một chút "background"

Framer Motion là một **animation/motion library** (thư viện hoạt hình/chuyển động? dịch ra nghe cứ sao sao nhỉ, thôi thì mình xin phép không Việt hóa những từ nặng về technical). Framer Motion được [Matt Perry](https://github.com/mattgperry) phát triển dành riêng cho các ứng dụng, trang web được xây dựng bằng ReactJS, là một *high level* library được dựng lên từ cái nền móng kiên cố là [Popmotion](https://popmotion.io/) (cùng tác giả). *High level* ở đây có nghĩa là bên trong library đã được xử lý khá nhiều cơ chế và logic chuyển động cực kỳ phức tạp, cung cấp một bộ API tường minh, dễ sử dụng và linh hoạt, giúp chúng ta nhẹ đầu và có thời gian nhâm nhi tách cafe ☕ khi làm việc với library này.

> Dành cho những bạn quan tâm tác giả thì ngoài Framer Motion và Popmotion, Matt cũng phát triển cả [Motion One](https://motion.dev/) (chỉ là một pet project của anh thôi đấy 😳), một animation library khác sử dụng Web Animations API hiện đại, có kích thước siêu gọn, nhưng cũng siêu nhanh và dễ sử dụng không kém.

# Bá cháy làm sao?

Một số tính năng vượt trội được tác giả và team phát triển liệt kê trên chính [trang chủ](https://www.framer.com/motion/) như sau:

* Cú pháp khai báo animation đơn giản, ngắn gọn -> giảm số lượng code -> codebase dễ đọc, dễ maintain.
* Animation giữa 2 component được tự động xử lý một cách rất là "magic".
* Hỗ trợ nhiều thao tác và event listener phức tạp như: tap, drag, hover, viewport...
* Nhiều kiểu animation như **spring** (kiểu chuyển động đàn hồi tự nhiên), **tween** (chuyển động theo thời gian) hay **inertia** (chuyển động theo quán tính) đều được "mỳ ăn liền" hóa, chúng ta có thể sử dụng ngay mà không cần cài đặt gì, hoặc vẫn có thể dễ dàng cài đặt và kiểm soát hoàn toàn animation theo ý mình.
* Và còn nhiều tính năng khác như hỗ trợ SSR, unmount animation, accessibility... vân vân mây mây...

![Show me code](https://media.makeameme.org/created/enough-blah-blah.jpg)

Để thấy được độ khét của Framer Motion qua ví dụ trực quan, mình có làm một cái codepen dựng lại kiểu bố cục thông dụng của một trang web e-commerce như bên dưới, các bạn tham khảo nhé:

{@embed: https://codepen.io/khangnd/pen/QWQLwjg}

Bố cục này gồm 3 mảng chính:

* Thanh **header** ở trên cùng, chứa logo và các link điều hướng.
* Khung **sidebar** bên tay trái, có thể chứa các danh mục sản phẩm hay bộ lọc.
* Phần **content** bên phải, chứa danh sách các sản phẩm.

## Animation API đơn giản

Ở codepen trên, các bạn có thể thấy mình chỉ cần import duy nhất một component là `motion` từ library (tạm thời mình đừng quan tâm tới `AnimatePresence`), bất kể bạn đang dùng thẻ HTML nào, chỉ cần thêm tiền tố `motion.` trước tên thẻ là có thể bắt đầu tạo animation cho thẻ đó, ví dụ `motion.div`, `motion.span` hay `motion.li`.

Việc tạo animation đơn giản chỉ cần khai báo một object chứa các animation ta muốn trong thuộc tính là `animate` hoặc đối với các thao tác như `tap` thì dùng thuộc tính `whileTap`, focus thì dùng `whileFocus`.

Như ở codepen trên, đối với logo, khi mình hover chuột lên thì các bạn có thể thấy **logo phình to lên** một tí, nhờ khai báo animation `scale` như sau:

```jsx
// line 12
<motion.div className="logo" whileHover={{ scale: 1.2 }} />
```

Tương tự, nếu muốn logo dịch **sang phải 10px** khi hover, chỉ cần thay `scale: 1.2` thành `x: 10`:
```jsx
<motion.div className="logo" whileHover={{ x: 10 }} />
```

Hoặc kết hợp nhiều animation cùng lúc:
```jsx
<motion.div className="logo" whileHover={{ scale: 1.2, x: 10 }} />
```

Đơn giản chưa? 😃 Các bạn cứ fork pen về mà nghịch nhé.

> *Đọc thêm:*
> * https://www.framer.com/docs/animation/#simple-animations
> * https://www.framer.com/docs/gestures/

## Variants thông minh

`Variants` là một thuộc tính khác của motion component, cho phép chúng ta nhóm nhiều animation lại với nhau (thành những ~~biến thể~~/trạng thái). Ví dụ như một button có thể có nhiều trạng thái như: default, hover, active, focus; hoặc một dialog có 2 trạng thái như: close, open. Mỗi trạng thái sẽ có những animation khác nhau được khai báo và `variants` giúp dễ quản lý chúng, khi cần `animate` như thế nào thì chỉ cần trỏ đến trạng thái đó.

Như ở codepen trên, mình đặt 2 trạng thái là *collapse* và *expand* cho khung sidebar. Khi bấm vào nút mũi tên thì sẽ thu gọn/mở rộng sidebar tương ứng và dựa theo trạng thái đó để animate:

```jsx
// line 35
const listVariants = {
    collapse: { width: 0 },
    expand: {
        transition: { staggerChildren: 0.2 }
    }
};

// line 57
<motion.ul
    variants={listVariants}
    animate={isCollapsed ? "collapse" : "expand"}
>
    ...
</motion.ul>
```

Ngoài ra, `variants` còn cho phép chúng ta **propagate** (animate những component con dựa theo trạng thái của cha) và **orchestrate** (kiểm soát thời gian, delay của chúng từ component cha). Như trong codepen:

```jsx
// line 42
const itemVariants = {
    collapse: { opacity: 0 },
    expand: { opacity: 1 }
};

// line 62
<motion.li key={i} variants={itemVariants} ... />
```

Các `li` chỉ cần khai báo `variants` ứng với trạng thái của `ul` cha thì chúng sẽ được tự động animate biến mờ dần theo cha (propagation). Và nếu các bạn để ý, trong `listVariants` của `ul` cha, mình có dùng một thuộc tính là `staggerChildren`, thuộc tính này cho phép delay animation của từng component con theo một khoảng thời gian nhất định, ví dụ ở đây là 0.2s thì component con thứ 1 sẽ delay 0s, component con thứ 2 sẽ delay 0.2s, component con thứ 3 sẽ delay 0.4s... và cứ thế (orchestration).

> *Đọc thêm:*
> * https://www.framer.com/docs/animation/#variants
> * https://www.framer.com/docs/transition/#orchestration

## Unmount và layout animation

Một trong những khả năng ***ảo diệu*** của Framer Motion là đây. Trong codepen, tính năng unmount và một phần layout animation được mình thể hiện ở các link điều hướng. Các bạn có thể thấy, khi nhấp vào một link điều hướng, link này được "hai lai" màu xanh, sau đó chọn sang một link khác thì ô màu xanh như được "di dời" sang cái link mới đó. Đó chính là nhờ vận dụng thuộc tính `layoutId` của motion component và một component gọi là `AnimatePresence`:

```jsx
// line 15
<a key={i} onClick={() => setActiveElem(i)}>
    <AnimatePresence>
        {activeElem === i && (
            <motion.span
                layoutId="navlink"
                animate={{ opacity: 1 }}
                initial={{ opacity: 0 }}
                exit={{ opacity: 0 }}
            />
        )}
    </AnimatePresence>
</a>
```

Logic mình xử lý ở đây là, mỗi thẻ `a` (link điều hướng) sẽ lồng một thẻ `span` (highlighter màu xanh), khi nhấp chọn một link thì hiển thị highlighter của link đó lên bằng cách mount component, sau đó animate `opacity` từ trạng thái ban đầu (initial) là 0 sang 1.

Mặc định, chúng ta chỉ có thể animate một component khi nó được mount vào cây DOM của React, để animate component cả khi nó được unmount thì Framer Motion có cung cấp component `AnimatePresence` giúp ta thực hiện điều đó. Chỉ cần bọc `AnimatePresence` bên ngoài component cần xử lý unmount animation, rồi khai báo thêm một thuộc tính là `exit` cho motion component là xong.

Các thẻ `span` mình chỉ cần khai báo cùng một `layoutId`, Framer Motion sẽ tự động xử lý layout animation như đang chuyển highlighter từ component này sang component kia.

Giờ các bạn thử chọn một button trong sidebar, sẽ thấy được sự ảo diệu của layout animation được thể hiện rõ hơn nữa. Các button này mình đang xử lý như một filter button, khi chọn một button, danh sách sản phẩm bên phía content sẽ được lọc tương ứng. Các bạn có thể thấy các ô sản phẩm bên tay phải bay nhảy mỗi khi chúng ta thay đổi filter, ảo diệu chưa 🤯 Chỉ đơn giản là khai báo thêm một thuộc tính `layout` cho motion component là chúng ta có ngay một animation cực kỳ "magic":

```jsx
// line 82
<motion.li
    layout
    className={[5, 17].includes(i) && "highlighted"}
    whileHover={{ y: -5 }}
>
    {i}
</motion.li>
```

![Magic gif](https://i.pinimg.com/originals/73/e5/53/73e55358e7b0703f20602b01b408e9e6.gif)

> *Đọc thêm:*
> * https://www.framer.com/docs/animate-presence/
> * https://www.framer.com/docs/animation/#layout-animations
> * https://www.framer.com/docs/animation/#shared-layout-animations

# "To Infinity and Beyond"

Ngoài những tính năng cơ bản được thể hiện qua những ví dụ đơn giản ở codepen trên, Framer Motion còn rất rất nhiều tính năng xịn xò và cao cấp hơn, ví dụ như các dạng animation (spring, tween, inertia), khả năng tự do tùy chỉnh transition, sử dụng dynamic variants, hay animate component bằng code nhờ các animation control... Tất cả đang chờ các bạn [khám phá](https://www.framer.com/docs/)! Hãy đem lại sức sống cho trang web, ứng dụng của mình! Hãy để user phải trầm trồ bởi sự sáng tạo, trí tưởng tượng của bạn, cho họ cảm giác thích thú khi được trải nghiệm một sản phẩm kỹ thuật nhưng có tính nghệ thuật cao. 😆

(Nhưng mà các bạn nhớ là "cái gì quá cũng không tốt" nhé, quá nhiều animation có thể sẽ làm phản tác dụng, khiến trải nghiệm của người dùng trở nên tệ hơn. Chỉ sử dụng chứ đừng lạm dụng!)

Cảm ơn các bạn đã theo dõi bài viết ✌

----
@khangnd<br>[![Github](https://images.viblo.asia/20x20/81dd12f0-a8c9-403f-ae51-27b92828ca22.png)](https://github.com/khang-nd) [![Linkedin](https://images.viblo.asia/20x20/4981766e-5e57-401a-8623-d3657a3148e5.png)](https://www.linkedin.com/in/khangnd/) [![Dev.to](https://images.viblo.asia/20x20/3921db2e-e4e5-45d7-acc8-e8b92e02d47d.png)](https://dev.to/khangnd) [![Fandom](https://images.viblo.asia/20x20/fad64df3-0be8-4481-b810-8995f18f71ea.png)](https://dev.fandom.com/wiki/User:KhangND)

Bạn đã chán ngấy khi làm việc với những trang web bất động? Bạn muốn thổi hồn vào những ứng dụng web của mình? Bạn muốn làm cái gì đó sinh động hơn, sáng tạo hơn. Vậy còn chờ gì mà không dùng Framer Motion? 🥳 Cùng mình khám phá vài sự thú vị với thư viện này nhé.

Một chút "background"

Framer Motion là một animation/motion library (thư viện hoạt hình/chuyển động? dịch ra nghe cứ sao sao nhỉ, t...

Framer Motion - Animation library bá cháy cho React web

Pet project (hay side project), một từ mà dân code chúng ta ít nhiều cũng đã nghe qua hoặc đã từng làm dăm ba cái để rèn luyện kỹ năng hay tiếp cận những công nghệ mới. Chủ đề này có lẽ đã được anh Hoàng (chủ blog toidicodedao nổi tiếng) khai thác và hướng dẫn triệt để, từ những lợi ích mà pet project mang lại, đến việc chọn ý tưởng để thực hiện, cũng như những cách triển khai để đưa đứa con ti...

Pet project - những lợi ích và câu chuyện bản thân

Mạnh Đàm Văn

Trong thời đại các thiết bị mobile đang ngày càng thông dụng, thì việc làm ra một website/webapp ngày càng phức tạp khi chúng ta phải chú trọng tới nhiều kích cỡ màn hình. Dù đã có nhiều framework CSS hỗ trợ sẵn nhưng việc nắm rõ CSS để không quá lệ thuộc vào framework không bao giờ là thừa. Bên cạnh kỹ thuật hỗ trợ responsive bá đạo như *media queries*, thì có lẽ đơn vị phần trăm là một người bạn đồng hành không thể thiếu nếu bạn muốn cuộc đời dev của mình không bị hành bởi CSS 😀 Bài viết này mình xin tổng hợp và chia sẻ ý nghĩa của **đơn vị phần trăm** cho một số thuộc tính CSS thông dụng để mọi người dễ nắm bắt và áp dụng hơn.

# Phần trăm của cái gì?

Đã là phần trăm thì chúng ta cần phải có một đối tượng cụ thể để đối chiếu. Đa số câu trả lời cho câu hỏi này thường sẽ là **parent block** (phần tử cha). Tuy câu trả lời đó không sai, nhưng chưa thực sự đầy đủ và bao hàm hết tất cả các trường hợp. Đáp án chính xác nhất là **containing block**, tức là phần tử chứa phần tử mà ta đang đặt đơn vị phần trăm.

Để minh họa cụ thể cho đáp án trên, các bạn cùng xem qua ví dụ dưới đây:
{@codepen: https://codepen.io/khangnd/pen/powbjEL}

Trong ví dụ này mình tạo 3 div lồng nhau là 3 ô vuông với các đặc điểm sau:
* Div **ông nội** bọc ngoài cùng, màu xám nhạt, kích thước là **4x4**
* Div **cha** màu xám đậm, kích thước là **2x2**
* Div **con** màu đỏ, kích thước là **50%**

Nếu phần trăm là theo **parent** thì kích thước của **con** lẽ ra phải bằng 1/2 **cha**, nhưng không, kích thước của **con** lúc này là bằng **cha** và lại bằng 1/2 kích thước của **ông nội** như các bạn thấy trong ví dụ. Nguyên nhân là do div **ông nội** mới thực sự là **containing block** chứa div **con**, vì trong div **con** mình có đặt thuộc tính `position: absolute`, ứng với `position: relative` trong div **ông nội**.

Như vậy, việc xác định đâu mới là **containing block** để đơn vị phần trăm đối chiếu hoàn toàn dựa trên thuộc tính `position` của phần tử đó. *Các bạn có thể đọc kĩ hơn trên [MDN](https://developer.mozilla.org/en-US/docs/Web/CSS/Containing_block#identifying_the_containing_block) (tài liệu tiếng Anh).*

Đối với một số thuộc tính, đối tượng để đối chiếu không phải là *parent block* hay *containing block* mà lại là chính nó - **self element**.

# Các thuộc tính

Dưới đây mình liệt kê một vài thuộc tính thông dụng trong số rất nhiều thuộc tính có thể sử dụng đơn vị phần trăm cùng với ý nghĩa của chúng, đi kèm một vài ví dụ để dễ hình dung hơn.

## `width`/`height`

Đây là 2 thuộc tính phổ biến nhất mà các bạn có thể đã ít nhiều áp dụng đơn vị phần trăm. Không có gì phức tạp, như ví dụ trên, khi bạn đặt phần trăm cho `width` của phần tử thì nó sẽ được đối chiếu với `width` của **containing block** tương ứng, và tương tự, `height` sẽ được đối chiếu với `height` của **containing block**.

## `padding`

Đối với `padding`, cho dù là dọc (`padding-top`/`padding-bottom`) hay ngang (`padding-left`/`padding-right`) thì đơn vị phần trăm đều sẽ đối chiếu với `width` của **containing block**.

Ví dụ:
{@codepen: https://codepen.io/khangnd/pen/YzQWWRG}

Trong ví dụ này,
* Div **cha** có đặt kích thước là **6x4**
* Div **con** có kích thước là **0**, nhưng với 2 thuộc tính `padding-top` và `padding-left` đều là **50%**

Kết quả là **con** có kích thước bằng 1/2 `width` của **cha**, tức là một hình vuông **3x3**.

## `margin`

Tương tự như `padding`, đơn vị phần trăm của `margin` (cả dọc và ngang) đều đối chiếu với `width` của **containing block**.

Ví dụ:
{@codepen: https://codepen.io/khangnd/pen/MWoejWd}

Trong ví dụ này,
* Div **cha** có kích thước là **6x4**
* Div **con** với 2 thuộc tính `margin-top` và `margin-left` đều là **50%**

Kết quả là **con** nằm cách cạnh trên và cạnh trái của **cha** một khoảng bằng **3** đơn vị (1/2 `width` của **cha**).

## `top`/`bottom`/`left`/`right`

Đối với các thuộc tính định vị trí của phần tử (thường được kết hợp với `position`), đơn vị phần trăm sẽ đối chiếu `top`/`bottom` với `height` và `left`/`right` với `width` của **containing block**.

Ví dụ:
{@codepen: https://codepen.io/khangnd/pen/MWoerzw}

Trong ví dụ này
* Div **cha** có kích thước là **6x4**
* Div **con** được đặt `position: absolute` với 2 thuộc tính `top` và `left` đều là **50%**

Kết quả là **con** nằm cách cạnh trên của **cha** một khoảng **2** đơn vị (1/2 `height` của **cha**), và cách cạnh trái của **cha** một khoảng **3** đơn vị (1/2 `width` của **cha**).

## `transform: translate()`

Có lẽ thuộc tính này sẽ ít bạn biết tới hơn, nhưng đây cũng là một thuộc tính cực kỳ lợi hại để định vị trí của phần tử thay cho các thuộc tính trên, thậm chí còn lợi hại hơn về mặt performance khi bạn cần kết hợp với animation hay transition. Tuy nhiên, đối với thuộc tính `transform: translate()` này, đơn vị phần trăm không được đối chiếu với **containing block**, mà sẽ được đối chiếu với **self element** (chính bản thân nó).

Ví dụ:
{@codepen: https://codepen.io/khangnd/pen/QWgEQvy}

Trong ví dụ này,
* Div **cha** có kích thước là **6x4**
* Div **con** có kích thước là **2x1** với thuộc tính `transform: translate(50%, 50%)`

Kết quả là **con** nằm cách cạnh trên của **cha** một khoảng **0.5** đơn vị (1/2 `height` của **con**), và cách cạnh trái của **cha** một khoảng **1** đơn vị (1/2 `width` của **con**).

## `background-size`

Đối với `background-size` thì sẽ hơi phức tạp hơn. Đơn vị phần trăm của thuộc tính này sẽ dựa vào **background positioning area** (tạm dịch: phạm vi đặt vị trí ảnh). Hiểu đơn giản thì **background positioning area** cũng chính là **containing block**, nhưng bổ sung 3 yếu tố sau:

* Block chỉ bao gồm content (`content-box`)
* Block bao gồm content và padding (`padding-box`)
* Block bao gồm cả content, padding và border (`border-box`)

3 yếu tố được quy định theo thuộc tính `background-origin`.

Ví dụ:
{@codepen: https://codepen.io/khangnd/pen/rNwLdMZ}

Trong ví dụ này,
* Div **cha** có kích thước là **6x4**
* Div **con** có kích thước là **3x2**, không `padding`, ko `border`
* Mình dùng [một biểu tượng](https://d2fltix0v2e0sb.cloudfront.net/dev-rainbow.png) (tỉ lệ thật là hình vuông **1:1**) đặt làm `background-image` cho div **con**, với thuộc tính `background-size` là **50% 50%**

Kết quả là ảnh background bị co giãn để có kích thước là **1.5x1**, ứng với 1/2 kích thước của div **con**.

## `background-position`

Tương tự như `background-size`, đơn vị phần trăm của `background-position` cũng dựa vào **background positioning area**.

Ví dụ:
{@codepen: https://codepen.io/khangnd/pen/JjJKLaP}

Ở ví dụ này, mình dùng hình ảnh và bố cục tương tự như ví dụ `background-size`. Khi thay đổi giá trị của `background-position`, chúng ta có thể quan sát thấy vài điểm sau:
* Khi không đặt giá trị `background-position` (giá trị mặc định là `0 0`), ảnh background sẽ nằm ở góc **trái trên**.
* Khi đặt `background-position: 0 50%`, ảnh background sẽ nằm ở góc **trái giữa**.
* Khi đặt `background-position: 50% 50%`, ảnh background sẽ nằm ở ngay **chính giữa**.
* Khi đặt `background-position: 100% 100%`, ảnh background sẽ nằm ở góc **phải dưới**.

> **Lưu ý**: `background-position: 0 50%` tương đương:
> * `background-position-x: 0`
> * `background-position-y: 50%`

Rõ ràng là có một sự tính toán đằng sau đơn vị phần trăm của thuộc tính này, thay vì chỉ là khoảng cách từ cạnh trên của div **con** đến ảnh. Lấy một trường hợp cụ thể là `background-position: 100% 100%`, nếu tính như `top`/`left` thì lẽ ra ảnh đã phải nằm ra ngoài div **con**, hay nếu tính như `transform: translate()` thì ảnh phải nằm ở góc **giữa dưới**. Vậy tại sao trường hợp này ảnh lại nằm ở góc **phải dưới**? Nguyên nhân là do thuộc tính `background-position` phải tham giao vào công thức sau trước khi trả về vị trí thực của ảnh:

> offset X = (container's width - image's width) * background-position-x
> 
> offset Y = (container's height - image's height) * background-position-y

Trong trường hợp này,
* *container* là div **con**
* *image's width/height* là kích thước của ảnh đã qua xử lý của `background-size`

## `font-size`

Đối với `font-size`, bất kể như thế nào, đơn vị phần trăm chỉ được đối chiếu với **parent block**.

Ví dụ:
{@codepen: https://codepen.io/khangnd/pen/MWoeXMO}

Ví dụ này mình dùng bố cục tương tự như ví dụ đầu tiên, với các thuộc tính `font-size` được đặt như sau:
* Div **ông nội** là **13px**
* Div **cha** là **26px**
* Div **con** là **50%**

Kết quả như chúng ta có thể thấy, `font-size` của **con** lúc này có vẻ là bằng với **ông nội** và bằng 1/2 của **cha**, mặc dù **ông nội** có thuộc tính `position: relative` còn **cha** thì không.

## `line-height`

Tuy ít phổ biến hơn nhưng mình cũng nhắc đến thuộc tính này vì nó cũng hỗ trợ đơn vị phần trăm. Đơn vị phần trăm của `line-height` sẽ đối chiếu với `font-size` của chính bản thân nó - **self element**. Cách tính là lấy giá trị phần trăm * `font-size` để được giá trị thực của `line-height`.

Ví dụ:
{@codepen: https://codepen.io/khangnd/pen/oNwLMXR}

Trong ví dụ này,
* Đoạn text có **11** dòng
* `font-size` là **20px**
* `line-height` là **150%**

Kết quả `height` thực tế của khối là **~329px**,
* Tính theo cách trên thì kết quả của `line-height` = 20 * 150 / 100 = **30px**.
* Tính theo `line-height` thì `height` = 30 * 11 = **330px**, cũng sấp sỉ kết quả thực tế.

# Kết
Hi vọng bài viết phần nào giúp các bạn dễ hiểu hơn về đơn vị phần trăm, chứ không làm tình hình càng tệ hơn 😅

Dưới đây mình làm 1 bảng tóm sơ lại các đối tượng để đối chiếu phần trăm, để có cái gọi là "takeaway":

| Thuộc tính | Đối tượng để đối chiếu % 
| -------- | -------- 
| `width` | **containing block's `width`**
| `height` | **containing block's `height`**
| `padding` | **containing block's `width`**
| `margin` | **containing block's `width`**
| `left/right` | **containing block's `width`**
| `top/bottom` | **containing block's `height`**
| `transform: translateX()` | **self element's `width`**
| `transform: translateY()` | **self element's `height`**
| `background-size` | **background positioning area**
| `background-position` | **background positioning area** (có công thức tính)
| `font-size` | **parent block's `font-size`**
| `line-height` | **self element's `font-size`** (có công thức tính)

Còn đây là trọn bộ các ví dụ trong bài viết: https://codepen.io/collection/xKwgdW
# Tham khảo

* https://developer.mozilla.org/en-US/docs/Web/CSS/Containing_block
* https://developer.mozilla.org/en-US/docs/Web/CSS/percentage
* https://developer.mozilla.org/en-US/docs/Web/CSS/background-position#regarding_percentages
* https://jameshfisher.com/2019/12/29/what-are-css-percentages/
* https://wattenberger.com/blog/css-percents

----
@khangnd<br>[![Github](https://images.viblo.asia/20x20/81dd12f0-a8c9-403f-ae51-27b92828ca22.png)](https://github.com/khang-nd) [![Linkedin](https://images.viblo.asia/20x20/4981766e-5e57-401a-8623-d3657a3148e5.png)](https://www.linkedin.com/in/khangnd/) [![Dev.to](https://images.viblo.asia/20x20/3921db2e-e4e5-45d7-acc8-e8b92e02d47d.png)](https://dev.to/khangnd) [![Fandom](https://images.viblo.asia/20x20/fad64df3-0be8-4481-b810-8995f18f71ea.png)](https://dev.fandom.com/wiki/User:KhangND)

Trong thời đại các thiết bị mobile đang ngày càng thông dụng, thì việc làm ra một website/webapp ngày càng phức tạp khi chúng ta phải chú trọng tới nhiều kích cỡ màn hình. Dù đã có nhiều framework CSS hỗ trợ sẵn nhưng việc nắm rõ CSS để không quá lệ thuộc vào framework không bao giờ là thừa. Bên cạnh kỹ thuật hỗ trợ responsive bá đạo như media queries, thì có lẽ đơn vị phần trăm là một người bạ...

CSS Percentage - Hiểu rõ hơn về đơn vị phần trăm trong CSS

Trần Xuân Thắng

*Bài viết được dịch từ [**Gist của wojteklu**](https://gist.github.com/wojteklu/73c6914cc446146b8b533c0988cf8d29).*

Code sạch khi nó có thể được hiểu bởi tất cả mọi người trong team. Code sạch có thể được một lập trình viên khác ngoài chính tác giả đọc và cải tiến. Code dễ hiểu sẽ dễ đọc, dễ sửa, dễ cải tiến và dễ bảo trì.

-----

## Quy tắc chung

1. Tuân theo các quy ước chuẩn.
2. Suy nghĩ đơn giản thôi, viết code cũng đơn giản thôi.
3. Luôn dọn code sạch sẽ hơn lúc bạn nhận nó, dù là code của mình hay người khác.
4. Luôn tìm nguyên nhân cốt lõi của vấn đề.

## Quy tắc thiết kế

1. Dữ liệu tùy chỉnh/cấu hình thì nên đặt ở level cao.
2. Thay vì dùng if/else hoặc switch/case, nên vận dụng [tính đa hình](https://viblo.asia/p/4-dac-tinh-cua-lap-trinh-huong-doi-tuong-object-oriented-program-XL6lAA7Nlek#_tinh-da-hinh-polymorphism--2).
3. Tách code đa luồng.
4. Đừng lạm dụng *configurability*?
5. Sử dụng [dependency injection](https://viblo.asia/p/dependency-injection-la-gi-va-khi-nao-thi-nen-su-dung-no-LzD5d0d05jY).
6. Tuân theo [Định luật Demeter](https://viblo.asia/p/code-tom-2-biet-qua-nhieu-63vKjR2RK2R)

## Mẹo để code dễ hiểu

1. Thống nhất cách làm. Nếu bạn quen với một cách nào đó thì hãy áp dụng cách đó cho những thứ tương tự.
2. Đặt tên biến có nghĩa.
3. Khai báo biến để chứa các giá trị biên. Ví dụ:
    ```js
    // ❌
    const arr = [1, 2, 3];
    for (let i = 0; i <= arr.length - 1; i++) { }
    
    // ✅
    const arr = [1, 2, 3];
    const lastIndex = arr.length - 1;
    for (let i = 0; i <= lastIndex; i++) { }
    ```
4. Nếu có thể, chọn 'value object' thay vì kiểu dữ liệu nguyên thủy.
5. Tránh sự lệ thuộc về logic. Ví dụ khi xây dựng method, không nên cho method đó lệ thuộc một điều kiện nào đó trong cùng một class.
6. Tránh dùng điều kiện phủ định.

## Quy tắc đặt tên

1. Đặt tên rõ ràng, mô tả được công dụng.
2. Dễ phân biệt.
3. Dễ đọc.
4. Dễ tìm.
5. Không nên dùng số trực tiếp trong code mà phải đặt tên cho nó. Ví dụ:
    ```js
    // ❌
    if (gender === 0) { }
    else if (gender === 1) { }
    else { }
    
    // ✅
    const MALE = 0;
    const FEMALE = 1;
    
    if (gender === MALE) { }
    else if (gender === FEMALE) { }
    else { }
    ```
6. Không nên chèn tiền tố hay kiểu dữ liệu vào tên. Ví dụ:
    ```js
    // ❌
    let sName = "Robert C. Martin";
    let roleList = ["User", "Admin", "Mod"];

    // ✅
    let name = "Robert C. Martin";
    let roles = ["User", "Admin", "Mod"];
    ```
    
*Tham khảo thêm: [Naming rules - Các quy tắc vàng trong làng đặt tên](https://viblo.asia/p/naming-rules-cac-quy-tac-vang-trong-lang-dat-ten-ByEZkMXE5Q0)*

## Quy tắc của hàm

1. Nhỏ.
2. Chỉ làm một việc.
3. Tên dễ hiểu.
4. Chỉ nên có ít đối số.
5. Không có tác dụng phụ.
6. Không được dùng đối số dạng flag mà phải tách nhỏ hàm ra thành nhiều hàm độc lập để dễ gọi cũng như test. Ví dụ:
    ```js
    // ❌
    function setConfig(name, value) {
        if (name === "theme") {
            this._theme = value;
        }
        if (name === "font") {
            this._font = value;
        }
    }
    
    // ✅
    function setTheme(value) { this._theme = value; }
    function setFont(value) { this._font = value; }
    ```

## Quy tắc comment

1. Code nên dễ hiểu để không lệ thuộc nhiều vào comment.
2. Không comment dư thừa.
3. Không comment những điều quá rõ ràng, dễ nhận biết. Ví dụ:
    ```js
    /**
     * Hàm thêm role vào database.
     */
    function addRole(role) {
        db.roles.add(role);
    }
    ```
4. Không comment khi đóng thẻ/ngoặc. Ví dụ:
    ```html
    <!DOCTYPE html>
    <html lang="en">
    
    <head>
    ...
    </head>
    
    
    
    <body>
    ...
    </body>
    
    </html>
    ```
5. Không comment đoạn code không còn sử dụng, xóa nó luôn.
6. Comment lý do tại sao code được viết như vậy (code lạ, trường hợp bất khả kháng).
7. Comment để làm rõ ý nghĩa của code (logic phức tạp).
8. Comment cảnh báo hậu quả.

## Cấu trúc code

1. Phân chia code theo chiều dọc.
2. Những code liên quan nhau nên viết liền nhau (theo chiều dọc).
3. Khai báo biến gần chỗ nó được sử dụng.
4. Các hàm liên quan nhau nên đặt gần nhau.
5. Các hàm giống nhau nên đặt gần nhau.
6. Các hàm nên viết từ trên xuống dưới.
7. Mỗi dòng code nên ngắn.
8. Không cân chỉnh code theo chiều ngang. Ví dụ:
    ```ts
    // ❌
    const PI:     number = 3.14;
    let   radius: number = 10;
    let   area:   number = 2 * PI * radius;
    
    // ✅
    const PI: number = 3.14;
    let radius: number = 10;
    let area: number = 2 * PI * radius;
    ```
9. Dùng khoảng trắng một cách hợp lý để liên kết những thứ liên quan và tách những thứ ít liên quan với nhau.
10. Đừng ngắt thụt đầu dòng. Ví dụ:
    ```js
    // ❌
    if (isUser) loadUserPage();
    else redirectHome();
    
    // ✅
    if (isUser)
        loadUserPage();
    else
        redirectHome();
    ```

## Cấu trúc dữ liệu và object

1. Ẩn cấu trúc nội bộ.
2. Dùng cấu trúc dữ liệu nếu có thể.
3. Tránh cấu trúc hỗn hợp, nửa này nữa kia.
4. Nhỏ.
5. Chỉ làm một việc.
6. Chỉ dùng một ít biến instance.
7. Cha không được nhìn con. (Base class không nên biết các child class trông như thế nào)
8. Tạo nhiều hàm thay vì truyền đối số vào duy nhất một hàm rồi xử lý theo đối số đó.
9. Nên dùng non-static thay vì static method.

## Kiểm thử (test)

1. Mỗi test chỉ nên kiểm tra một thứ.
2. Dễ đọc.
3. Nhanh.
4. Độc lập.
5. Có thể lặp đi lặp lại.

## Code thúi

1. Quá cứng nhắc, khó thay đổi. Một thay đổi nhỏ mà dẫn tới một loạt những thay đổi khác.
2. Mong manh, dễ vỡ. Chỉ sửa một chỗ mà gây ra lỗi một đống chỗ.
3. Bất động. Code không thể được tái sử dụng trong những dự án khác, vì quá nhiều rủi ro và tốn effort.
4. Phức tạp hóa không cần thiết.
5. Lặp lại không cần thiết.
6. Code khó hiểu.

----
@khangnd<br>[![Github](https://images.viblo.asia/20x20/81dd12f0-a8c9-403f-ae51-27b92828ca22.png)](https://github.com/khang-nd) [![Linkedin](https://images.viblo.asia/20x20/4981766e-5e57-401a-8623-d3657a3148e5.png)](https://www.linkedin.com/in/khangnd/) [![Dev.to](https://images.viblo.asia/20x20/3921db2e-e4e5-45d7-acc8-e8b92e02d47d.png)](https://dev.to/khangnd) [![Fandom](https://images.viblo.asia/20x20/fad64df3-0be8-4481-b810-8995f18f71ea.png)](https://dev.fandom.com/wiki/User:KhangND)

Bài viết được dịch từ *Gist của wojteklu*.

Code sạch khi nó có thể được hiểu bởi tất cả mọi người trong team. Code sạch có thể được một lập trình viên khác ngoài chính tác giả đọc và cải tiến. Code dễ hiểu sẽ dễ đọc, dễ sửa, dễ cải tiến và dễ bảo trì.

Quy tắc chung

1. Tuân theo các quy ước chuẩn.
2. Suy nghĩ đơn giản thôi, viết code cũng đơn giản thôi.
3. Luôn dọn code sạch sẽ hơn lúc bạn nh...

Tóm tắt cuốn Clean Code của Uncle Bob

Có lẽ kỹ thuật này đã xuất hiện từ rất lâu và chắc nhiều người đã biết tới, nhưng thực sự thì đến giờ mình mới được biết đến, cảm thấy nó cực kỳ tiện lợi và thú vị nên muốn chia sẻ lại cho những bạn chưa biết. Chúng ta cùng tìm hiểu về **Bookmarklet** và xem cách tạo một tool đơn giản và tiện lợi bằng kỹ thuật này như thế nào nhé.

# Bookmarklet là gì?
Khi sử dụng trình duyệt web, các bạn hẳn đã không còn xa lạ với tính năng **bookmark** (đánh dấu) các trang web mà mình hay truy cập để khi cần tới chỉ bằng một cú nhấp chuột là dễ dàng truy cập lại. **Bookmarklet** cũng là bookmark, nhưng thay vì lưu URL của trang web, chúng ta sẽ lưu các dòng lệnh JavaScript. Do vậy, bookmarklet có thể được hình dung là một chương trình JavaScript, một extension cho trình duyệt, giúp các bạn bổ sung một tính năng nào đó cho trang web chỉ với một cú nhấp chuột.

Nếu so sánh với một extension hẳn hoi của trình duyệt thì quả là khập khiễng, bởi bookmarklet sẽ chỉ có thể thao tác trên trang web mà bạn đang truy cập (đọc, thêm, sửa đổi cây DOM của trang, giống như **content_script** của extension). Nhưng sự tiện lợi, đơn giản và nhanh chóng, từ bước code đến sử dụng, rõ ràng là một ưu điểm để chúng ta cân nhắc khi có use case phù hợp. Ngoài ra, vì cũng là bookmark nên bookmarklet vẫn có thể được sử dụng trên mobile, đây là một lợi thế đáng chú ý so với extension.

# Cách tạo một bookmarklet

Hôm nay mình thấy có bạn đăng bài về [cách tải tất cả ảnh trên trang web bằng JS](https://viblo.asia/p/download-all-images-tren-website-su-dung-javascript-bJzKm4ED59N) khá hay, mình sẽ hiện thực chức năng này bằng bookmarklet và chúng ta cùng xem nó đơn giản như thế nào:

Cú pháp để tạo một bookmarklet như sau:
```js
javascript:(function(){
  // code
})();
```

Code chức năng tải ảnh mình sẽ viết như sau:
```js
javascript: (function () {
  document.querySelectorAll("img").forEach((img) => {
    fetch(img.src)
      .then((response) => response.blob())
      .then((blob) => {
        var a = document.createElement("a");
        a.href = URL.createObjectURL(blob);
        a.download = img.src.split("/").pop();
        a.target = "blank";
        a.click();
      });
  });
})();
```

Sau đó, copy code này vào ô URL của bookmark:
![](https://images.viblo.asia/500/ce24fad5-3215-4f32-9b9d-edd8421fa704.png)

Lưu lại, vậy là xong. Chỉ mất một phút để có một tool tải tất cả ảnh trên trang web, quá đơn giản phải không? Khi cần sử dụng, chỉ việc mở thanh bookmark (hoặc bấm tổ hợp phím **Ctrl + Shift + B**) và nhấp vào bookmark mà chúng ta vừa lưu.

## Chia sẻ bookmarklet

Để chia sẻ bookmarklet của mình cho những người khác, các bạn có thể áp dụng cách tương tự như trang [Wirify](https://www.wirify.com/) này. Những gì họ làm, đơn giản chỉ là gán đoạn code JS vào `href` của môt thẻ anchor như sau:
```html
<a href="javascript:(function(){//code})()">Tên Bookmarklet</a>
```

Những người khác nếu muốn dùng, chỉ cần kéo link đó vào thanh bookmark của mình là xong.

## Dùng remote code

Trường hợp đoạn code JS cần dùng quá nhiều, hoặc bạn cần lưu trữ code ở một host nào đó để tiện cho việc phát triển, và code được dùng lúc nào cũng là phiên bản build mới nhất, các bạn có thể áp dụng thủ thuật sau để remote tới code:

```js
javascript: (function() {
    var script = document.createElement("script");
    script.src = "https://my-code.min.js?" + new Date().getTime();
    document.body.appendChild(script);
})();
```

# Một số bookmarklet hữu ích

Dưới đây là vài bookmarklet được viết sẵn, khá tiện lợi mà các bạn có thể sử dụng ngay, chỉ với 1 click chuột.

* **[Bootlint](https://github.com/twbs/bootlint)**: HTML linter dành cho các trang web sử dụng Bootstrap.
    ```js
    javascript:(function(){var s=document.createElement("script");s.onload=function(){bootlint.showLintReportForCurrentDocument([]);};s.src="https://stackpath.bootstrapcdn.com/bootlint/latest/bootlint.min.js";document.body.appendChild(s)})();
    ```
* **[a11y.css](https://ffoodd.github.io/a11y.css/)**: Hiển thị lỗi HTML trên trang web.
    ```js
    javascript:(function(){a11ycss=document.createElement("LINK");a11ycss.href="https://ffoodd.github.io/a11y.css/css/a11y-en.css";a11ycss.rel="stylesheet";a11ycss.media="all";document.body.appendChild(a11ycss);})();
    ```
* **[Instantgram](https://theus.github.io/instantgram/)**: Hỗ trợ xem và tải ảnh trên Instagram.
    ```js
    javascript:(function (){d=document;d.body.appendChild(d.createElement("script")).src="https://raw.githubusercontent.com/theus/instantgram/gh-pages/dist/main.js";})();
    ```
* **[Performance Bookmarklet](https://github.com/micmro/performance-bookmarklet)**: Phân tích, hiển thị số liệu hiệu suất của trang web.
    ```js
    javascript:(function(){var el=document.createElement('script');el.type='text/javascript';el.src='https://micmro.github.io/performance-bookmarklet/dist/performanceBookmarklet.min.js';el.onerror=function(){alert("Looks like the Content Security Policy directive is blocking the use of bookmarklets\n\nYou can copy and paste the content of:\n\n\"https://micmro.github.io/performance-bookmarklet/dist/performanceBookmarklet.min.js\"\n\ninto your console instead\n\n(link is in console already)");console.log("https://micmro.github.io/performance-bookmarklet/dist/performanceBookmarklet.min.js");};document.getElementsByTagName('body')[0].appendChild(el);})();
    ```
* **Soạn thư Gmail**: mở Gmail chế độ soạn thư + chèn sẵn title và URL của trang bạn đang đứng + chèn sẵn phần văn bản mà bạn copy. Bạn chỉ việc điền người nhận và gửi.
    ```js
    javascript:(function (){popw="";Q="";d=document;w=window;if(d.selection){Q=d.selection.createRange().text;}else if(w.getSelection){Q=w.getSelection();}else if(d.getSelection){Q=d.getSelection();}popw=w.open("http://mail.google.com/mail/s?view=cm&fs=1&tf=1&to=&su="+encodeURIComponent(d.title)+"&body="+encodeURIComponent(Q)+escape("%5Cn%5Cn")+encodeURIComponent(d.location)+"&zx=RANDOMCRAP&shva=1&disablechatbrowsercheck=1&ui=1","gmailForm","scrollbars=yes,width=680,height=575,top=175,left=75,status=no,resizable=yes");if(!d.all)setTimeout(function (){popw.focus();},50);})();
    ```
* **Mở khóa chuột**: một số trang khóa chuột phải, không cho phép bạn chọn khối văn bản, đoạn code sau kích hoạt lại.
    ```js
    javascript:(function (){function R(a){ona="on"+a;if(window.addEventListener)window.addEventListener(a,function (e){for(var n=e.originalTarget;n;n=n.parentNode)n[ona]=null;},true);window[ona]=null;document[ona]=null;if(document.body)document.body[ona]=null;}R("click");R("mousedown");R("mouseup");R("selectstart");R("contextmenu");})();
    ```
* **Hiển thị mật khẩu**: một số trang không có chức năng hiển thị mật khẩu bạn đang nhập.
    ```js
    javascript:(function(){var s,F,j,f,i;s="";F=document.forms;for(j=0;j<F.length;++j){f=F[j];for(i=0;i<f.length;++i){if(f[i].type.toLowerCase()=="password")s+=f[i].value+"\n";}}if(s)alert("Passwords in forms on this page:\n\n"+s);else alert("There are no passwords in forms on this page.");})();
    ```
* **Tìm kiếm nhanh**: tìm kiếm từ khóa trên trang (ở đây mình tìm trên trang "viblo.asia").
    ```js
    javascript:(function (){s="viblo.asia";void(q=prompt("Searching at "+s+":"));if(q)location.href="http://www.google.com/search?q=site%3A"+s+" "+escape(q);})();
    ```

# Kết
Bài chia sẻ ngắn nhưng hi vọng các bạn cũng biết được một thứ mới, thú vị và hữu ích để tận dụng vào công việc, cuộc sống của mình 🙂 Cảm ơn các bạn đã theo dõi.

Tham khảo: [Bookmarklet - Wikipedia](https://en.wikipedia.org/wiki/Bookmarklet)

----
@khangnd<br>[![Github](https://images.viblo.asia/20x20/81dd12f0-a8c9-403f-ae51-27b92828ca22.png)](https://github.com/khang-nd) [![Linkedin](https://images.viblo.asia/20x20/4981766e-5e57-401a-8623-d3657a3148e5.png)](https://www.linkedin.com/in/khangnd/) [![Dev.to](https://images.viblo.asia/20x20/3921db2e-e4e5-45d7-acc8-e8b92e02d47d.png)](https://dev.to/khangnd) [![Fandom](https://images.viblo.asia/20x20/fad64df3-0be8-4481-b810-8995f18f71ea.png)](https://dev.fandom.com/wiki/User:KhangND)

Có lẽ kỹ thuật này đã xuất hiện từ rất lâu và chắc nhiều người đã biết tới, nhưng thực sự thì đến giờ mình mới được biết đến, cảm thấy nó cực kỳ tiện lợi và thú vị nên muốn chia sẻ lại cho những bạn chưa biết. Chúng ta cùng tìm hiểu về Bookmarklet và xem cách tạo một tool đơn giản và tiện lợi bằng kỹ thuật này như thế nào nhé.

Bookmarklet là gì?
Khi sử dụng trình duyệt web, các bạn hẳn đã khôn...

Bookmarklet - Tạo tính năng để tương tác với trang web thật đơn giản

Nguyen Van Hung

HungHocHoi

Lữ Quang Minh

![Uninstall Live Server](https://images.viblo.asia/568d067b-34a7-45bd-a767-973a204df400.png)

Hôm nay là một ngày Chủ Nhật cuối tuần đẹp trời  để... code. Như bao ngày cuối tuần, mình lại ngồi vào máy, bật VS Code để vọc vạch những thứ linh tinh về web, JS các kiểu. Lâu ngày mở lại cái pet project từ thời tám hoánh nào đó mà mình viết bằng HTML, CSS, JS thuần, cái thời chưa biết React, Vue là cái beep gì, lúc đấy toàn xài cái [Live Server Extension](https://github.com/ritwickdey/vscode-live-server) để phục vụ cho việc development. Vậy mà hôm nay, vì một lý do magic nào đó mà cái extension thân yêu khi xưa không còn hoạt động nữa (hẳn là do bản cập nhật của VS Code chứ chẳng có magic gì 😄), thế là mình lên repo của tác giả để xem thì thấy 1 nùi issue tương tự kèm một đống pull request đã khá lâu nhưng vẫn chưa được review/merge, chắc tác giả đang quá bận để maintain cái extension. Vậy là mình quyết định tìm hiểu "under the hood", và thế là bài viết này ra đời để chia sẻ những gì mình biết về **Live Server** và giải pháp thay thế nếu bạn không dùng extension được.

# TL;DR

Giải pháp thay thế cho extension là:

* Cài [Node](https://nodejs.org/en/) nếu máy của bạn chưa có.
* Mở Cmd hoặc CLI của VS code, nhập `npm i live-server -g`.
* Chuyển đến thư mục cần mở server, nhập `live-server`.

Vậy là xong, thư mục của bạn đã được host lên server local với địa chỉ + port mặc định.
Nếu muốn tìm hiểu kỹ hơn thì mời các bạn đọc tiếp.

**Update**: Các bạn cũng có thể sử dụng [serve](https://www.npmjs.com/package/serve) để dễ dàng tạo một server, hỗ trợ luôn *https*.

# Hiểu công cụ của mình

Chắc nhiều bạn cũng như mình, trước giờ code web nghe nhiều người khuyên dùng VS Code, rồi nhớ cài thêm Live Server extension mà cũng chưa tìm hiểu kỹ về công cụ của mình 😄. Chuyện thường ở huyện ấy mà, tới lúc cần thì sẽ tìm hiểu thôi, mà giờ chắc là lúc rồi.

**Live Server** là một tiện ích dành cho VS Code giúp dân chơi hệ front-end đỡ khổ khi cần phải phát triển một trang web/web app tĩnh (static) hoặc độc lập với back-end (giao tiếp bằng các micro service/RESTful API). Nếu đào sâu tí vào source code, các bạn sẽ biết extension này được phát triển trên [**một bộ core cùng tên**](https://github.com/tapio/live-server), tích hợp thêm nhiều tính năng, nhưng chung quy lại vẫn xoay quanh 2 tính năng cơ bản sau:

* Cho phép gửi Http request lên các service, việc mà các bạn không thể thực hiện với giao thức `file://` vì lý do an ninh, bảo mật.
* Tự động reload lại trang khi có sửa đổi trong các file được theo dõi (watch), giúp tốc độ code tăng đáng kể.

Nếu đào sâu hơn vào chi tiết cách implement của bộ core, các bạn sẽ thấy cơ bản là tác giả xây dựng một server chạy trên local nên việc gửi request có thể được thực hiện. Ngoài ra, việc hot reload cũng được tích hợp với sự hỗ trợ của một thư viện khác gọi là **chokidar**, thư viện cung cấp một interface dễ sử dụng phục vụ việc theo dõi file và xử lý ứng với event đã quy định.

Sức mạnh của open source quả là lợi hại 👍

# Giải pháp thay thế

Ok, giờ hiểu sơ sơ cái Live Server extension của mình rồi thì việc tìm cách khắc phục cũng sẽ khả thi, hoặc chí ít cũng có cách workaround chứ không bí thế mà phải đợi ông tác giả fix cái extension của ổng, có khi tới mùa mít. Đây cũng là một trong những kỹ năng problem solving quan trọng mà dân kỹ thuật chúng ta cần.

Như đã nói trên, cái extension này cũng chỉ được phát triển dựa trên một bộ core là [**Live Server**](https://github.com/tapio/live-server), giờ chỉ cần bỏ tí tẹo thời gian ra đọc hướng dẫn sử dụng là mình setup được cái server mà không cần extension ấy mà.

* Đầu tiên, việc cần làm là cài NodeJS vì Live Server là một Node package.
* Sau khi cài Node, các bạn mở Cmd hoặc command line của VS Code để cài package Live Server bằng lệnh `npm i live-server -g`.
* Vậy là chúng ta đã cài đặt xong, từ giờ mỗi lần cần host một thư mục hoặc file nào đó, chỉ cần mở thư mục đó trong VS Code, hoặc trỏ đến đường dẫn thư mục và chạy lệnh `live-server` trong command line.

Khi cần thay đổi cấu hình server, vd như IP hay port, chỉ cần truyền thêm các đối số tương ứng vào CLI. Truy cập [repo](https://github.com/tapio/live-server#usage-from-command-line) để xem danh sách đầy đủ các đối số được hỗ trợ.
Ví dụ để thay đổi port mặc định thành 3000, và mở bằng trình duyệt Firefox sau khi server được kích hoạt:

```shell
live-server --port=3000 --browser=Firefox
```

## Kích hoạt bằng phím tắt

Tuy giải pháp thay thế đã có, nhưng sau mấy bước setup, chạy lệnh phiền phức, cái Live Server extension vẫn lợi hại hơn đúng không? Rõ ràng là vậy, chứ nếu không đâu tự nhiên mà cái extension tới 10M+ lượt tải. Tuy không hoàn toàn xịn như extension, nhưng chúng ta vẫn có thể tự đặt một phím tắt cho câu lệnh `live-server`, kèm theo cấu hình chúng ta hay dùng, xem nhé:

* Trong VS Code, bấm phím **F1**, một Command Palette sẽ hiện ra bao gồm tất cả chức năng của VS Code.
* Gõ tìm `keyboard shortcuts` và chọn **Preferences: Open Keyboard Shortcuts (JSON)**
* Nhập vào đoạn code sau để thiết lập phím tắt:
```json
{
  "key": "alt+l alt+o",
  "command": "workbench.action.terminal.sendSequence",
  "args": {
    "text": "live-server --port=3000 --browser=Firefox\u000D"
  }
}
```

Từ giờ mỗi lần muốn kích hoạt Live Server, chúng ta chỉ cần mở CLI (bấm **Ctrl + \`**) và tổ hợp phím **Alt + L, Alt + O** là xong.

# Kết

Vậy là mình đã chia sẻ xong một giải pháp để giải quyết vấn đề không sử dụng được cái extension Live Server thân yêu. Chắc hẳn nhiều bạn vẫn còn nhiều giải pháp xịn và sáng tạo hơn nhiều, nhưng nhìn chung thì quan trọng vẫn là cố gắng hiểu rõ bản chất của mọi thứ mình dùng và làm, từ cách thức, công cụ, đến code, và cuối cùng là sản phẩm, để chúng ta có thể nắm quyền kiểm soát và đưa ra những giải pháp thay thế phù hợp khi có vấn đề xảy ra.

PS: Cái ảnh để câu view thôi nha, đừng gỡ extension, biết đâu mai này tác giả quay lại fix, còn update thêm nhiều tính năng pro hơn nữa sao 😂

----
@khangnd<br>[![Github](https://images.viblo.asia/20x20/81dd12f0-a8c9-403f-ae51-27b92828ca22.png)](https://github.com/khang-nd) [![Linkedin](https://images.viblo.asia/20x20/4981766e-5e57-401a-8623-d3657a3148e5.png)](https://www.linkedin.com/in/khangnd/) [![Dev.to](https://images.viblo.asia/20x20/3921db2e-e4e5-45d7-acc8-e8b92e02d47d.png)](https://dev.to/khangnd) [![Fandom](https://images.viblo.asia/20x20/fad64df3-0be8-4481-b810-8995f18f71ea.png)](https://dev.fandom.com/wiki/User:KhangND)



Hôm nay là một ngày Chủ Nhật cuối tuần đẹp trời  để... code. Như bao ngày cuối tuần, mình lại ngồi vào máy, bật VS Code để vọc vạch những thứ linh tinh về web, JS các kiểu. Lâu ngày mở lại cái pet project từ thời tám hoánh nào đó mà mình viết bằng HTML, CSS, JS thuần, cái thời chưa biết React, Vue là cái beep gì, lúc đấy toàn xài cái Live Server Extension để phục vụ cho việc development. Vậy ...

Live Server - Làm gì khi cái VS Code extension thân yêu trở chứng?

Lúc mới học JS, mình chỉ biết mỗi một kiểu cơ bản nhất là:
```calculator.js
function add(a, b) {
    return a + b;
}
```

```index.html
<!DOCTYPE html>
<html lang="en">
<body>
    <script src="calculator.js"></script>
    <script>
        console.log(add(4, 6)) // 10
    </script>
</body>
</html>
```

Đúng vậy, khi cần tách code, cứ nhóm tất cả các hàm liên quan với nhau vào một file, khi cần lôi các hàm ra dùng thì nhúng file này vào trang HTML bằng thẻ `<script>`, quá ez luôn. Nhưng khi bắt đầu ra lăn lộn giang hồ + sự tiến hóa không ngừng của công nghệ, mình gặp phải nhiều cú pháp ngoài hình tinh để tách code, cũng bị xoắn não và mệt mỏi lắm mới có thể nắm bắt được. Nên trong bài viết này, mình xin tổng hợp và chia sẻ **các kiểu khai báo module** phục vụ việc tách code và cách phân biệt từng kiểu để dễ nhớ.

Bài viết sẽ không nói về khái niệm "Module là gì?" hay "Sao phải sử dụng module?", bởi vì đã có nhiều bài viết trả lời những câu hỏi này, và mình nghĩ chắc nhiều bạn cũng như mình, chả thể nuốt nổi ba cái lý thuyết nếu không ứng dụng thực tế để thật sự hiểu và tự trả lời cho mấy câu hỏi trên.

# Các kiểu khai báo
## 1. IIFE
Viết tắt của **Immediately Invoked Function Expression**, hiểu đơn giản là "tạo hàm, gọi liền". Đây là kỹ thuật sơ khai nhất được các bậc tiền nhân phát minh và vẫn đang được sử dụng rộng rãi cho các bộ compiler/bundler như Babel, Webpack, Rollup... nhằm chuyển các cú pháp khai báo module hiện đại về code JavaScript thuần (< ES6). Nếu các bạn đọc source của jQuery, thư viện từng thống trị một thời, thì sẽ thấy nhiều đoạn cũng sử dụng IIFE. Cú pháp có dạng như sau:

```js
(function() {
    // code
})();
```

Nhìn có vẻ hack não bởi cả đống ngoặc, nhưng nếu viết dạng tương đương dưới đây chắc bạn dễ nhìn hơn:

```js
function add() {
    // code
}
add();
```

Như các bạn thấy, hàm `add()` sau khi tạo liền được gọi, để hiểu rõ nữa thì các bạn chịu khó search bài viết khác nhé, mình quay lại với cách khai báo module. **IIFE** giúp ẩn các code được xử lý bên trong và chỉ xuất ra những gì mà chúng ta muốn. Ví dụ:

```js
var text = (function() {
    var privateText = "Text không thể truy cập!";
    var publicText = "Text được phép truy cập!"
    return publicText;
})();
console.log(text); // Text được phép truy cập!
```

Một ví dụ phức tạp hơn:

```js
var calculator = (function() {
    function add(a, b) {
        return a + b;
    }
    function subtract(a, b) {
        return a - b;
    }
    function divide(a, b) {
        return a / b;
    }
    return {
        add: add,
        subtract: subtract,
    };
})();
console.log(calculator.add(2, 2)); // 4
console.log(calculator.subtract(2, 2)); // 0
console.log(calculator.divide(2, 2)); // Xảy ra lỗi vì hàm "divide" không được xuất ra ngoài
```

## 2. CJS
Viết tắt của **CommonJS**. Dân chơi hệ back-end, đặc biệt là những ai hay sử dụng NodeJS chắc hẳn không lạ gì với cái tên này. Xuất hiện lần đầu với tên gọi **ServerJS** thay vì CommonJS như bây giờ, nghe tên là biết ngay mục tiêu của dự án là nhắm vào một hệ sinh thái module dành cho JavaScript phía back-end, CommonJS đến nay vẫn đang gắn bó thân thiết với một số nền tảng phổ biến như NodeJS, MongoDB... Ví dụ cách khai báo module bằng CJS:

```calculator.js
function add(a, b) {
    return a + b;
}
function subtract(a, b) {
    return a - b;
}
module.exports = {
    // những gì cần xuất ra ngoài được đặt trong này
    add: add,
    subtract: subtract,
};
```

```index.js
// dùng "require" để load module "calculator.js" (phần đuôi .js có thể được lược bỏ)
var calculator = require("./calculator");
console.log(calculator.add(2, 2)); // 4
console.log(calculator.subtract(2, 2)); // 0
```

## 3. AMD
Viết tắt của **Asynchronous Module Definition**. Như tên gọi, nhiệm vụ của AMD là quy định kiểu khai báo cho module và load *bất đồng bộ* các dependency của module đó nếu có. Do đó, trái với CJS, AMD sinh ra để dành cho dân chơi hệ front-end. Cú pháp đầy đủ có dạng như sau:

```js
define(id?, dependencies?, factory);
```

Các đối số:
* `id` (string): Tên định danh cho module. Không bắt buộc, nhưng cần khi khai báo module.
* `dependencies` (array): mảng chứa tên các module khác cần được load. Không bắt buộc nếu không có dependency.
* `factory` (object/function): object hoặc function để khởi tạo cho module.

Cùng xem ví dụ sau để dễ hình dung hơn:

```calculator.js
// module với tên "calculator" được khai báo là một object chứa 2 hàm.
define("calculator", {
    add: function(a, b) {
        return a + b;
    },
    subtract: function(a, b) {
        return a - b;
    },
});
```

```index.js
// dùng hàm "require" để load module "calculator"
require(["calculator"], function(calculator) {
    console.log(calculator.add(2, 2)); // 4
    console.log(calculator.subtract(2, 2)); // 0
});
```

## 4. UMD
Viết tắt của **Universal Module Definition**. UMD có một sứ mệnh là mang back-end và front-end đến gần nhau hơn, bằng việc hỗ trợ nhiều trường hợp để tương thích cho cả hai, bao gồm cả browser global. Vì lý do này mà code của UMD tương đối phức tạp, chúng ta cùng xem ví dụ khai báo một module bằng UMD:

```calculator.js
(function (calculator) {
    if (typeof define === 'function' && define.amd) {
        // xuất bằng AMD
        define("calculator", calculator);
    } else if (typeof module === 'object' && module.exports) {
        // xuất bằng CJS
        module.exports = calculator;
    } else {
        // xuất bằng browser global
        window.calculator = calculator;
    }
}({
    add: function(a, b) {
        return a + b;
    },
    subtract: function(a, b) {
        return a - b;
    },
}));
```

```index.js
// load bằng AMD
require(["calculator"], function (calculator) {
    console.log(calculator.add(2, 2));
    console.log(calculator.subtract(2, 2));
});

// load bằng CJS
var calculator = require("./calculator");
console.log(calculator.add(2, 2));
console.log(calculator.subtract(2, 2));

// nếu trong browser thì có thể truy xuất trực tiếp
console.log(calculator.add(2, 2));
console.log(calculator.subtract(2, 2));
```

Qua ví dụ thì các bạn có thể thấy, UMD tập hợp các trường hợp khai báo module khác nhau, giúp module "calculator" có thể được sử dụng cho tất cả môi trường từ trước (front-end) ra sau (back-end).

## 5. ESM
Viết tắt của **ECMAScript Modules**. Còn gọi là ES6 Modules, ESM chính là giải pháp cho một tương lai tươi sáng của hệ sinh thái module bằng việc chuẩn hóa cú pháp khai báo module, hoạt động từ trước ra sau, và được hỗ trợ bởi chính JavaScript mà không cần thông qua bất kì một compiler hay loader nào (trừ việc phải polyfill từ ES6 về các phiên bản ES trước cho các trình duyệt cũ). Chắc hẳn nhiều bạn đã quá quen với đoạn code sau:

```js
import React from "react";
import App from "./App";
render(<App />, document.getElementById("root"));
```

Đúng vậy, đoạn code được sử dụng trong `index.js` của một React App, sử dụng ESM để load các module. Giờ chúng ta cùng xem một ví dụ khác tương đương các ví dụ trên bằng ESM:

```calculator.js
function add(a, b) {
    return a + b;
}
function subtract(a, b) {
    return a - b;
}
export default {
    add,
    subtract,
};
```

```index.js
import calculator from "./calculator";
console.log(calculator.add(2, 2));
console.log(calculator.subtract(2, 2));
```

Ví dụ trên sử dụng `default export` để xuất tất cả những gì cần xuất trong duy nhất một object, ngoài cách này, ESM còn hỗ trợ `named export` cho phép xuất nhiều thứ cùng lúc. Để biết thêm, các bạn search bài viết khác hoặc tham khảo các liên kết bên dưới nhé.

# Tổng kết
Đọc đến đây chắc cũng có bạn còn mông lung, vẫn chưa rõ tại sao lại có quá nhiều kiểu khai báo module trong JavaScript, cũng như làm sao để nhớ hết cả đống kiến thức trên. Mình xin tóm tắt lại những cái quan trọng để mọi người cùng nhớ:

**1. IIFE (Immediately Invoked Function Expression)**
* Kỹ thuật khai báo module cho JS thuần (ES5 trở về trước)
* Cú pháp:
    ```js
    var moduleName = (function() {
        // return something to export
    })();
    ```

**2. CJS (CommonJS)**
* Cú pháp khai báo module được sử dụng dưới back-end (phổ biến nhất là NodeJS)
* Các module được import một cách *đồng bộ*
* Cú pháp:
    ```js
    // export
    module.exports = factory;
    
    // import
    var alias = require("./moduleName")
    ```

**3. AMD (Asynchronous Module Definition)**
* Cú pháp khai báo module được sử dụng trên front-end (thông qua bộ loader phổ biến là RequireJS)
* Các module được import một cách *bất đồng bộ*
* Cú pháp:
    ```js
    // export
    define("moduleName", ["dependency1", "dependency2", ...], factory);
    
    // import
    require(["moduleName"], function(alias) {
        // code
    });
    ```

**4. UMD (Universal Module Definition)**
* Kỹ thuật kết hợp nhiều cú pháp khai báo module
* Tương thích với front-end lẫn back-end
* Cú pháp tương đối phức tạp
* Cú pháp:
    ```js
    (function (factory) {
        if (typeof define === 'function' && define.amd) {
            define("moduleName", factory);
        } else if (typeof module === 'object' && module.exports) {
            module.exports = factory;
        } else {
            window["moduleName"] = factory;
        }
    })(factory);
    ```

**5. ESM (ECMAScript Modules)**
* Cú pháp khai báo module được chuẩn hóa, hỗ trợ trực tiếp bởi JS thuần (ES6 trở về sau)
* Tương thích với front-end lẫn back-end
* Cú pháp đơn giản nhưng đa dạng, linh động hơn
* Cú pháp:
    ```js
    // default exports
    export default { }
    export default function fnA() { }
    export default class classB { }

    // named exports
    export function fnA() { }
    export var varB = "";
    
    // default import
    import alias from "moduleName";

    // named imports
    import * as alias from "moduleName";
    import { fnA, varB } from "moduleName";
    ```

# Tham khảo
* [FreeCodeCamp - JavaScript Modules: A Beginner's Guide](https://www.freecodecamp.org/news/javascript-modules-a-beginner-s-guide-783f7d7a5fcc/)
* [Dev.to - What are CJS, AMD, UMD, and ESM in JavaScript](https://dev.to/iggredible/what-the-heck-are-cjs-amd-umd-and-esm-ikm)
* [Wikipedia - Asynchronous module definition](https://en.wikipedia.org/wiki/Asynchronous_module_definition)
* [Github - AMD Specification](https://github.com/amdjs/amdjs-api)
* [Github - UMD Pattern](https://github.com/umdjs/umd)
* [ExploringJS - ES6 Modules](https://exploringjs.com/es6/ch_modules.html)

----
@khangnd<br>[![Github](https://images.viblo.asia/20x20/81dd12f0-a8c9-403f-ae51-27b92828ca22.png)](https://github.com/khang-nd) [![Linkedin](https://images.viblo.asia/20x20/4981766e-5e57-401a-8623-d3657a3148e5.png)](https://www.linkedin.com/in/khangnd/) [![Dev.to](https://images.viblo.asia/20x20/3921db2e-e4e5-45d7-acc8-e8b92e02d47d.png)](https://dev.to/khangnd) [![Fandom](https://images.viblo.asia/20x20/fad64df3-0be8-4481-b810-8995f18f71ea.png)](https://dev.fandom.com/wiki/User:KhangND)

Lúc mới học JS, mình chỉ biết mỗi một kiểu cơ bản nhất là:
function add(a, b) {
    return a + b;
}

Đúng vậy, khi cần tách code, cứ nhóm tất cả các hàm liên quan với nhau vào một file, khi cần lôi các hàm ra dùng thì nhúng file này vào trang HTML bằng thẻ <script>, quá ez luôn. Nhưng khi bắt đầu ra lăn lộn giang hồ + sự tiến hóa không ngừng của công nghệ, mình gặp phải nhiều cú pháp ngoài hình...

JS Modules - Bao nhiêu kiểu khai báo, làm sao nhớ hết?

Trần Việt

![](https://images.viblo.asia/5c0ea105-1da9-48cb-82ab-85c4e0ffcf56.png)

> Đã bao giờ bạn gặp khó khăn khi phải suy nghĩ nên đặt tên biến/hàm như thế nào trong lúc code?

Nếu câu trả lời là No, hi vọng là vì bạn đã hiểu rõ và tự tin vào cách đặt tên của mình, còn nếu No vì bạn chả bao giờ quan tâm đến cách đặt tên, thì xin chia buồn, bạn đã gián tiếp tạo nghiệp cho anh em trong team khi phải review code, hoặc những hậu bối khi phải maintain code của bạn, bởi vì, họ ít nhiều đang ngồi rủa bạn 😅

Nếu câu trả lời là Yes, thì hoan nghênh bạn đến với bài tổng hợp các quy tắc đặt tên cho hàm/biến từ một repo cực kỳ hay ho mà mình tìm được trên Github: [**kettanaito/naming-cheatsheet**](https://github.com/kettanaito/naming-cheatsheet#naming-cheatsheet). Đa phần nội dung trong bài viết mình dựa trên repo đó, nhưng một số chỗ và ví dụ đã được mình chỉnh sửa cho đơn giản và dễ hiểu hơn. Lưu ý là tuy ngôn ngữ lập trình được sử dụng trong các ví dụ là JavaScript, nhưng các quy tắc này có thể được áp dụng cho bất kỳ ngôn ngữ nào.

# Dùng tiếng Anh
> Luôn sử dụng tiếng Anh để đặt tên hàm và biến.

Tiếng Anh là ngôn ngữ tất yếu trong lập trình, từ chính cú pháp được viết bằng tiếng Anh, đến các tài liệu nghiên cứu, giáo dục, hầu hết cũng bằng tiếng Anh. Nên khi bạn viết code bằng tiếng Anh, code của bạn và cú pháp sẽ liền mạch hẳn. Nếu như bạn cảm thấy khả năng tiếng Anh của mình chưa tốt thì lời khuyên chân thành là nên cố gắng trau dồi, ít nhất đạt được khả năng đọc viết ở mức ok.

```javascript
/* Bad */
const hoTen = "Trạng Tí"
const banBe = ["Sửu Ẹo", "Dần Béo", "Cả Mẹo"]

/* Good */
const fullName = "Trạng Tí"
const friends = ["Sửu Ẹo", "Dần Béo", "Cả Mẹo"]
```

# Quy ước đặt tên
> Quy ước nào cũng được, quan trọng là consistency (nhất quán).

Nếu team của bạn chọn quy ước đặt tên là `camelCase`, hãy sử dụng `camelCase` cho toàn bộ dự án, nếu bạn qua một team khác chuộng `snake_case` hơn, hãy tuân thủ nghiêm ngặt. Cho dù là quy ước nào thì điều quan trọng nhất chính là tính nhất quán.

```javascript
/* Bad */
const page_count = 5
const isUser = true

/* Good */
const pageCount = 5
const isUser = true

/* Good as well */
const page_count = 5
const is_user = true
```

# Nguyên tắc S-I-D
> Short, Intuitive, Descriptive.

* **Short** (ngắn gọn): tên không được dài, không phải mất thời gian để gõ và nhớ.
* **Intuitive** (tự nhiên): tên khi đọc lên phải cho cảm giác xuôi tai, gần gũi với văn nói.
* **Descriptive** (súc tích): tên phải mô tả được ý nghĩa, tác dụng của nó, bằng cách hiệu quả nhất.

```javascript
/* Bad */
const totalNumberOfPublishedArticles = 10 // tên quá dài
const a = 5 // "a" không mô tả được số 5 để làm gì
const isDisplayable = a > 5 // "isDisplayable" nghe không tự nhiên lắm

/* Good */
const totalArticles = 10
const postCount = 5
const shouldDisplay = postCount > 5
```

# Tránh viết tắt
> Không được sử dụng từ viết tắt.

Viết tắt không giúp ích gì mà chỉ làm code của bạn khó đọc hơn. Có thể bạn thấy từ viết tắt đó dễ hiểu đối với bạn, nhưng chắc gì người khác hiểu được. Có thể bạn khó nghĩ ra một cái tên vừa ngắn vừa súc tích, nhưng nên cố gắng nghĩ cho ra, không nên chọn giải pháp viết tắt.

```javascript
/* Bad */
function onItmClk(ev) { }

/* Good */
function onItemClick(event) { }
```

# Tránh lặp từ
> Tận dụng context để đặt tên không lặp từ.

Ví dụ về một context thường thấy là trường hợp khi khai báo hàm trong một class, nhiều bạn có xu hướng đặt tên hàm có chứa từ đã có trong class. Có thể lược bỏ các từ đó đi để tên hàm được gọn và dễ đọc hơn.

```javascript
class User {
    /* Bad */
    updateUserProfile() { }

    /* Good */
    updateProfile() { }
}
```

# Số ít, số nhiều
> Áp dụng ngữ pháp số nhiều của tiếng Anh.

Đối với mảng có chứa nhiều phần tử, chúng ta có thể sử dụng ngữ pháp số nhiều của tiếng Anh để đặt tên, vừa ngắn gọn, vừa đủ nghĩa. *Trong tiếng Anh, đối với danh từ đếm được, chúng ta chỉ cần thêm `s` ở cuối danh từ để biểu thị số nhiều.*

```javascript
/* Bad */
const friend = ["Sửu Ẹo", "Dần Béo", "Cả Mẹo"]

/* Good */
const friends = ["Sửu Ẹo", "Dần Béo", "Cả Mẹo"]
```

# Tên hàm kiểu A/HC/LC
Đối với tên hàm, có một kiểu đặt tên cực kỳ phổ biến mà có lẽ các bạn ít nhiều cũng đã từng gặp qua. Kiểu đó có dạng như sau:
```
prefix? + action (A) + high context (HC) + low context? (LC)
```

Ví dụ:
| Name | Prefix   | Action (A) | High context (HC) | Low context (LC) |
| ---------------------- | -------- | ---------- | ----------------- | ---------------- |
| `getUser`              |          | `get`      | `User`            |                  |
| `getUserMessages`      |          | `get`      | `User`            | `Messages`       |
| `handleClickOutside`   |  | `handle`   | `Click`           | `Outside`        |                
| `shouldDisplayMessage` |  `should` | `Display`  | `Message`         |                 |

Nhìn quen chứ? Chúng ta sẽ đi sâu vào từng phần để hiểu rõ hơn. Một lưu ý quan trọng là thứ tự của các chữ cũng có ảnh hưởng đến ý nghĩa của tên. Ví dụ như `shouldUpdateComponent` có nghĩa **bạn** là người sẽ update component, nhưng khi đảo thứ tự thành `shouldComponentUpdate`, nghĩa là **component** sẽ tự update, bạn chỉ kiểm soát khi nào nó được update thôi.

## Actions
> Động từ chỉ hành động của hàm

Đa số các hàm đều sẽ bắt đầu bằng action để diễn tả hàm này sẽ làm gì. Một số từ dùng làm action phổ biến:

**`get`**: Truy xuất/lấy dữ liệu.
```javascript
class User {
    getRole() {
        return this.role;
    }
}
user.getRole();
```

**`set`**: Gán giá trị cho biến.
```javascript
class User {
    setRole(newRole) {
        this.role = newRole;
    }
}
user.setRole("Admin");
```

**`reset`**: Đặt lại giá trị/trạng thái ban đầu.
```javascript
class User {
    resetRole() {
        this.role = "User";
    }
}
user.resetRole();
```

**`fetch`**: Gửi request để lấy dữ liệu.
```javascript
function fetchUsers() {
    return fetch("https://api.viblo.asia/users", {...});
}
```

**`remove`**: Loại bỏ một phần tử khỏi mảng, danh sách, hoặc tập hợp (cần lưu ý điểm khác biệt giữa `remove` và `delete`).
```javascript
function removeItem(name, items) {
    return items.filter((itemName) => itemName !== name);
}
const initialItems = ["Giày", "Dép", "Quần áo"];
removeItem("Dép", initialItems); // ["Giày", "Quần áo"]
```

**`delete`**: Xóa bỏ hoàn toàn sự tồn tại của một cá thể.
```javascript
function deletePost(id) {
    return database.find({ id }).delete();
}
```

**`create`**: Tạo dữ liệu mới.
```javascript
function createRole(roleInfo) {
    return database.create(roleInfo);
}
```

**`handle`**: Xử lý sự kiện hoặc callback (ngoài `handle` thì `on` cũng hay được sử dụng).
```javascript
function handleClick(event) {
    console.log(event.target);
}
button.addEventListener("click", handleClick);
```

## Context
> Bối cảnh xử lý của hàm

Hiểu đơn giản thì context là mục đích của hàm, hàm tồn tại để xử lý cái gì. Ví dụ:
```javascript
/* "Role" là context của hàm, hàm tồn tại để tạo role  */
function createRole(roleInfo) { }

/* "RecentPosts" là context của hàm, với "Recent" gọi là Low Context,
 và "Posts" gọi là High Context, hoặc có thể ngược lại */
function getRecentPosts(user) { }
```

Trong một số trường hợp, có thể bỏ qua không cần dùng context. Ví dụ như khi hàm được khai báo trong một class, hoặc khi hàm đó chuyên được dùng để xử lý một kiểu dữ liệu nào đó:

```javascript
/* Class Role đã là context của hàm */
class Role {
    create(roleInfo) { }
}

/* Sort chuyên được dùng để sắp xếp danh sách/mảng,
 không cần thiết phải thêm sortList hay sortArray */
function sort(condition, list) { }
```

## Prefixes
> Tiền tố giúp tăng ý nghĩa của hàm/biến

**`is`**: Mô tả đặc điểm hoặc trạng thái của context (thường là `boolean`).
```javascript
const color = "blue"
const isBlue = color === "blue" // đặc điểm
const isPresent = true // trạng thái

if(isBlue && isPresent) {
    console.log("Blue is present");
}
```

**`has`**: Xác định sự tồn tại hoặc trạng thái của context (thường là `boolean`).
```javascript
/* Bad */
const isProductsExist = productCount > 0 // sai ngữ pháp
const areProductsPresent = productCount > 0 // chưa gọn, đọc không xuôi tay lắm

/* Good */
const hasProducts = productCount > 0
```

**`should`**: Thể hiện điều kiện sẽ xảy ra của một hành động (thường là `boolean`).
```javascript
function shouldUpdateUrl(url, expectedUrl) {
    return url !== expectedUrl;
}
```

**`min`/`max`**: Mô tả giới hạn của context (thường là `numeric`).
```javascript
function getPosts(posts, minPosts, maxPosts) {
    return posts.slice(0, randomBetween(minPosts, maxPosts));
}
```

**`prev`/`next`**: Thể hiện sự chuyển từ trạng thái cũ sang trạng thái mới.
```javascript
function fetchPosts() {
    const prevPosts = this.state.posts;
    const fetchedPosts = fetch(...);
    const nextPosts = concat(prevPosts, fetchedPosts);
    this.setState({ posts: nextPosts });
}
```

----
@khangnd<br>[![Github](https://images.viblo.asia/20x20/81dd12f0-a8c9-403f-ae51-27b92828ca22.png)](https://github.com/khang-nd) [![Linkedin](https://images.viblo.asia/20x20/4981766e-5e57-401a-8623-d3657a3148e5.png)](https://www.linkedin.com/in/khangnd/) [![Dev.to](https://images.viblo.asia/20x20/3921db2e-e4e5-45d7-acc8-e8b92e02d47d.png)](https://dev.to/khangnd) [![Fandom](https://images.viblo.asia/20x20/fad64df3-0be8-4481-b810-8995f18f71ea.png)](https://dev.fandom.com/wiki/User:KhangND)

![](https://images.viblo.asia/5c0ea105-1da9-48cb-82ab-85c4e0ffcf56.png)



Đã bao giờ bạn gặp khó khăn khi phải suy nghĩ nên đặt tên biến/hàm như thế nào trong lúc code?

Nếu câu trả lời là No, hi vọng là vì bạn đã hiểu rõ và tự tin vào cách đặt tên của mình, còn nếu No vì bạn chả bao giờ quan tâm đến cách đặt tên, thì xin chia buồn, bạn đã gián tiếp tạo nghiệp cho anh em trong team khi phải review code, hoặc những hậu bối khi phải maintain code của bạn, bởi vì, họ ...

Naming rules - Các quy tắc vàng trong làng đặt tên

AnhPT

Khi nói đến **CSS Framework**, chắc ai cũng nghĩ ngay đến những framework nổi tiếng và bá đạo như Bootstrap, Materialize, hay Tailwind... Nhưng trong bài viết này, mình sẽ không nhắc đến những framework chuyên nghiệp được sử dụng cho mục đích thương mại đó, mà sẽ tổng hợp các framework mà có thể bạn ít biết tới hoặc chưa từng nghe, nhưng rất có thể sau khi biết tới, bạn sẽ cảm thấy cực kỳ thích thú vì sự "độc đáo" của chúng. Điểm độc đáo nằm ở chỗ, các CSS framework này được viết bởi đam mê, sở thích của tác giả, vì họ thích code, thích làm điều khác biệt, hoặc đơn giản họ chỉ muốn "have fun". Bản thân mình cũng thấy, ngoài lý do phải học, phải làm việc, phải kiếm tiền bằng code, thì việc tìm được một cái thú vui nào đó từ code cũng là một điều hay. Nên nếu các bạn thấy dưới đây có cái framework nào mà mình cảm thấy thích hoặc ấn tượng thì hãy cho nó 1 star, hoặc bay vào contribute cho nó luôn, vừa nghịch, vừa học được nhiều cái mới lạ 🙂

# 1. NES.css
![](https://images.viblo.asia/f2447272-9c6f-48a3-a3d4-de7bac3223d7.png)

Đứng đầu danh sách là một CSS framework dành cho các tín đồ 8-bit **NES** (Nintendo Entertainment System), hay được biết tới nhiều nhất với cái tên "máy chơi game 4 nút" lúc đương thời. Xin chúc mừng những bạn có tuổi thơ gắn liền với dòng máy này, vì đây là một framework dành cho bạn để làm sống lại ký ức tuổi thơ.

Với xì-tai ảnh pixel, NES.css hỗ trợ tương đối đầy đủ các component để bạn có thể xây dựng một website hoàn chỉnh. Các quy tắc đặt tên class cũng thân thiện, dễ sử dụng. Bộ CSS còn bonus thêm cho bạn các icon/sprite bằng pixel cực kỳ ấn tượng (code hoàn toàn từ CSS nhé, siêu chưa).

**<p align="center">(<a href="https://github.com/nostalgic-css/NES.css">Source Code</a> - <a href="https://nostalgic-css.github.io/NES.css/">Demo</a>)</p>**

# 2. Wired Elements
![](https://images.viblo.asia/bddfb270-c72f-43d4-a57d-5f98fea3d597.png)

Tưởng tượng trang web của bạn trông như một bản phác thảo, độc đáo chưa? **Wired Elements** giúp bạn thực hiện điều đó bằng các component được chia sẵn và thiết kế theo phong cách "hand-drawn", bạn chỉ việc import component mình muốn và sử dụng.

**<p align="center">(<a href="https://github.com/rough-stuff/wired-elements">Source Code</a> - <a href="https://wiredjs.com/">Demo</a>)</p>**

# 3. BOOTSTRA.386
![](https://images.viblo.asia/b51805ff-1270-4e0b-8af1-ceb6796ed7c9.png)

"Giao diện máy tính tiên tiến nhất" của hệ điều hành **DOS** những năm 1980 được làm sống lại bởi **BOOTSTRA.386**. Được phát triển là một theme của Bootstrap, các quy tắc đặt tên class, component, layout... đều được sử dụng lại. Nếu đã quen với Bootstrap thì bạn sẽ sử dụng bộ framework này dễ dàng.

**<p align="center">(<a href="https://github.com/kristopolous/BOOTSTRA.386">Source Code</a> - <a href="http://kristopolous.github.io/BOOTSTRA.386/">Demo</a>)</p>**

# 4. 98.css
![](https://images.viblo.asia/9cd42355-f68d-40df-85c3-469fe0efe72c.png)

Một trang web có giao diện như **Window 98**? Tại sao không? 98.css là một CSS framework cho phép các bạn thiết kế các component theo kiểu Windows 98, không hoàn toàn sử dụng class mà tập trung sử dụng semantic HTML và tính a11y (accessibility) cho các component. Chắc hẳn khi nhìn thấy bộ framework này, không ít người được gợi nhớ lại ký ức tuổi thơ với một hệ điều hành từng gắn bó một thời.

**<p align="center">(<a href="https://github.com/jdan/98.css">Source Code</a> - <a href="https://jdan.github.io/98.css/">Demo</a>)</p>**

# 5. PaperCSS
![](https://images.viblo.asia/c1b3c106-af34-475d-b34f-dfa3a745e586.png)

Đơn giản, thanh lịch, chính là **PaperCSS**. Như tên gọi, ý tưởng của bộ framework này là khiến giao diện của bạn trông giống như tờ giấy trắng, cùng với khá nhiều component được hỗ trợ, còn có cả các layout và utility như một framework chuyên nghiệp cho mục đích thương mại.

**<p align="center">(<a href="https://github.com/papercss/papercss">Source Code</a> - <a href="https://www.getpapercss.com/">Demo</a>)</p>**

# 6. Geo
![](https://images.viblo.asia/aa8d8b70-4eae-40a5-8b19-a92f3d6defd2.png)

**Geo** là một bộ theme nữa dành cho Bootstrap, một cỗ máy thời gian đưa bạn trở lại thời xa xưa với kiểu thiết kế giao diện đẹp... nhức nhối.

**<p align="center">(<a href="https://github.com/divshot/geo-bootstrap">Source Code</a> - <a href="http://divshot.github.com/geo-bootstrap/">Demo</a>)</p>**

# 7. XP.css
![](https://images.viblo.asia/6b3acc0d-e422-4291-8c7a-77304e24beff.png)

Kế thừa ý tưởng và bố cục của 98.css, **XP.css** được phát triển và bổ sung thêm vài component, cùng với một khung xương SCSS được tách ra để phục vụ việc phát triển và bảo trì dễ dàng hơn. Một bộ framework lý tưởng dành cho các bạn gắn bó với Windows XP một thời.

**<p align="center">(<a href="https://github.com/botoxparty/XP.css">Source Code</a> - <a href="https://botoxparty.github.io/XP.css/">Demo</a>)</p>**

# 8. Terminal.css
![](https://images.viblo.asia/dd5ec9de-0b7d-490c-9688-b362d45b45f3.png)

Các fan của giao diện **Terminal** cũng có một cái CSS framework riêng nhé. Đơn giản, tinh gọn, Terminal.css cũng hỗ trợ nhiều component và layout để các bạn có thể biến trang web của mình thành một phiên bản terminal.

**<p align="center">(<a href="https://github.com/Gioni06/terminal.css">Source Code</a> - <a href="https://terminalcss.xyz/">Demo</a>)</p>**

# 9. PSone.css
![](https://images.viblo.asia/ed235db2-d640-4d94-9b0d-03b2f0d88cbb.png)

Có một CSS framework cho NES của Nintendo rồi thì tại sao lại không có một cái cho Playstation của Sony nhỉ? **PSone.css** là chính câu trả lời. Tuy số lượng component được hỗ trợ còn khá ít, nhưng các component được thiết kế rất sát với phong cách 16-bit của PlayStation 1. Một framework để nghịch, học hỏi cũng hay chứ.

**<p align="center">(<a href="https://github.com/micah5/PSone.css">Source Code</a> - <a href="https://micah5.github.io/PSone.css/">Demo</a>)</p>**

# 10. RPGUI
![](https://images.viblo.asia/bf1ec4f5-ce42-4d87-8cf2-4dfb323995e2.png)

Một tấm vé khác đưa bạn trở về tuổi thơ, **RPGUI** là một CSS Framework dành cho những bạn từng một thời đam mê và lớn lên với dòng game RPG 8-bit. RPGUI hỗ trợ tương đối nhiều component, gồm cả scrollbar và cursor, thật ấn tượng!

**<p align="center">(<a href="https://github.com/RonenNess/RPGUI">Source Code</a> - <a href="http://ronenness.github.io/RPGUI/">Demo</a>)</p>**

# 11. 7.css
![](https://images.viblo.asia/6990197d-7d1c-49eb-bcf3-b10bba625cff.png)

Tiếp tục kế thừa ý tưởng đưa giao diện Windows lên web của 98.css và XP.css, **7.css** được phát triển dựa trên khung xương SCSS của XP.css, vẫn tập trung vào việc vận dụng semantic HTML và a11y, tiếp tục bổ sung thêm một vài component và thiết kế riêng biệt chỉ có ở Windows 7, như hiệu ứng glass, gradient...

**<p align="center">(<a href="https://github.com/khang-nd/7.css">Source Code</a> - <a href="https://khang-nd.github.io/7.css/">Demo</a>)</p>**

Vậy là mình đã giới thiệu qua những CSS framework độc lạ mà mình biết, nếu các bạn còn biết thêm những cái hay ho khác thì đừng ngại chia sẻ bằng cách bình luận bên dưới nhé. Và như đã nói ở trên, nếu có framework nào mà bạn cảm thấy thích, đừng do dự mà để lại 1 star cho repository đó, hoặc có thể fork về và contribute luôn nếu muốn phát triển hoặc học hỏi thêm. Chúc các bạn code vui!

----
@khangnd<br>[![Github](https://images.viblo.asia/20x20/81dd12f0-a8c9-403f-ae51-27b92828ca22.png)](https://github.com/khang-nd) [![Linkedin](https://images.viblo.asia/20x20/4981766e-5e57-401a-8623-d3657a3148e5.png)](https://www.linkedin.com/in/khangnd/) [![Dev.to](https://images.viblo.asia/20x20/3921db2e-e4e5-45d7-acc8-e8b92e02d47d.png)](https://dev.to/khangnd) [![Fandom](https://images.viblo.asia/20x20/fad64df3-0be8-4481-b810-8995f18f71ea.png)](https://dev.fandom.com/wiki/User:KhangND)

Khi nói đến CSS Framework, chắc ai cũng nghĩ ngay đến những framework nổi tiếng và bá đạo như Bootstrap, Materialize, hay Tailwind... Nhưng trong bài viết này, mình sẽ không nhắc đến những framework chuyên nghiệp được sử dụng cho mục đích thương mại đó, mà sẽ tổng hợp các framework mà có thể bạn ít biết tới hoặc chưa từng nghe, nhưng rất có thể sau khi biết tới, bạn sẽ cảm thấy cực kỳ thích thú...

Các CSS Framework độc đáo mà có thể bạn chưa biết

*Bài viết được dịch từ Dev.to. Truy cập bài viết gốc: **[You don't need to know everything (but you should know something well)](https://dev.to/rhymes/you-dont-need-to-know-everything-but-you-should-know-something-well-4ho3)***

Mới đi làm được cỡ một năm rưỡi nay, tuy chưa đủ thâm niên để gọi là người từng trải trên con đường công nghệ, kỹ thuật phần mềm, nhưng thật sự có những lúc mình cảm thấy đuối, mệt mỏi, bị "overwhelmed", và đôi khi muốn bỏ cuộc khi xung quanh có quá nhiều con người tài năng, thông minh mà mình thua kém, và còn quá nhiều kiến thức chưa biết hoặc không thể tiếp thu nổi trong lĩnh vực chuyên môn. Mình đã học hỏi kinh nghiệm của nhiều anh đi trước, đọc nhiều bài viết rất hay của nhiều người trong ngành, cả Việt lẫn Eng, để có nguồn động lực mà phấn đấu. Một trong số đó là bài chia sẻ dưới đây từ Dev.to, mình xin dịch lại để mọi người cùng đọc và chiêm nghiệm.

----
![](https://images.unsplash.com/photo-1497796742626-fe30f204ec54?ixid=MXwxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHw%3D&ixlib=rb-1.2.1&auto=format&fit=crop&w=750&q=80)

*Photo by [Lysander Yuen](https://unsplash.com/@lysanderyuen?utmsource=unsplash&amp;utmmedium=referral&amp;utmcontent=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/knowledge?utmsource=unsplash&amp;utmmedium=referral&amp;utmcontent=creditCopyText)*

[Dan Abramov](http://twitter.com/dan_abramov) (kỹ sư tại Facebook, core member của ReactJS, đồng sáng lập Redux và Create React App) có đăng một số bài viết khiến tôi suy ngẫm rất nhiều. Có hai bài viết mà tôi xem là món quà quý giá, để tôi cho bạn biết tại sao.

Trong bài viết đầu tiên, [Things I Don’t Know as of 2018](https://overreacted.io/things-i-dont-know-as-of-2018/) (Những thứ mà tôi chưa biết, tính đến 2018), Dan liệt kê ra một danh sách những công nghệ, kỹ thuật mà anh biết rất ít, hoặc thậm chí không biết gì. Tôi sẽ không liệt kê ra đây vì chúng ta không tập trung nói về chủ đề đó.

Nhiều developer phải vật lộn với ý nghĩ viễn vông là làm sao để trở thành một developer trên thông thiên văn, dưới tường địa lý, một người có thể am hiểu tường tận mọi công nghệ, kỹ thuật cool ngầu (từ quá khứ, hiện tại, đến tương lai). Ý nghĩ này có lẽ xuất phát từ sự kết hợp giữa các yếu tố: lòng tự tôn của bản thân, áp lực từ đồng nghiệp, đồng môn, những "siêu nhân" phần mềm, hay những kỳ vọng không tưởng, và những mô tả công việc tuyển dụng được phóng đại lên. Dẫn đến việc bạn dần bị kiệt quệ hoặc mất đi những kĩ năng xã hội cần thiết.

Do đó, để có cái nhìn thoáng hơn, tôi rất khuyên bạn nên đọc qua [bài chia sẻ](https://overreacted.io/things-i-dont-know-as-of-2018/) của Dan. Trích dẫn vài câu trong bài:

> Chúng ta có thể thừa nhận những lỗ hổng kiến thức của mình, nhưng dù thế nào thì vẫn có những kiến thức chuyên môn cực kỳ giá trị mà ta đã phải trải qua nhiều năm làm việc mới có được.

Điều này nhắc tôi nhớ đến phong thái của một số thành viên khác trên Dev.to mà tôi đang theo dõi. Họ là những người biết rất sâu, rất giỏi chuyên môn trong *một lĩnh vực* nào đó nhưng không hề e ngại thừa nhận những điều họ chưa biết và muốn trao dồi không ngừng về lĩnh vực đó. Một phẩm chất nên có, không chỉ đối với việc làm lập trình.

> Tôi biết mình còn thiếu sót nhiều kiến thức, nhưng tôi có thể bổ sung sau, lúc tôi tò mò hay cần dùng cho một dự án mới.<br>
> Điều này không làm đánh mất giá trị của tôi, về kiến thức hay kinh nghiệm. Bởi vẫn có nhiều thứ mà tôi có thể làm tốt, ví dụ như khả năng học nhanh công nghệ khi tôi cần tới.

Đây là điểm mấu chốt. Sự phát triển theo hướng tò mò (hoặc "sự phát triển khi cần thiết") là một trong những điểm chung có ở nhiều developer thành công. Học cách để học (learning how to learn) lại càng quan trọng hơn.

Trong bài viết thứ hai, [The Elements of UI Engineering](https://overreacted.io/the-elements-of-ui-engineering/) (Các yếu tố trong xây dựng UI), Dan nói về những cái mà anh biết sâu, cùng với một điều làm bài viết này trở nên quý giá.

Nếu trong bài viết đầu, anh liệt kê những công nghệ và kỹ thuật, thì ở bài viết này, a liệt kê những phương pháp, pattern, và những điều quan trọng cho việc phát triển UI. Dan nhấn mạnh một khía cạnh mà tại đây, chúng ta lại có một cái nhìn nữa:

> Đột phá lớn nhất trong sự học của tôi không phải từ một công nghệ nhất định, mà là khi tôi phải vật lộn để giải quyết một vấn đề về UI, đây mới là lúc tôi học được nhiều nhất. Đôi khi, tôi tìm ra được một thư viện hay pattern có thể giúp giải quyết vấn đề, nhưng cũng có lúc, tôi phải tự tìm ra giải pháp cho riêng mình (tốt có, xấu có).<br>
> Hiểu được vấn đề, thử nghiệm nhiều giải pháp, và áp dụng các chiến lược khác nhau, chính sự kết hợp này mới đem lại cho tôi một trải nghiệm học bổ ích nhất trong cuộc đời của mình.

Trên dev.to, cũng có rất nhiều bài viết và thảo luận nói về việc: nắm chắc những nguyên tắc cơ bản và tư duy giải quyết vấn đề có giá trị hơn nhiều so với việc sử dụng công nghệ này, công nghệ kia.

Như tiêu đề: *Không nhất thiết phải biết rộng, nhưng nên biết sâu*.

----
@khangnd<br>[![Github](https://images.viblo.asia/20x20/81dd12f0-a8c9-403f-ae51-27b92828ca22.png)](https://github.com/khang-nd) [![Linkedin](https://images.viblo.asia/20x20/4981766e-5e57-401a-8623-d3657a3148e5.png)](https://www.linkedin.com/in/khangnd/) [![Dev.to](https://images.viblo.asia/20x20/3921db2e-e4e5-45d7-acc8-e8b92e02d47d.png)](https://dev.to/khangnd) [![Fandom](https://images.viblo.asia/20x20/fad64df3-0be8-4481-b810-8995f18f71ea.png)](https://dev.fandom.com/wiki/User:KhangND)

Bài viết được dịch từ Dev.to. Truy cập bài viết gốc: *You don't need to know everything (but you should know something well)*

Mới đi làm được cỡ một năm rưỡi nay, tuy chưa đủ thâm niên để gọi là người từng trải trên con đường công nghệ, kỹ thuật phần mềm, nhưng thật sự có những lúc mình cảm thấy đuối, mệt mỏi, bị "overwhelmed", và đôi khi muốn bỏ cuộc khi xung quanh có quá nhiều con người tài ...

Không nhất thiết phải biết rộng, nhưng nên biết sâu

Hao Le

Huỳnh Minh Hưng

Thang Le Ba

![](https://docs.github.com/assets/images/help/repository/profile-with-readme.png)

Khi đã chọn nghề IT, dấn thân vào con đường dev khó có ngày yên nghỉ (ngơi), chắc các bạn đã không còn xa lạ với **Github**, nếu không muốn nói là quá quen (nếu chưa biết Github là cái gì thì bạn cần lăn lộn giang hồ nhiều nữa 😅). Với một hệ thống siêu khủng, nhiều tính năng siêu tiện ích, một đội ngũ phát triển siêu nhân thì Github đang là platform số 1 dành cho cộng đồng developer trên toàn thế giới để làm việc với source code, từ quản lý lịch sử phiên bản bằng git, peer coding, code review, open source, đến tích hợp service, actions, hosting, blah blah blah,... Ôi thôi, kể ra chưa hết mà chắc bài viết này đã "1 hour read", mà bài viết này không phải để mình giới thiệu về Github mà chia sẻ cho các bạn đã sử dụng qua Github, cách tạo một "portfolio" cá nhân bằng **Profile README**.

# TL;DR
Tóm tắt các bước tạo profile README dành cho các bạn lười đọc:
* Tạo một repository với tên trùng với username của bạn
* Chọn chế độ public
* Tick vào ô "Initialize this repository with a README"
* Sau khi tạo, nội dung trong file README sẽ xuất hiện trên trang profile của bạn

Vậy là bạn đã có một "portfolio" cá nhân nhanh chóng trên Github, nếu muốn biết thêm một số cách trình bày, cũng như làm đẹp cho portfolio này thì chịu khó...đọc tiếp.

# Các bước tạo (kèm hình)
(phần này dịch từ trang chủ [Github Docs](https://docs.github.com/en/free-pro-team@latest/github/setting-up-and-managing-your-github-profile/managing-your-profile-readme), hình ảnh cũng mượn luôn)

1. Tạo 1 repository bằng cách hay dùng: click vào dấu + góc phải trên cùng, chọn **New repository**

![](https://docs.github.com/assets/images/help/repository/repo-create.png)

2. Điền **username** của mình vào cho tên của repository. Ví dụ tên user Github của bạn là *nguyen-van-teo*, thì repository này cũng phải tên *nguyen-van-teo*.

![](https://docs.github.com/assets/images/help/repository/repo-username-match.png)

3. Nhớ chọn chế độ **public**

![](https://docs.github.com/assets/images/help/repository/create-personal-repository-visibility.png)

4. Tick ô "Initialize this repository with a README"

![](https://docs.github.com/assets/images/help/repository/initialize-with-readme.png)

5. Cuối cùng chọn **Create repository**

![](https://docs.github.com/assets/images/help/repository/create-repository-button.png)

6. Sau khi tạo, các bạn vào sửa đổi file README

![](https://docs.github.com/assets/images/help/repository/personal-repository-edit-readme.png)

Lúc này, Github tự động điền sẵn cho bạn một template để bạn lấy ý tưởng.

![](https://docs.github.com/assets/images/help/repository/personal-repository-readme-template.png)

Vậy là xong, bạn có thể sửa đổi file README này theo phong cách của mình.

# Một số ý tưởng trình bày
Về bản chất thì vẫn chỉ là một file README nên "portfolio" này cũng không có nhiều cách để bạn có thể thiết kế, làm đẹp, ngoài việc vận dụng toàn bộ hiểu biết về [Markdown](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet) và hình ảnh để tạo nên sự khác biệt. Dưới đây là vài porfolio hay và đẹp mà mình lụm lặt được, nếu bạn cũng nghĩ portfolio của mình đẹp thì đừng ngại chia sẻ.

* Dùng ảnh banner nổi bật: anh [Hậu Nguyễn](https://github.com/paulnguyen-mn/paulnguyen-mn) và [M0nica](https://github.com/M0nica/M0nica)
* Dùng code để giới thiệu bản thân: [Thaiane](https://github.com/Thaiane/Thaiane) và [AnhellO](https://github.com/AnhellO/AnhellO)
* Dùng badge để biểu diễn các môn võ mình biết: [Gaboso](https://github.com/kautukkundan/Awesome-Profile-README-templates/blob/master/multimedia/Gaboso.md)

Các bạn có thể tham khảo thêm nhiều mẫu portfolio tại trang tổng hợp này: https://awesomegithubprofile.tech

# Một số công cụ hỗ trợ
* Auto tạo profile README cho bạn: https://github.com/rahuldkjain/github-profile-readme-generator
* Hiển thị các số liệu của bạn trên Github: https://github.com/anuraghazra/github-readme-stats
* Hiển thị các số liệu của bạn theo biểu đồ: https://github.com/vn7n24fzkq/github-profile-summary-cards
* Hiển thị số lượt truy cập profile của bạn: https://github.com/antonkomarev/github-profile-views-counter
* Hiển thị các bài blog mới của bạn từ mọi nguồn: https://github.com/gautamkrishnar/blog-post-workflow
* Tạo và hiển thị badge cho file README: https://github.com/badges/shields

# Kết
Đối với những bạn hay làm open source trên Github, những bạn chuyên làm backend và ít quan tâm tới frontend hay UI/UX, hay những bạn không có thời gian, không quỡn làm một cái portfolio từ đầu tới đuôi thì **Profile README** có lẽ là một "portfolio" thay thế cực kỳ tiện lợi để show-off những kỹ năng, những tech stack mà bạn biết, cũng như giới thiệu đôi lời về bản thân. Hi vọng sau bài chia sẻ, nhiều bạn sẽ có một portfolio ấn tượng trên Github, nhưng cũng đừng mất quá nhiều thời gian để nghĩ cách làm sao cho nó "phá cách, sáng tạo", các bạn còn cái CV mà, và còn nhiều thứ để học, nhiều việc để làm lắm 😉

----
@khangnd<br>[![Github](https://images.viblo.asia/20x20/81dd12f0-a8c9-403f-ae51-27b92828ca22.png)](https://github.com/khang-nd) [![Linkedin](https://images.viblo.asia/20x20/4981766e-5e57-401a-8623-d3657a3148e5.png)](https://www.linkedin.com/in/khangnd/) [![Dev.to](https://images.viblo.asia/20x20/3921db2e-e4e5-45d7-acc8-e8b92e02d47d.png)](https://dev.to/khangnd) [![Fandom](https://images.viblo.asia/20x20/fad64df3-0be8-4481-b810-8995f18f71ea.png)](https://dev.fandom.com/wiki/User:KhangND)

![](https://docs.github.com/assets/images/help/repository/profile-with-readme.png)



Khi đã chọn nghề IT, dấn thân vào con đường dev khó có ngày yên nghỉ (ngơi), chắc các bạn đã không còn xa lạ với Github, nếu không muốn nói là quá quen (nếu chưa biết Github là cái gì thì bạn cần lăn lộn giang hồ nhiều nữa 😅). Với một hệ thống siêu khủng, nhiều tính năng siêu tiện ích, một đội ngũ phát triển siêu nhân thì Github đang là platform số 1 dành cho cộng đồng developer trên toàn thế...

Profile README - Portfolio cá nhân nhanh, bổ, rẻ ngay trên Github

[![UI Components](https://cdn.dribbble.com/users/427857/screenshots/14376977/media/c35b2be4b09afcc1d0fadf8ccf783cb4.png)](https://dribbble.com/shots/14376977-UI-Components-for-Unity-Gaming)
*UI components by [Tran Mau Tri Tam](https://dribbble.com/tranmautritam)*

Nếu là một front-end developer, chắc hẳn bản thân bạn cũng sẽ ít nhiều hiểu được tầm quan trọng của UI đối với người dùng, cũng như việc một ứng dụng có giao diện đẹp, ưa nhìn sẽ giúp người dùng có cái nhìn tốt hơn và sẽ lựa chọn việc sử dụng ứng dụng của bạn nhiều hơn. Là developer, thường chúng ta sẽ không nhúng quá sâu vào công việc thiết kế UI, mà phần lớn thời gian sẽ dùng để code ra giao diện dựa trên những mẫu thiết kế có sẵn, hay sử dụng các UI framework như Bootstrap, Material UI, Ant Design... để xây dựng front-end. Tuy nhiên, giả sử bạn rơi vào một trong những trường hợp sau:
* Có một số thứ mà UI framework bạn đang sử dụng không hỗ trợ
* Quy mô ứng dụng không lớn (ví dụ như extension, plugin, tool), việc dùng framework khiến bạn cảm thấy thừa thãi
* Hay đơn giản là bạn phải bố trí các element của UI framework sao cho phù hợp với bố cục
* Hoặc thậm chí, bạn là người thực hiện việc phát triển một sản phẩm từ A - Z (Developer kiêm Designer kiêm luôn Tester 😎)

Đây chính là lúc việc nắm rõ **các yếu tố cơ bản trong thiết kế UI** sẽ rất có ích cho bạn, giúp bạn có những cảm nhận tốt hơn về tính thẫm mĩ, và xây dựng các thành phần UI nhanh và đẹp. Vậy ta cùng xem các yếu tố cơ bản nào trong thiết kế UI mà ta cần biết.

*Bài viết dựa trên khóa học "[Learn UI Design Fundamentals](https://scrimba.com/learn/design)" của tác giả Gary Simon.*

# Các yếu tố cơ bản
## 1. White space (khoảng trắng)
> Giữa các phần tử trên giao diện cần được cách nhau bởi các khoảng trắng thích hợp.

Cùng xem 2 hình ảnh của cùng một `card` bên dưới:

![whitespace](https://images.viblo.asia/845437b9-f18d-4d8c-a086-5caea553c6ea.png)

Các bạn có thể thấy hình bên phải nhìn được hơn hẳn đúng không? Các phần tử sau khi được chia khoảng trắng hợp lý bằng các thuộc tính như `padding`, `margin`, thì bạn có thể thấy sự khác biệt rõ rệt.
 
## 2. Alignment (căn chỉnh)
> Đảm bảo các phần tử được đặt đúng vị trí sao cho tương thích với nhau.

Cùng xem 2 hình sau:
![alignment](https://images.viblo.asia/b6cd7835-3416-4b10-8bca-bf94d3af1642.png)

Ở 2 hình này, bạn có thể thấy các phần tử đã được cách nhau bởi những khoảng trắng, nhìn cũng ok. Nhưng ở hình bên trái, các phần tử thụt ra thụt vào không đều so với lề bên trái của khung, điều nay khiến bạn cảm thấy hơi khó chịu khi nhìn. Ở hình bên phải, các phần tử được căn đều so với lề bên trái, trông được hơn chứ nhỉ?

## 3. Contrast (độ tương phản)
> Đảm bảo các phần tử có độ tương phản nhất định, giúp người dùng dễ nhìn.

Độ tương phản là sự khác biệt về màu sắc giữa phần tử này với phần tử kia trên giao diện. Ví dụ như độ tương phản giữa:
* Text trên một button và nền của button đó
* Button và div chứa nó
* Hay div đó và nền của cả trang web.

![](https://images.viblo.asia/95d2f6cf-d96e-4439-b525-451a151491e2.png)

[WCAG](https://www.w3.org/WAI/standards-guidelines/wcag/) (một chuẩn dành cho phát triển web) quy định tỷ lệ tương phản tối thiểu nên có giữa 2 phần tử là **4.5:1**, hoặc đối với các phần tử cỡ lớn thì nên là **3:1**. Tỷ lệ này càng lớn, các phần tử càng dễ phân biệt, người dùng càng dễ nhìn, nhất là đối với người dùng có các tật về mắt.

Để hiểu rõ hơn về độ tương phản, cùng xem 2 hình sau:

![contrast](https://images.viblo.asia/45ae3836-9a9f-42fa-9078-d932f273a9d3.png)

Chỉ cần ngó sơ qua là bạn có thể thấy ngay là hình nào dễ nhìn hơn đúng không? Hình bên trái là ví dụ của một thiết kế có độ tương phản kém, trong khi ở hình bên phải, các phần tử được phối màu với độ tương phản tốt nên từng phần tử hiện lên rõ ràng.

## 4. Scale (kích cỡ)
> Cân nhắc sử dụng kích cỡ phù hợp với phần tử cũng như mục đích sử dụng của phần tử.

Một ví dụ đơn giản là, khi bạn thấy một bài viết, cái đầu tiên bạn quan tâm chắc hẳn là **tiêu đề** vì nó khái quát được **nội dung** bài viết nói gì. Nếu tiêu đề không hứng thú, bạn liền next, tiết kiệm khối thời gian. Do vậy **tiêu đề** cần có kích cỡ to hơn, nổi bật hơn phần chữ trong **nội dung**.

Cùng xem 2 hình sau:

![scale](https://images.viblo.asia/28eba25e-e90a-4e8a-bd83-f0246d6a44e0.png)

Quá rõ ràng bên nào nhìn thích hơn đúng không? Ở hình bên trái, các phần tử hầu như đều cùng cỡ chữ, chúng ta không biết mình cần chọn lọc những thông tin gì để lưu vào đầu, ngoài ra các khung màu cũng không trải hết độ rộng trang, nhìn không đều. Ở hình bên phải, chúng ta phân biệt được trang này có tiêu đề là gì, từng màu sắc có mã màu hiện rõ lên giúp ta dễ dàng ghi nhớ và các khung màu trông cũng ok hẳn.

## 5. Typography (kiểu chữ)
> Sử dụng kiểu chữ nhất quán, phù hợp mục đích sử dụng, và tương thích với các yếu tố khác.

Thường trên cùng một giao diện chỉ nên sử dụng 1 hoặc 2 font chữ để đảm bảo tính nhất quán, người dùng nhìn dễ quen mắt hơn. Và tùy vào mục đích sử dụng, nên chọn font và kiểu chữ sao cho phù hợp, ví dụ như bạn đang làm một giao diện trang bán đồ nội thất, bạn lại sử dụng một font chữ phong cách đường phố như graffiti, như vậy không phải là sáng tạo đâu nhé 😅

Cùng xem tiếp 2 hình sau:

![typography](https://images.viblo.asia/7911a590-e5d0-464f-a982-14c4f60ed5b0.png)

Vấn đề của hình bên trái đó là sử dụng quá nhiều kiểu chữ (tiêu đề 1 kiểu, nội dung 1 kiểu, footer 1 kiểu) và kích cỡ cũng không ổn, hoặc là do kiểu chữ, hoặc do lỗi của người thiết kế. Sau khi chuyển về cùng 1 kiểu chữ và tinh chỉnh một số thứ như trong hình bên phải, có phải nhìn ổn hơn một tí?

## 6. Color (màu sắc)
> Lựa chọn màu sắc một cách khoa học, hài hòa và phù hợp với chủ đề đang hướng tới.

Một trong những yếu tố cơ bản và cực kỳ quan trọng mà không thể không nói tới, đó chính là màu sắc. Lấy ví dụ như khi bạn truy cập một trang web, điều đầu tiên đập vào mắt của bạn không phải là bố cục, không phải là nội dung, mà chính là màu sắc của trang đó. Do đó, việc lựa chọn màu sắc là một công việc khá quan trọng và đòi hỏi tính thẫm mỹ cao ở người thiết kế. Chúng ta sẽ không đi quá sâu, mà cùng điểm qua một số lưu ý sau:
* **Cần lựa chọn màu sắc phù hợp với chủ đề đang hướng tới**: mỗi màu sắc có thể mang một ý nghĩa tượng trưng, ví dụ như màu xanh lục thường đại diện cho thiên nhiên, sự sung túc... hoặc màu đen, đại diện cho sự trang trọng, quý phái... Do đó, nên cân nhắc lựa chọn màu sắc tùy vào đối tượng sử dụng, sản phẩm, hay loại hình kinh doanh của công ty.
* **Không nên sử dụng quá nhiều màu sắc trên cùng một giao diện**: quá nhiều màu sắc có thể làm người dùng bị rối mắt, mất đi mục đích biểu đạt của phần tử giao diện. Thường để dễ dàng và an toàn hơn, ta chỉ nên chọn 1 hoặc 2 màu chủ đạo, rồi phối với các shade (độ đậm nhạt) khác nhau để tạo sự hài hòa.
* **Chú ý kết hợp với độ tương phản một cách hợp lý**: như đã đề cập ở trên, độ tương phản tốt giúp người dùng dễ nhìn hơn, và màu sắc đóng một vai trò quan trọng trong việc điều phối độ tương phản.

Cùng xem 2 hình sau:

![color](https://images.viblo.asia/e8d57da4-dec5-4496-b8b4-bb5eac96ef53.png)

Ta cùng đếm xem có bao nhiêu màu ở hình bên trái, chắc có bạn đếm được 4, có bạn 5, hoặc rộng rãi hơn thì cứ cho 6. Từ đây, các bạn có thể thấy các phần tử quan trọng không được nổi bật, nếu không muốn nói là khó nhìn, vì sử dụng quá nhiều màu sắc và một phần do độ tương phản giữa các màu này đem lại không được tốt. Sang hình bên phải, ở đây mình thấy có 3 màu, màu nền mình tính hoàn toàn là 1 màu, chỉ là các shade khác nhau, màu thứ 2 là màu chữ, màu thứ 3 là button. Các bạn có thể dễ dàng nhìn ra đâu là cái button mình có thể bấm, đâu là phần chữ mình có thể đọc.

## 7. Visual Hierarchy (mối liên hệ trực quan)
> Làm nổi bật chức năng, mục đích của các phần tử trên giao diện

Một ví dụ dễ thấy nhất là cái slider, có phải khi cuộn cái slider, tấm hình ở giữa sẽ to hơn những tấm hình ở 2 bên, điều này giúp bạn tập trung nhiều hơn vào tấm hình đó. Đó là một cách làm nổi bật phần tử vận dụng yếu tố **visual hierarchy**. Visual hierarchy được vận dụng làm nổi bật phần tử thông qua các yếu tố cơ bản đã kể trên. Chúng ta cùng xem những cách thực hiện điều đó bằng 5 cái hộp:

5 cái hộp | Sử dụng `white space` & `alignment` | Sử dụng `contrast`
-------- | -------- | --------
![](https://images.viblo.asia/931b75dc-48e8-48f6-bcd4-09ccea6f0a5c.png) | ![](https://images.viblo.asia/753de628-c72f-450d-b948-28a66d31ff35.png) | ![](https://images.viblo.asia/97a20ba6-f9ab-4010-a18f-3af0f6e5fb76.png)

Sử dụng `scale` | Sử dụng `color` | Hỗn hợp nhiều cách
-------- | -------- | --------
![](https://images.viblo.asia/ca4776d1-238e-4e8e-b733-f5fc130ffa9e.png) | ![](https://images.viblo.asia/c4b226dc-ceb2-43c9-b936-b605cf724d76.png) | ![](https://images.viblo.asia/d2b73c76-b745-443a-98f6-84b6433e8982.png)

Ta lại xem tiếp 2 hình sau của cùng một form:

![](https://images.viblo.asia/a2bfe145-3702-41e5-b366-20f510f62fce.png)

Hình bên trái là một ví dụ khi không vận dụng yếu tố visual hierarchy, các phần tử trông đều như nhau, không có điểm nhấn. Ở hình bên phải, các phần tử được làm nổi bật, thể hiện rõ chức năng và mục đích của mình nhờ vận dụng yếu tố visual hierarchy. Các bạn có thể kể tên được bao nhiêu yếu tố cơ bản đã được áp dụng trong hình bên phải không? Bình luận bên dưới nhé.

# Kết
Vậy là mình đã chia sẻ qua các yếu tố cơ bản trong UI design, hi vọng bài viết giúp bạn phần nào hiểu hơn về UI cũng như có cái nhìn tốt hơn và thẫm mỹ hơn khi làm việc với UI. Xin kết thúc bài viết bằng một bài tập nho nhỏ để áp dụng các yếu tố kể trên, các bạn thiết kế giao diện cho khung xương HTML trong codepen sau, sau khi hoàn tất có thể đối chiếu với thiết kế mẫu mình đặt bên JS. Share kết quả bên dưới nhé. Have fun!
{@codepen: https://codepen.io/khangnd/pen/JjRbdvZ}

----
@khangnd<br>[![Github](https://images.viblo.asia/20x20/81dd12f0-a8c9-403f-ae51-27b92828ca22.png)](https://github.com/khang-nd) [![Linkedin](https://images.viblo.asia/20x20/4981766e-5e57-401a-8623-d3657a3148e5.png)](https://www.linkedin.com/in/khangnd/) [![Dev.to](https://images.viblo.asia/20x20/3921db2e-e4e5-45d7-acc8-e8b92e02d47d.png)](https://dev.to/khangnd) [![Fandom](https://images.viblo.asia/20x20/fad64df3-0be8-4481-b810-8995f18f71ea.png)](https://dev.fandom.com/wiki/User:KhangND)


UI components by Tran Mau Tri Tam

Nếu là một front-end developer, chắc hẳn bản thân bạn cũng sẽ ít nhiều hiểu được tầm quan trọng của UI đối với người dùng, cũng như việc một ứng dụng có giao diện đẹp, ưa nhìn sẽ giúp người dùng có cái nhìn tốt hơn và sẽ lựa chọn việc sử dụng ứng dụng của bạn nhiều hơn. Là developer, thường chúng ta sẽ không nhúng quá sâu vào công việc thiết kế UI, mà phần lớ...

UI Design - Các yếu tố cơ bản trong thiết kế giao diện

Alexander Huỳnh

Nguyễn Trần Minh Pháp

![Svelt](https://subscribe.packtpub.com/wp-content/uploads/2020/10/svelte_js.png)

Hello mọi người, trong bài viết này, mình xin khái quát một số kiến thức về **Svelte** cũng như cách để xây dựng một web app bằng Svelte.
# TL;DR
Dành cho những bạn lười đọc, vốn tiếng Anh kha khá và thích "learn by doing":
* Mọi thông tin, tài liệu của Svelte, từ cơ bản đến nâng cao đều được hướng dẫn chi tiết trên trang chủ: https://svelte.dev
* Vừa học, vừa thực hành: https://svelte.dev/tutorial
* Github repo: https://github.com/sveltejs/svelte
* Tổng hợp các tài liệu liên quan: https://svelte-community.netlify.app/resources
* Tổng hợp các plugins hay đi kèm: https://github.com/rollup/plugins

# 1. Tổng quan
**Svelte** hay còn được gọi là SvelteJS, là một front-end JavaScript framework được phát triển bởi [Rich Harris](https://twitter.com/Rich_Harris) nhằm xây dựng giao diện người dùng một cách nhanh chóng và dễ dàng. Về bản chất, Svelte là một **compiler**, giúp biên dịch các cú pháp đặc thù mà bạn viết từ Svelte sang HTML, JS, CSS thuần tại thời điểm build, giúp tăng hiệu suất nhờ giảm các bước xử lý từ phía client.

## 1.1. Các ưu điểm
### Code ít hơn
Việc làm phần mềm nói chung, và viết code nói riêng đều có rủi ro ít nhiều về lỗi, bug. Việc phải viết nhiều code, bạn phải mất nhiều thời gian > codebase của bạn trở nên to, việc maintain, xử lý lỗi tốn nhiều thời gian > bạn muốn phát triển thêm tính năng hay ho, tối ưu hiệu suất, học thêm các kiến thức khác hoặc bạn muốn dành thời gian cho bạn bè, gia đình, vui chơi giải trí... bạn không còn thời gian. Do vậy, việc code ít, đồng nghĩa với việc sản phẩm của bạn sẽ ít lỗi, hoặc ít nhất bạn dễ tìm ra lỗi để xử lý, bạn sẽ có thêm thời gian cho các hoạt động khác ngoài chỉ biết "fix bug". Bạn hạnh phúc với cuộc đời dev 😀.

### Không dùng Virtual DOM
Nếu bạn đã và đang sử dụng các thư viện/framework phổ biến hiện nay như React hay Vue, chắc hẳn bạn sẽ nghe quen quen khái niệm "Virtual DOM" (DOM ảo) cũng như hay nghe nói "Virtual DOM nhanh vô đối". Dưới góc nhìn của Rich Harris, người sáng tạo ra Svelte, cho rằng việc sử dụng Virtual DOM để xử lý giao diện người dùng không hoàn toàn nhanh như những gì chúng ta đang lầm tưởng. Do đó, Svelte không sử dụng Virtual DOM mà hoàn toàn là một compiler biên dịch code của bạn sang ngôn ngữ JS thuần, zero dependency. App của bạn sẽ chỉ nhanh và nhanh ⚡.

### Reactive thực thụ
Bạn ngán ngẫm, không thể hiểu nổi các cơ chế quản lý state phức tạp trong các thư viện/framework JavaScript? Svelte là lựa chọn dành cho bạn, Svelte đưa cơ chế "reactivity" trong JavaScript lên một cấp độ mới, cực kỳ đơn giản và dễ áp dụng. Bạn sẽ càng đam mê với code 💻.

## 1.2. Làm quen
Các cú pháp của Svelte được nhận diện trong các component, có phần đuôi mở rộng là `.svelte`. Mỗi component sẽ gồm có 3 phần rõ ràng:
```html
<script>
    // JS code
</script>

<style>
    /* CSS code */
</style>


```
* `<script>` chứa code JS mà bạn muốn xử lý trong component.
* `<style>` chứa code CSS để trang điểm cho component (code CSS này sẽ chỉ thuộc phạm vi component này thôi).
* Phần cuối cùng sẽ được Svelte compiler tự động nhận diện là các thẻ HTML.

Nhìn quá quen thuộc như lúc bạn mới nhập môn lập trình web đúng không? Phần thú vị còn ở phía sau 😁.

## 1.3. Các cú pháp cơ bản
Mình lướt qua một số cú pháp cơ bản của Svelte. Nhìn chung các cú pháp của Svelte không quá phức tạp, nếu không muốn nói là đơn giản. Nếu bạn đã quen thuộc với HTML, CSS, JavaScript, và một số cú pháp của ES6 thì bạn sẽ nhanh chóng thích nghi ngay.

### Truy xuất biến
```html
<script>
	let name = "world";
</script>

<h1>Hello {name}!</h1>
```

Khai báo biến trong thẻ `<script>`, trong HTML template, muốn truy xuất, bạn chỉ cần nhập tên biến trong cặp dấu ngoặc nhọn.

### Truy xuất biến trong thuộc tính thẻ
```html
<script>
	let src = "image.gif";
</script>

<img src={src} alt="Tên ảnh">
```

Tương tự, cú pháp để truy xuất biến trong thuộc tính thẻ được sử dụng như trên. Trường hợp biến của bạn cùng tên với thuộc tính, có thể viết gọn lại như sau:
```html
<img {src} alt="Tên ảnh">
```

### Import một component khác
```html
<script>
    import Button from "./Button.svelte";
</script>

<h1>Ví dụ import</h1>
<Button />
```

### Reactivity - cơ chế phản ứng với thay đổi
```html
<script>
    let count = 0;
    function increase() {
        count += 1;
    }
    setInterval(increase, 1000);
</script>

<p>Giá trị của count là: {count}</p>
```

Với ví dụ trên, cứ mỗi 1 giây thì biến `count` sẽ tăng lên 1. Như các bạn thấy, chỉ với cú pháp khai báo và gán giá trị biến thông thường, Svelte khiến cơ chế "reactivity" trở nên vô cùng đơn giản.

### Tạo props (thuộc tính) cho component
```html
// Button.svelte
<script>
    export let text = "Gửi";
</script>

<button>{text}</button>

// App.svelte
<script>
    import Button from "./Button.svelte";
</script>

<Button text="Hủy" />
```

Bằng từ khóa `export`, các component khác có thể thay đổi thuộc tính `text` của component Button.

### Sự kiện DOM
```html
<script>
    let count = 0;
    
    function handleClick() {
        count += 1;
    }
</script>

<button on:click={handleClick}>Đã nhấn {count} lần</button>
```

Nếu JS thuần bạn dùng `onclick` để gắn sự kiện, thì Svelte chỉ hơi khác một chút là `on:click`.

### Conditional rendering (render theo điều kiện)
```html
<script>
	let user = { loggedIn: false };

	function toggle() {
		user.loggedIn = !user.loggedIn;
	}
</script>

{#if user.loggedIn}
	<button on:click={toggle}>
		Log out
	</button>
{:else}
	<button on:click={toggle}>
		Log in
	</button>
{/if}
```

Với HTML thuần, bạn không thể thực hiện conditional rendering, nhưng với Svelte thì có. Cú pháp có vẻ hơi lạ, nhưng cần phải nhớ.

### Render dữ liệu từ mảng/danh sách
```html
<script>
    let tasks = [
        "Dọn dẹp nhà cửa",
        "Cho gà ăn",
        "Tắm cho heo",
        "Code"
    ];
</script>

<h1>Nhiệm vụ</h1>
<ul>
    {#each tasks as task, index}
        <li>Nhiệm vụ số {index + 1}: {task}</li>
    {/each}
</ul>
```

Svelte cũng hỗ trợ render từng phần tử trong một mảng/danh sách.

### Two-way binding (ràng buộc song phương)
```html
<script>
	let name = "world";
</script>

<input bind:value={name}>

<h1>Hello {name}!</h1>
```

Two-way binding cũng cực kỳ đơn giản với Svelte.

### Lifecycle (chu kỳ hoạt động)
```html
<script>
	import { onMount } from 'svelte';
    
    let data;
    
    onMount(() =>  {
        fetch("https://someapi.com")
            .then(res => res.json())
            .then(res => {
                data = res;
            });
    });
</script>

{#if data}
    <p>Dữ liệu đã fetch được: {data}</p>
{:else}
    <p>Đang tải...</p>
{/if}
```

Lifecycle của một component tương tự như React hay Vue cũng được Svelte hỗ trợ. Ngoài `onMount`, còn có `onDestroy`, `beforeUpdate` hay `afterUpdate`... Tùy trường hợp mà bạn có thể tìm hiểu thêm để sử dụng.
# 2. Các bước xây dựng một web app
## 2.1. Chuẩn bị
* Máy tính, chuột, bàn phím...
* Code Editor mà bạn yêu thích (như Atom, VS Code, Sublime, Vim, ...)
* CLI (như CMD hoặc một terminal tích hợp sẵn nếu code editor của bạn có hỗ trợ)
* [NodeJS](https://nodejs.org/en/) (cần thiết để sử dụng npm)

## 2.2. Setup môi trường
Sau khi đã chuẩn bị đầy đủ, nhập vào CLI các câu lệnh sau:
```
npx degit sveltejs/template MY-SVELTE-PROJECT
cd MY-SVELTE-PROJECT

npm install
npm run dev
```

Mở trình duyệt, truy cập `http://localhost:5000`, bạn thấy màn hình sau:
![](https://media.prod.mdn.mozit.cloud/attachments/2020/07/22/17338/24c9401b457b27a1f27d60e944b77e5f/01-svelte-starter-app.png)

Vậy là bạn đã setup xong và có thể bắt đầu xây dựng web app bằng Svelte 👍

**Giải thích tí về các câu lệnh trên**

[`degit`](https://github.com/Rich-Harris/degit) là một công cụ khác do Rich Harris phát triển, cho phép bạn copy toàn bộ source code từ một repository trên Github xuống thư mục của mình. Cụ thể ở đây chúng ta đang copy source code của một template Svelte có sẵn xuống thư mục của mình với tên `MY-SVELTE-PROJECT`.

Sau khi copy xong ta chuyển đường dẫn tới thư mục vừa tạo, cài các dependency bằng `npm install` và cuối cùng chạy môi trường development bằng `npm run dev`.

### Cấu trúc thư mục
Một template Svelte sẽ có cách tổ chức thư mục cơ bản như sau, tùy theo từng dự án mà bạn có thể tổ chức thư mục theo cách của mình sao cho phù hợp nhất.
![](https://images.viblo.asia/8f7fc56b-91b7-4654-bd27-7405d8f64b6b.png)

Từ dưới lên:
* **`rollup.config.js`**: Svelte sử dụng công cụ bundle gọi là Rollup, và đây là file bạn có thể tùy chỉnh cài đặt để bundle source code của mình.
* **`README.md`**: File thông tin project của bạn (dành cho user đọc) nếu bạn publish lên GitHub
* **`package.json`**: File thông tin project của bạn (dành cho dev đọc), cũng chứa các dependency để phát triển, deploy project của bạn.
* **`.gitignore`**: Như tên gọi, file này để bỏ qua các file/folder mà bạn không muốn commit lên git.
* **`src`**: Thư mục chứa source code
    * **`main.js`**: File đầu vào của cả cái web app. Lưu ý là nếu thay đổi tên file, bạn cần cài đặt lại tương ứng trong `rollup.config.js`.
    * **`App.svelte`**: Component viết bằng cú pháp của Svelte.
* **`scripts/setupTypeScript.js`**: File để cài đặt TypeScript thay cho JavaScript, chạy câu lệnh `node scripts/setupTypeScript.js` để cài đặt.
* **`public`**: Thư mục để deploy.

## 2.3. Xây dựng một web app máy tính đơn giản
Sau khi đã hoàn tất khâu chuẩn bị và cài đặt môi trường dev, ta tiến hành xây dựng một web app, đề tài đơn giản mình chọn là một web app **máy tính** để áp dụng một số cú pháp cơ bản của Svelte. Ok, bắt đầu thôi!

### Bố cục, chức năng
Cấu trúc vẫn như trên, mình sẽ chỉ thêm 2 component mới là **`Button.svelte`** và **`Screen.svelte`**.

**`Button.svelte`** là từng phím bấm để xử lý các thao tác tính toán.
```html
<script>
  export let key;
  export let result;
  const error = "Invalid input!";

  function replace(value) {
    return value.replace("x", "*").replace("÷", "/");
  }

  function handleClick() {
    switch (key) {
      case "=":
        try {
          result = eval(replace(result));
        } catch (e) {
          result = error;
        }
        break;
      case "C":
        result = "0";
        break;
      default:
        result = result === error || result === "0" ? key : result + key;
    }
  }
</script>

<button on:click={handleClick}>{key}</button>
```

**`Screen.svelte`** là màn hình hiển thị kết quả tính toán.
```html
<script>
  export let result;
</script>

<div class="screen">{result}</div>
```

Cuối cùng trong **`App.svelte`**, mình import 2 component trên vào và hiển thị thành một máy tính hoàn chỉnh
```html
<script>
  import Screen from "./Screen.svelte";
  import Button from "./Button.svelte";

  const rows = [
    ["7", "8", "9", "÷"],
    ["4", "5", "6", "x"],
    ["1", "2", "3", "-"],
    ["0", "C", "=", "+"],
  ];

  let result = "";
</script>

<main>
  <Screen {result} />
  <div class="keys">
    {#each rows as row}
      <div class="row">
        {#each row as key}
          <Button {key} bind:result />
        {/each}
      </div>
    {/each}
  </div>
</main>
```

Kết quả bạn sẽ có một máy tính với hình dáng sơ khai như hình:
![](https://images.viblo.asia/94fd08ba-7f7a-4558-b4e3-3bf83a1a3f58.png)

### Làm đẹp
Bước tiếp theo là trang điểm, làm đẹp các kiểu cho cái máy tính. Ở đây mình chọn kiểu **neumorphism** và style theo từng component. Kết quả cuối cùng cái máy tính sẽ có mặt mũi như hình:

![](https://images.viblo.asia/1918a28c-7328-4780-b527-62fc6284f07b.png)


## 2.4. Build và deploy
Sau khi đã hài lòng với cái máy tính, các bạn build source code bằng câu lệnh `npm run build`. Toàn bộ source code sau đó sẽ được minify lại, giúp giảm kích cỡ, đồng thời cơ chế **livereload** cũng sẽ được tắt đi. Để deploy, chỉ cần quăng toàn bộ thư mục `public` lên host là hoàn tất.

> **Lưu ý**: khi deploy lên host, bạn cần kiểm tra lại các đường dẫn tương đối trong [`index.html`](https://github.com/khang-nd/calculator-svelte/blob/master/public/index.html). Vd khi mình deploy lên Github Pages, mình phải đặt thẻ `<base href>` lên đầu, và bỏ tất cả dấu `/` ở đầu các đường dẫn đến file JS, CSS.

* Repository đầy đủ cho bạn tham khảo: https://github.com/khang-nd/calculator-svelte.
* Trang thành quả: https://khang-nd.github.io/calculator-svelte

# 3. Kết
Svelte vẫn còn là một framework mới mẻ, job offer cũng chưa có nhiều và cộng đồng sử dụng cũng chưa lớn, nhưng Svelte là một tân binh tiềm năng, có thể phát triển mạnh và được sử dụng rộng rãi trong tương lai. Hiện tại mình chỉ nên vọc và làm vài cái pet project hoặc project cá nhân để học và thỏa đam mê với code 😎 Nếu bạn có ý định sử dụng cho project bự thì nên cân nhắc.

Vậy là mình đã khái quát một số kiến thức cơ bản về Svelte mà mình biết, mong là bài viết giúp ích cho mọi người.

----
@khangnd<br>[![Github](https://images.viblo.asia/20x20/81dd12f0-a8c9-403f-ae51-27b92828ca22.png)](https://github.com/khang-nd) [![Linkedin](https://images.viblo.asia/20x20/4981766e-5e57-401a-8623-d3657a3148e5.png)](https://www.linkedin.com/in/khangnd/) [![Dev.to](https://images.viblo.asia/20x20/3921db2e-e4e5-45d7-acc8-e8b92e02d47d.png)](https://dev.to/khangnd) [![Fandom](https://images.viblo.asia/20x20/fad64df3-0be8-4481-b810-8995f18f71ea.png)](https://dev.fandom.com/wiki/User:KhangND)



Hello mọi người, trong bài viết này, mình xin khái quát một số kiến thức về Svelte cũng như cách để xây dựng một web app bằng Svelte.
TL;DR
Dành cho những bạn lười đọc, vốn tiếng Anh kha khá và thích "learn by doing":
* Mọi thông tin, tài liệu của Svelte, từ cơ bản đến nâng cao đều được hướng dẫn chi tiết trên trang chủ: https://svelte.dev
* Vừa học, vừa thực hành: https://svelte.dev/tutorial...

Svelte - Tổng quan và cách xây dựng một web app bằng Svelte

Hunter Production (thosanmaytinh)

Nguyễn Hữu Kim

Truong Dang

*Bài viết được dịch từ DEV.to. Truy cập bài viết gốc: **[Grow up](https://dev.to/macsikora/grow-up-20c5)**.*

Vừa qua mình có đọc được một bài viết chia sẻ kinh nghiệm của một dev trên trang DEV.to rất hay và đâu đó thấy hình ảnh của bản thân phảng phất trong những khuyết điểm được đề cập. Mình xin dịch lại bài viết để cùng chia sẻ và nghiền ngẫm những ý hay trong bài.

----
![](https://res.cloudinary.com/practicaldev/image/fetch/s--zsEfoLTz--/c_imagga_scale,f_auto,fl_progressive,h_420,q_auto,w_1000/https://dev-to-uploads.s3.amazonaws.com/i/lfvlu9hib7j4x2ucjw1u.jpg)
Những quan điểm cứng nhắc về những thứ không đáng, đây là điều đang diễn ra trong cộng đồng developer. Tab vs space, React vs Angular, JS vs TS, Python vs PHP, OOP vs FP. Đó là một vài ví dụ, chúng ta hay nói công nghệ mà mình chọn là tốt hơn, giải pháp mà mình đưa ra là đỉnh nhất, phải... nhưng không hẳn là đúng.

## Code của tui tốt hơn
Code của tui tốt hơn bạn, nhưng tốt hơn nghĩa là gì? Chẳng phải đó chỉ là lời tuyên bố chủ quan? Nếu bạn viết 'vòng for' lại thành 'reduce' chỉ vì bạn không thích nhìn thấy nhiều vòng lặp, thì việc đó cũng chả liên quan gì đến mục tiêu của dự án. Tất cả những bài viết có tiêu đề dạng như - "Đừng bao giờ dùng x" hay "Ngưng sử dụng y". Để làm gì? Để cho mọi người thấy quan điểm của bạn tốt hơn họ. Có gì chứng minh? Không, chỉ là những ví dụ để cho thấy sự khác biệt trong một khía cạnh nào đó, phù hợp với người đó mà thôi. Không có lý do gì để bảo người khác nên 'return sớm' thay cho việc dùng 'else', không có lợi ích gì cho việc sửa code chỉ vì nó đang dùng switch, thay vì sử dụng những cú pháp cao siêu. Nếu bạn nghĩ code của bạn là hoàn hảo - bạn chưa trưởng thành.

## Mô hình cho mọi vấn đề
*(phần này hơi quá tầm hiểu biết nên mình dịch có thể sai ý)*

Tôi quan sát thấy có những người đang cố gắng thể hiện cho cộng đồng lập trình rằng FP là một mô hình tốt hơn những cái khác, và những cái khác đó không đáng thử. Hầu hết những chương trình đang hoạt động và được bảo trì trong các ngành công nghiệp và xã hội này được viết bằng kiểu lập trình mệnh lệnh. Bạn nói lập trình mệnh lệnh là sai - bạn chưa trưởng thành.
> **Ghi chú:** Không phải tôi đang nói FP sai, mà chỉ là không lý tưởng, không phải là giải pháp hoàn toàn cho mọi vấn đề.

## Static vs dynamic
*(Ngôn ngữ static: C, C++, C#, Java, Go, Rust...; ngôn ngữ dynamic: JavaScript, Python, PHP...)*

Không có khác biệt gì giữa kiểu static và kiểu dynamic. Có người nói - tôi không cần kiểu static, chả có lợi ích gì khi sử dụng. Có người lại nói - kiểu dynamic chỉ có một dạng, và dễ bị lỗi mà mình chả làm gì được. Cá nhân tôi thích ngôn ngữ kiểu static, nhưng tôi thấy được sự đánh đổi, đó là ngôn ngữ kiểu static muốn đạt được độ biểu đạt tốt cần phải tạo những cách rất phức tạp để tạo sự đa hình (ví dụ như Haskell typeclass). Một ví dụ về thứ không thể được biểu đạt trong các ngôn ngữ kiểu static là - transducer(?). Ngôn ngữ kiểu dynamic cũng có một số lợi ích rõ ràng như viết những chương trình nhỏ, cho phép phát triển nhanh chóng. Mặt khác, ngôn ngữ kiểu static cung cấp những công cụ cho việc bảo trì code mà không phải lo. Bạn nói kiểu static vô dụng - bạn chưa trưởng thành. Bạn nói kiểu dynamic không có đất dung thân - bạn cũng chưa trưởng thành.

## Mọi người phải chơi theo luật của tui
Dự án mới, hãy tuân theo luật của tui. Rất phổ biến việc các senior developer tham gia vào một dự án,  thay vì hiểu rõ codebase hiện tại và tại sao lại viết code như vậy, họ hay nói - phải viết lại, hoặc - code sai bét vì không dùng thư viện x. Hãy nhớ tư duy phản biện có lợi, còn tư duy bác bỏ thì có hại. Nếu bạn muốn viết lại code của người khác, chỉ vì bạn không muốn hiểu nó - bạn chưa trưởng thành.

## Ngôn ngữ mà tui chọn là số 1
Mọi công nghệ đều có ưu điểm lẫn khuyết điểm. Một số ngôn ngữ, thư viện sẽ phù hợp với mình trong một số trường hợp nhất định. Thường thì chúng ta hay chọn những thư viện, ngôn ngữ mà mình đã quen thuộc. Và việc đó ok thôi. Nếu tiếng mẹ đẻ của bạn là tiếng Ba Lan, mặc dù tiếng Ba Lan là một ngôn ngữ khó, và bạn dễ diễn đạt bằng tiếng Ba Lan hơn là tiếng Anh, điều đó không có nghĩa là tiếng Ba Lan vốn dĩ tốt hơn trong việc diễn đạt, nó chỉ phù hợp trong tình huống của bạn mà thôi. Nếu bạn chọn Node.js cho server của mình, chỉ vì bạn có 1 team chuyên JS, cũng ok thôi, nhưng đừng nói dối rằng bạn chọn Node.js vì nó là công nghệ server side tốt nhất. Nếu bạn nói ngôn ngữ mà bạn chọn là số 1 - bạn chưa trưởng thành.

## Ngôn ngữ lập trình thực thụ
PHP không phải là ngôn ngữ lập trình. Tại sao PHP không phải trong khi Python lại phải? Chỉ khác nhau về cú pháp, cả 2 đều vẫn biễu diễn các giải thuật. Chúng ta có thể khách quan nói Python được thiết kế tốt hơn, cú pháp đẹp hơn, nhưng không có nghĩa PHP không phải là một ngôn ngữ lập trình. Nếu bạn nói PHP không phải là một ngôn ngữ lập trình - bạn chưa trưởng thành.

## Lập trình viên thực thụ
Frontend không phải là lập trình. Hiện tại thì ý kiến này không còn phổ biến như trước. Nhưng tôi còn nhớ thời gian mà những developer backend tự hào gọi mình là "lập trình viên thực thụ". Nếu bạn nghĩ vậy - bạn chưa trưởng thành.

## Mọi thứ đều có sự đánh đổi
Hãy suy nghĩ, nhìn nhận những điểm mạnh và điểm yếu, am hiểu chứ đừng quá mê muội công cụ của mình. Mỗi ngôn ngữ có điểm khác biệt, nhưng hầu hết đều thực hiện những việc như nhau. Việc ghét hay thích không phải là việc nên làm, làm vậy không giúp bạn làm việc tốt hơn đâu. Chỉ làm với một ngôn ngữ trong 10 năm cũng vậy. Hãy thay đổi, cả ngôn ngữ, lẫn đomain, học hỏi từ những người khác, bạn là senior trong JS, tuyệt, nhưng đừng sợ khi là một junior Java developer, thay đổi giúp bạn trở thành một lập trình viên tốt hơn, mở mang hơn.

## Áp dụng những quy tắc đã thống nhất
Code cần phải nhất quán, các dự án nên có những quy tắc, và mọi người nên tuân theo những quy tắc này. Nếu chúng ta đồng ý sử dụng các kỹ thuật FP như map và reduce, hãy sử dụng chúng, nếu chúng ta đã thống nhất các quy ước coding, hãy tuân thủ, nếu chúng ta cần unit test, hãy thực hiện, cho dù bạn không thấy lợi ích gì. Nếu những quy tắc cần sửa đổi, hãy ngồi xuống, thảo luận, đề xuất ý kiến, đừng gò ép. Một vài thành viên team có thể không thoải mái với những gì mà bạn thấy thoải mái, bạn cần giúp họ, đưa họ lên cùng level với bạn. Nhưng cũng có thể có lúc bạn cần phải gác ý kiến của bạn, vì lợi ích của cả team.

## Hãy tạo ảnh hưởng tích cực
Không bảo vệ quan điểm không có nghĩa bạn không quan tâm đến chất lượng code hay đồng ý với những giải pháp tệ. Bạn vẫn thấy được code nào dở, code nào tốt, bạn vẫn refactor code dở, bạn vẫn cố gắng hướng tới những giải pháp tốt hơn. Điều khác biệt là quyết định của bạn không lệ thuộc một cách phiến diện một framework mà bạn biết, những cái phổ biến hay giải pháp mà bạn thích và hay dùng. Mà quyết định của bạn đựa trên kiến thức và kinh nghiệm. Bạn nhìn thấy được sự đánh đổi. Nếu quyết định của bạn dựa trên kinh nghiệm, bạn có thể diễn đạt và lý giải tại sao ý tưởng của bạn tốt mà không phải gò ép ai làm theo.


Bài đăng này được viết cho bản thân tôi ở quá khứ. Phải, tôi là một developer với nhiều quan điểm cứng nhắc. Tôi đã phải mất rất nhiều thời gian để hiểu rằng thái độ như vậy làm tôi yếu kém. Tôi mong là bạn sẽ nhận ra sớm hơn tôi. Và cuối cùng, cũng nhớ rằng, luôn có một vài đồng nghiệp cùng làm lập trình của bạn sẽ không bao giờ trưởng thành.

----
@khangnd<br>[![Github](https://images.viblo.asia/20x20/81dd12f0-a8c9-403f-ae51-27b92828ca22.png)](https://github.com/khang-nd) [![Linkedin](https://images.viblo.asia/20x20/4981766e-5e57-401a-8623-d3657a3148e5.png)](https://www.linkedin.com/in/khangnd/) [![Dev.to](https://images.viblo.asia/20x20/3921db2e-e4e5-45d7-acc8-e8b92e02d47d.png)](https://dev.to/khangnd) [![Fandom](https://images.viblo.asia/20x20/fad64df3-0be8-4481-b810-8995f18f71ea.png)](https://dev.fandom.com/wiki/User:KhangND)

Bài viết được dịch từ DEV.to. Truy cập bài viết gốc: *Grow up*.

Vừa qua mình có đọc được một bài viết chia sẻ kinh nghiệm của một dev trên trang DEV.to rất hay và đâu đó thấy hình ảnh của bản thân phảng phất trong những khuyết điểm được đề cập. Mình xin dịch lại bài viết để cùng chia sẻ và nghiền ngẫm những ý hay trong bài.

Những quan điểm cứng nhắc về những thứ không đáng, đây là điều đang d...

Hãy trưởng thành - Grow up

![](https://images.viblo.asia/554010d0-223f-4b56-aee0-049bf3dc23f6.png)
Hello mọi người,

Bài viết đầu tiên của mình trên VIBLO, mình muốn chia sẻ một trang web đơn giản mình đã xây dựng để liệt kê các extension hữu ích dành cho VS Code.
# TL;DR
Dành cho những bạn lười đọc:
* [Đây là trang web thành quả](https://khang-nd.github.io/vscode-exts)
* [Đây là mã nguồn](https://github.com/khang-nd/vscode-exts)

Kỹ thuật sử dụng:
* HTML, JS
* Cú pháp ES6
* [Fetch API](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API)
* [Bulma CSS](https://bulma.io/)

# Coding
Cấu trúc chính gồm có
```html
vscode-exts
  |_exts.js
  |_get.js
  |_index.html
```

Đầu tiên mình tạo file [exts.js](https://github.com/khang-nd/vscode-exts/blob/main/exts.js) để chứa mảng các extension ID. ID này bạn có thể lấy từ URL của Marketplace, ví dụ:
`https://marketplace.visualstudio.com/items?itemName=`**`streetsidesoftware.code-spell-checker`**

Tiếp theo, tạo file [get.js](https://github.com/khang-nd/vscode-exts/blob/main/get.js) để thực hiện việc lấy data bằng Fetch API:
```javascript
const marketUrl = "https://marketplace.visualstudio.com/items?itemName=";
const installUrl = "vscode://";
const selector = {
  name: ".ux-item-name",
  author: ".ux-item-publisher",
  installs: ".ux-item-rating",
};

const promises = extensions.map((ext) =>
  fetch(marketUrl + ext)
    .then((page) => page.text())
    .then((content) => {
      const dom = new DOMParser().parseFromString(content, "text/html");
      return {
        name: dom.querySelector(selector.name).textContent,
        author: dom.querySelector(selector.author).textContent,
        installs: dom.querySelector(selector.installs).textContent.replace(/[^\d,]/g, ""),
        marketUrl: marketUrl + ext,
        installUrl: installUrl + ext,
      };
    })
);

const getExtensions = () => Promise.all(promises);
```
Ở đây mình dùng Fetch để lấy data trực tiếp từ cây DOM. Mình map các extension ID vào request, sau đó trả về một Promise sau khi tất cả các request cùng hoàn tất.

Cuối cùng là tạo file [index.html](https://github.com/khang-nd/vscode-exts/blob/main/index.html), nhúng 2 file js vào, sử dụng Bulma CSS để tinh chỉnh giao diện và hiển thị data lên giao diện.

Mong là bài chia sẻ giúp ích cho mọi người.<br>
@khangnd<br>[![Github](https://images.viblo.asia/20x20/81dd12f0-a8c9-403f-ae51-27b92828ca22.png)](https://github.com/khang-nd) [![Linkedin](https://images.viblo.asia/20x20/4981766e-5e57-401a-8623-d3657a3148e5.png)](https://www.linkedin.com/in/khangnd/) [![Dev.to](https://images.viblo.asia/20x20/3921db2e-e4e5-45d7-acc8-e8b92e02d47d.png)](https://dev.to/khangnd) [![Fandom](https://images.viblo.asia/20x20/fad64df3-0be8-4481-b810-8995f18f71ea.png)](https://dev.fandom.com/wiki/User:KhangND)

![](https://images.viblo.asia/554010d0-223f-4b56-aee0-049bf3dc23f6.png)


Hello mọi người,

Bài viết đầu tiên của mình trên VIBLO, mình muốn chia sẻ một trang web đơn giản mình đã xây dựng để liệt kê các extension hữu ích dành cho VS Code.
TL;DR
Dành cho những bạn lười đọc:
* Đây là trang web thành quả
* Đây là mã nguồn

Kỹ thuật sử dụng:
* HTML, JS
* Cú pháp ES6
* Fetch API
* Bulma CSS

Coding
Cấu trúc chính gồm có

Đầu tiên mình tạo file exts.js để chứa mảng các e...

Platform