<![CDATA[NTH Blog]]> https://hungvn.com RSS for Node Tue, 02 Jun 2026 15:40:26 GMT Tue, 02 Jun 2026 15:40:26 GMT <![CDATA[Running express.js server over HTTPS]]> https://hungvn.com/blog/running-express.js-server-over-https https://hungvn.com/blog/running-express.js-server-over-https Thu, 27 Feb 2020 06:59:28 GMT <![CDATA[Scrum cho người mới bắt đầu - Phần cuối: Các sự kiện trong Scrum]]> https://hungvn.com/blog/scrum-cho-nguoi-moi-bat-djau-phan-cuoi-cac-su-kien-trong-scrum https://hungvn.com/blog/scrum-cho-nguoi-moi-bat-djau-phan-cuoi-cac-su-kien-trong-scrum Mon, 20 Jan 2020 11:00:00 GMT <![CDATA[Scrum cho người mới bắt đầu - Phần 3: Nhóm scrum]]> https://hungvn.com/blog/scrum-cho-nguoi-moi-bat-djau-phan-3-nhom-scrum https://hungvn.com/blog/scrum-cho-nguoi-moi-bat-djau-phan-3-nhom-scrum Wed, 15 Jan 2020 02:45:00 GMT <![CDATA[Scrum cho người mới bắt đầu - Phần 2: Scrum cơ bản]]> https://hungvn.com/blog/scrum-cho-nguoi-moi-bat-djau-phan-2-scrum-co-ban https://hungvn.com/blog/scrum-cho-nguoi-moi-bat-djau-phan-2-scrum-co-ban Sat, 11 Jan 2020 08:00:00 GMT <![CDATA[Scrum cho người mới bắt đầu - Phần 1: Tổng quan về Agile]]> https://hungvn.com/blog/scrum-cho-nguoi-moi-bat-djau-phan-1-tong-quan-ve-agile https://hungvn.com/blog/scrum-cho-nguoi-moi-bat-djau-phan-1-tong-quan-ve-agile Sat, 04 Jan 2020 10:00:00 GMT <![CDATA[Những câu lệnh command Developer nên biết]]> somefile2 ``` ![](https://miro.medium.com/max/2296/1*NxLOMigqozU5EvxVdr1f7Q.png) --- # 5\. echo ``` $ echo "some text" ``` The _echo_ command in Linux is used to display a line of text/string that’s passed as an argument. The _echo_ is a built-in command that’s mostly used in shell scripts and batch files to output status text to the screen or a file. ![](https://miro.medium.com/max/2088/1*1bMjVqwhueQP5hvyMMdDKA.png) --- # 6\. touch ``` $ touch somefile ``` The _touch_ command is used to create a file without any content. The _touch_ command can be used when the user doesn’t have data to store at the time of file creation. ![](https://miro.medium.com/max/1528/1*RIrUCSW4TT_cJrnGy9ighQ.png) Notice how we’re using _touch_ to create the file and _cat_ to look inside the file. Since the newly created _index2.js_ file is empty, the cat returns nothing. Here are the main differences between _cat_ and*touch*: - _cat_— Used to create the file with the content. - _touch_— Creates a file without any content or empty files. Remember, the file created using _touch_ command is empty. This command is useful when the user doesn’t have data to store at the time of file creation. --- # 7\. mkdir ``` $ mkdir some-directory ``` As you guessed it, mkdir creates a new empty directory in the current active path. Instead of clicking around in your text editor or GUI, use this command to create new folders. ![](https://miro.medium.com/max/2184/1*FsxDBW5HDWJn9kHsw0My7A.png) _Note:_ Notice how we can peek inside the directory with the previous _ls_ command. ## 7.1 rm ``` $ rm someFile ``` Rm stands for remove, which does exactly what it says it does. Removes, or in other words, deletes a file. ![](https://miro.medium.com/max/2148/1*damLEKdyWY7aBPILFELVNg.png) By default, the _rm_ command doesn’t remove directories. You need to pass the _-rf_ flag to remove directories. ``` $ rm -rf some-directory ``` ![](https://miro.medium.com/max/2272/1*gXTLAllsEVTdWHCcDw83WQ.png) _Note:_ This removes the directory unconditionally, whether the directory has content inside or not. ## 7.2 rmdir ``` $ rmdir some-directory ``` The _rmdir_ command removes the directory if there’s no content inside the directory. ![](https://miro.medium.com/max/1880/1*aUJ0VbrVb_cTUf0okMxmWA.png) --- # 8\. tail ``` $ tail somefile ``` The _tail_ command reads a file and outputs the last part of it (the “tail”). ![](https://miro.medium.com/max/2804/1*Xvo2zdyDZqj4QhTHF0TLTg.png) The _tail_ command is useful when going through crash reports or previous history logs. Here’s an example of its usefulness when working with file logs. ``` # tail /var/log/messages Mar 20 12:42:22 hameda1d1c dhclient\[4334\]: DHCPREQUEST on eth0 to 255.255.255.255 port 67 (xid=0x280436dd) Mar 20 12:42:24 hameda1d1c avahi-daemon\[2027\]: Registering new address record for fe80::4639:c4ff:fe53:4908 on eth0.\*. Mar 20 12:42:28 hameda1d1c dhclient\[4334\]: DHCPREQUEST on eth0 to 255.255.255.255 port 67 (xid=0x280436dd) Mar 20 12:42:28 hameda1d1c dhclient\[4334\]: DHCPACK from 10.76.198.1 (xid=0x280436dd) Mar 20 12:42:30 hameda1d1c avahi-daemon\[2027\]: Joining mDNS multicast group on interface eth0.IPv4 with address 10.76.199.87. Mar 20 12:42:30 hameda1d1c avahi-daemon\[2027\]: New relevant interface eth0.IPv4 for mDNS. Mar 20 12:42:30 hameda1d1c avahi-daemon\[2027\]: Registering new address record for 10.76.199.87 on eth0.IPv4. Mar 20 12:42:30 hameda1d1c NET\[4385\]: /sbin/dhclient-script : updated /etc/resolv.conf Mar 20 12:42:30 hameda1d1c dhclient\[4334\]: bound to 10.76.199.87 -- renewal in 74685 seconds. Mar 20 12:45:39 hameda1d1c kernel: usb 3-7: USB disconnect, device number 2 ``` --- # 9\. wget ``` $ wget someurl ``` GNU Wget is a [free software](https://www.gnu.org/philosophy/free-sw) package for retrieving files using HTTP, HTTPS, FTP, and FTPS — the most widely-used internet protocols. It’s a non-interactive command-line tool, so it may easily be called from scripts, CRON jobs, terminals without X-Windows support, etc. ![](https://miro.medium.com/max/2880/1*nbzEhCeVUxT2-Px0oQbszQ.png) GNU Wget has many features to make retrieving large files or mirroring entire web or FTP sites easy, including: - Can resume aborted downloads using REST and RANGE - Can use filename wild cards and recursively mirror directories - NLS-based message files for many different languages - Optionally converts absolute links in downloaded documents to relative so that downloaded documents may link to each other locally - Runs on most UNIX-like operating systems as well as Microsoft Windows - Supports HTTP proxies - Supports HTTP cookies - Supports persistent HTTP connections - Unattended / background operation - Uses local file timestamps to determine whether documents need to be re-downloaded when mirroring - GNU Wget is distributed under the [GNU General Public License](https://www.gnu.org/licenses/gpl.html). Read the [official GNU documentation](https://www.gnu.org/software/wget/) for more information. --- # 10\. find ``` $ find path -name filename ``` The _find_ command lets you quickly lookup a file or directory. It’s useful when you’re working on a big project with hundreds of files and multiple directories. ![](https://miro.medium.com/max/1696/1*j291SZcYXSaPtdvqipX6sg.png) ## Search for files of a particular type The _find_ command also lets you search for the same type of files in a directory (and its subdirectories). For example, the following command will search for all _.js_ files in your current working directory. ``` $ find . -name "*.js" ``` ![](https://miro.medium.com/max/1992/1*_i8_TEIElXAAyXy-F1JQmA.png) --- # 11\. mv ``` $ mv somefile /to/some/other/path ``` The _mv_ command moves files or directories from one place to another. The _mv_ command supports moving single files, multiple files, and directories. ![](https://miro.medium.com/max/2360/1*TdqoyPUFrdBvI2Ws7cfyfQ.png) --- # Conclusion Thanks for reading, I hope you learned something new. If you know a handy command-line trick, please let’s grow together and post it in the responses. If you want to learn more about shell commands, I suggest grabbing the _“_[_Linux for beginners_](https://amzn.to/2QazBku)_”_ book. Stay curious and hungry! ]]> https://hungvn.com/blog/nhung-cau-lenh-command-developer-nen-biet https://hungvn.com/blog/nhung-cau-lenh-command-developer-nen-biet Thu, 26 Dec 2019 08:00:00 GMT <![CDATA[So sánh Redux và React Context]]> { const [articles, setArticles] = useState([ { id: 1, title: "post 1", body: "Quisque cursus, metus vitae pharetra" }, { id: 2, title: "post 2", body: "Quisque cursus, metus vitae pharetra" }, ]); return (
{articles.map(article => (
))}
); }; export default Articles; ``` - Add a _components_ folder in the _src_, then create _AddArticle/AddArticle.js_ and _Article/Article.js_. - In the _Article.js_ ```javascript import React from "react"; import "./Article.css"; const article = ({ article }) => (
{" "}

{article.title}

{article.body}

{" "}
); export default article; ``` - In the _AddArticle.js_ ```javascript import React, { useState } from "react"; import "./AddArticle.css"; const AddArticle = () => { const [article, setArticle] = useState(); const handleArticleData = e => { setArticle({ ...article, [e.target.id]: e.target.value, }); }; const addNewArticle = e => { e.preventDefault(); // The logic will come later }; return (
); }; export default AddArticle; ``` - In the _App.js_ ```javascript import React, { Fragment } from "react"; import AddArticle from "./components/AddArticle/AddArticle"; import Articles from "./containers/Articles"; function App() { return ( ); } export default App; ``` _So, if you've done with all the instructions above, we can move on and start implementing the context API._ ## Create a context A context helps us to handle state without passing down props on every component. Only the needed component will consume the context. To implement it, we need to create (it's optional) a new folder named _context_ in our project, and add this code below to _aricleContext.js_. - In _context/aricleContext.js_ ```javascript import React, { createContext, useState } from "react"; export const ArticleContext = createContext(); const ArticleProvider = ({ children }) => { const [articles, setArticles] = useState([ { id: 1, title: "post 1", body: "Quisque cursus, metus vitae pharetra" }, { id: 2, title: "post 2", body: "Quisque cursus, metus vitae pharetra" }, ]); const saveArticle = article => { const newArticle = { id: Math.random(), // not really unique but it's just an example title: article.title, body: article.body, }; setArticles([...articles, newArticle]); }; return ( {children} ); }; export default ArticleProvider; ``` The React library gives us access to a method called _createContext_. We can use it to as you might guess create a context. Here, we pass nothing to our context _ArticleContext_, but you can pass as argument object, array, string, etc. Then we define a function which will help us distribute the data through the _Provider_. We give to our _Provider_ two values: the list of articles and the method to add an article. By the way, _articles:articles_ and _saveArticle:saveArticle_ is the same as _articles_ and _saveArticle_ it's just a convenient syntax in case it confuses you. Now we've a context, however, we need to provide the context in order to consume it. To do that, we need to wrap our higher component with _ArticleProvider_ and _App.js_ might be the perfect one. So, let's add it to _App.js_. ## Provide the context - In _App.js_ ```javascript import React from "react"; import AddArticle from "./components/AddArticle/AddArticle"; import Articles from "./containers/Articles"; import ArticleProvider from "./context/articleContext"; function App() { return ( ); } export default App; ``` As you see here, we first import our context provider _ArticleProvider_ and wrap components which need to consume the context. Now what about consuming the context? and how we can do that. You might be surprised how easy it is to consume the context with hooks. So, let's do that. ## Consume the context We're going to consume the context in two components: _Articles.js_ and _AddArticle.js_. - In _Articles.js_ ```javascript import React, { useContext } from "react" import { ArticleContext } from "../context/articleContext" import Article from "../components/Article/Article" const Articles = () => { const { articles } = useContext(ArticleContext) return (
{articles.map(article => (
))}
) } export default Articles ``` With React hooks, we've now access to the _useContext_ hook. And as you might guess, it will help us consume the context. By passing our context _ArticleContext_ as argument to _useContext_, it gives us access to our state holden in _articleContext.js_. Here, we just need _articles_. Therefore, we pull it out and map through our articles and show them. Now, let's move on to _AddArticle.js_. - In _AddArticle.js_ ```javascript import React, { useState, useContext } from "react"; import { ArticleContext } from "../../context/articleContext"; import "./AddArticle.css"; const AddArticle = () => { const { saveArticle } = useContext(ArticleContext); const [article, setArticle] = useState(); const handleArticleData = e => { setArticle({ ...article, [e.target.id]: e.target.value, }); }; const addNewArticle = e => { e.preventDefault(); saveArticle(article); }; return (
); }; export default AddArticle; ``` As the previous case, here again we use _useContext_ to pull out _saveArticle_ from our context. With that, we can now safely add a new article through the React Context. We now manage our whole application's state through the React Context. However, we can still improve it through another hook named _useReducer_. ## Enhance the context with useReducer The _useReducer_ hook is an alternative to _useState_. It's mostly use for the more complex state. _useReducer_ accepts a reducer function with the initial state of our React app, and returns the current state, then dispatches a function. This will be much more clear, when we start implementing it. Now, we've to create a new file _reducer.js_ in our context folder and add this code block below. - In _reducer.js_ ```javascript export const reducer = (state, action) => { switch (action.type) { case "ADD_ARTICLE": return [ ...state, { id: Math.random(), // not really unique but it's just an example title: action.article.title, body: action.article.body, }, ]; default: return state; } }; ``` As you can see, the function _reducer_ receives two parameters: _state_ and _action_. Then, we check if the type of action is equal to _ADD_ARTICLE_ (you can create a constant or file to avoid mistyping), if it's the case add a new article to our state. This syntax might be familiar if you've used redux. Now, the logic to add a new article is handled by the reducer. We've not done yet, let's add it to our context file. ```javascript import React, { createContext, useReducer } from "react"; import { reducer } from "./reducer"; export const ArticleContext = createContext(); const ArticleProvider = ({ children }) => { const [articles, dispatch] = useReducer(reducer, [ { id: 1, title: "post 1", body: "Quisque cursus, metus vitae pharetra" }, { id: 2, title: "post 2", body: "Quisque cursus, metus vitae pharetra" }, ]); return ( {children} ); }; export default ArticleProvider; ``` Here, we start by importing the _useReducer_ hook and our function _reducer_. As i mention earlier, _useReducer_ takes a function. Therefore, we've to pass our reducer function to it and as second argument the initial state of our application. Now _useReducer_ gives us access to our _articles_ and a _dispatch_ function (you can name it whatever you like). And we can now, update our provider with these new values given by _useReducer_. You can already see that our context file is now much cleaner. By renaming the function which add a new article to _dispatch_, we've now to update a little bit our _AddArticle.js_ file. - In _AddArticle.js_ ```javascript import React, { useState, useContext } from "react"; import { ArticleContext } from "../../context/articleContext"; import "./AddArticle.css"; const AddArticle = () => { const { dispatch } = useContext(ArticleContext); const [article, setArticle] = useState(); const handleArticleData = e => { setArticle({ ...article, [e.target.id]: e.target.value, }); }; const addNewArticle = e => { e.preventDefault(); dispatch({ type: "ADD_ARTICLE", article }); }; return (
); }; export default AddArticle; ``` Now, instead of pulling out _saveArticle_, now we get the _dispatch_ function. It expects a type of action _ADD_ARTICLE_ and a value _article_ which will be the new article. With that, our project is now managed through the context API and React Hooks. ## Redux VS the React Context: Who wins? You can now clearly see the difference between Redux and React Context through their implementations on our project. However, Redux is far from dead or be killed by React Context. Redux is such boilerplate and require a bunch of libraries. But it remains a great solution towards props drilling. The context Api with hooks is much more easier to implement and will not increase your bundle size. However who wins? in my opinion, for a low-frequency updates like locale, theme changes, user authentication, etc. the React Context is perfectly fine. But with a more complex state which has a high-frequency updates, the React Context won't be a good solution. Because, the React Context will triggers a re-render on each update, and optimizing it manually can be really tough. And there, a solution like Redux is much easier to implement. You can find the finished project [here](https://github.com/ibrahima92/react-context-hooks-example) ]]> https://hungvn.com/blog/so-sanh-redux-va-react-context https://hungvn.com/blog/so-sanh-redux-va-react-context Mon, 16 Dec 2019 04:30:00 GMT <![CDATA[Sử dụng Google Sheets để lưu trữ dữ liệu web]]> ``` Step 3: Initiate a script block and store the path of the spreadsheet in a variable. Follow up with a \_init() \_function with a key, callback and set simpleSheet to true. Create a new function _showInfo_ and pass data and tabletop as arguments. This is interesting because tabletop (after _init()_) automatically holds the data of the sheet you assigned in the sheet variable in Step 2. Step 4: Create a basic card based structure that will repeat for the number of rows there are with details. ```html

Status:

Built Date:

Destroyed Date:

Destroyed by:

View details

``` **Step 5:** Now go back to the sheet and note down the column headers. This is how it looks now. ![](https://thecodepost.org/wp-content/uploads/2019/12/google-sheets-headers-1024x173.png) Google Sheets Headers -- note that they are all lowercase. This helps Tabletop. **Note: **Tabletop requires you to follow a simple guideline for naming column headers. The headers should be the first row and each of the header names should start with a small letter. Accessing the data is simple. For instance if your header cell is named 'name', getting all names from the sheet will require you to iterate i over data\[i\].name. Therefore for my headers in the sheet, the respective data fields are -- 1. data\[i\].no 2. data\[i\].summary 3. data\[i\].datebuilt 4. data\[i\].destroyedby 5. data\[i\].status 6. data\[i\].details_link So the **_Step 4_** can be re-written as -- ```html

'+data[i].name+'

'+data[i].name+'

' + data[i].summary + '

Status: '+ data[i].status + '

Built Date: '+ data[i].builtdate + '

Destroyed Date: '+ data[i].destroyeddate + '

Destroyed by: '+ data[i].destroyedby + '

View details

``` **Step 6:** Load the file up and access it over localhost. It should take a couple of seconds to actually fetch the data after loading the JavaScript, but the static content will be loaded in an instant. The appearance of the page to the end user can be further improved if the hero section of the page is enlarged to cover the entire page by default. By the time he is ready to scroll down, the images and relevant data will already be loaded. ![](https://thecodepost.org/wp-content/uploads/2019/12/google-sheets-as-cms-local-1024x526.png) Change any data in the Google Sheets and you will see the changes done here as well You can also debug the issues by simply enabling the Console of your browser's Developer Tools. The JSON response with the data object and its contents will be output there by default. If there is a parsing error, you can make sure the object returns the contents correctly. ![](https://thecodepost.org/wp-content/uploads/2019/12/data-object-from-google-sheets-1024x529.png) The data array is output in the console You can share the sheet with edit access to only those who you trust and your site will be up and running without depending on any other heavy server/database resource. This may run into issues if there are too many records as AJAX like request will slow down to a crawl, so a pagination may be necessary. Using Apps Script on the Spreadsheet itself or conditional JavaScript logic in the page, this can be implemented. I have hosted this on Github as well. You can [**find the site**](https://sarthakganguly.github.io/mutewitnesses/) and the [**code in the links herein**](https://github.com/sarthakganguly/mutewitnesses). ]]> https://hungvn.com/blog/su-dung-google-sheets-dje-luu-tru-du-lieu-web https://hungvn.com/blog/su-dung-google-sheets-dje-luu-tru-du-lieu-web Fri, 01 Nov 2019 10:30:00 GMT <![CDATA[JavaScript Design Patterns]]> Source code for the examples of all the design patterns explained here is available on **[GitHub](https://github.com/drenther/js-design-patterns)** ## Introduction We write code to solve problems. Problems that usually have many similarities and when trying to solve them, we notice several common patterns. This is where design patterns come in. > A **_design pattern_** is a term used in software engineering for a general reusable solution to a commonly occurring problem in software design. The underlying concept of design patterns has been around in the software engineering industry since the very beginning, but they weren't really so formalized. [Design Patterns: Elements Of Reusable Object-Oriented Software](https://en.wikipedia.org/wiki/Design_Patterns) written by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides — the famous Gang of Four (GoF) was instrumental in pushing the formalized concept of design patterns in software engineering. Now, design patterns are an essential part of software development and have been so for a long time. There were 23 design patterns introduced in the original book. **Creational Patterns** ![](https://miro.medium.com/max/672/1*wPH4aXJ_Arv4jnliLUySyQ.png) **Structural Patterns** ![](https://miro.medium.com/max/682/1*pD3iU_fQx56oDlIMMBnbNw.png) **Behavioural Patterns** ![](https://miro.medium.com/max/673/1*weYSJ2_ZxVY8yZ8reEGq6g.png) Design Patterns are beneficial for various reasons. They are proven solutions that the industry veterans have tried and tested. They are solid approaches that solve issues in a widely accepted way and reflect the experience and insights of the industry-leading developers that helped define them. Patterns also make your code more reusable and readable while speeding up the development process vastly. Design patterns are by no means finished solutions. They only provide us with approaches or schemes to solve a problem. > _**Note:** In this article, we will mainly talk about design patterns from an object-oriented point of view and in the context of their usability in modern JavaScript. That is why many classic patterns from GoF may be omitted and some modern patterns from sources like_ [**Addy Osmani’s Learn JavaScript Design Patterns**](https://addyosmani.com/resources/essentialjsdesignpatterns/book/) _will be included. The examples are kept simple for easier understanding and are hence not the most optimized implementation of their respective design patterns._ ## Categories of Design Patterns Design Patterns are usually categorized into three major groups. ### Creational Design Patterns As the name suggests, these patterns are for handling object creational mechanisms. A Creational Pattern basically solves a problem by controlling the creation process of an object. We will discuss the following patterns in details — **Constructor Pattern, Factory Pattern, Prototype Pattern** and **Singleton Pattern.** ### Structural Design Patterns These patterns are concerned with class and object composition. They help structure or restructure one or more parts without affecting the entire system. In other words, they help obtain new functionalities without tampering with the existing ones. We will discuss the following patterns in details — **Adapter Pattern, Composite Pattern, Decorator Pattern, Facade Pattern, Flyweight Pattern** and **Proxy Pattern.** ### Behavioural Design Patterns These patterns are concerned with improving communication between dissimilar objects. We will discuss the following patterns in details — **Chain of Responsibility Pattern, Command Pattern, Iterator Pattern, Mediator Pattern, Observer Pattern, State Pattern, Strategy Pattern** and **Template Pattern.** ## Creational Patterns ### Constructor Pattern This is a class-based creational design pattern. Constructors are special functions that can be used to instantiate new objects with methods and properties defined by that function. It is not one of the classic design patterns. In fact, it is more of a basic language construct than a pattern in most object-oriented languages. But in JavaScript, objects can be created on the fly without any constructor functions or “class” definition. Therefore, I think it is important to lay down the foundation for other patterns to come with this simple one. Constructor pattern is one of the most commonly used patterns in JavaScript for creating new objects of a given kind. In this example, we define a _Hero_ class with attributes like _name_ and _specialAbility_ and method like _getDetails_. Then, we instantiate an object _IronMan_ by invoking the constructor method with the _new_ keyword passing in the values for the respective attributes as arguments. ```javascript // traditional Function-based syntax function Hero(name, specialAbility) { // setting property values this.name = name; this.specialAbility = specialAbility; // declaring a method on the object this.getDetails = function () { return this.name + ' can ' + this.specialAbility; }; } // ES6 Class syntax class Hero { constructor(name, specialAbility) { // setting property values this._name = name; this._specialAbility = specialAbility; // declaring a method on the object this.getDetails = function () { return `${this._name} can ${this._specialAbility}`; }; } } // creating new instances of Hero const IronMan = new Hero('Iron Man', 'fly'); console.log(IronMan.getDetails()); // Iron Man can fly ``` ### Factory Pattern Factory Pattern is another class-based creational pattern. In this, we provide a generic interface that delegates the responsibility of object instantiation to its subclasses. This pattern is frequently used when we need to manage or manipulate collections of objects that are different yet have many similar characteristics. In this example, we create a factory class named _BallFactory_ that has a method that takes in parameters and depending on the parameters it delegates the object instantiation responsibility to the respective class. If the type parameter is *"football"* or *"soccer"* object instantiation is handled by _Football_ class but if it is _"basketball"_ object instantiation is handled by _Basketball_ class. ```javascript class BallFactory { constructor() { this.createBall = function (type) { let ball; if (type === "football" || type === "soccer") ball = new Football(); else if (type === "basketball") ball = new Basketball(); ball.roll = function () { return `The ${this._type} is rolling.`; }; return ball; }; } } class Football { constructor() { this._type = "football"; this.kick = function () { return "You kicked the football."; }; } } class Basketball { constructor() { this._type = "basketball"; this.bounce = function () { return "You bounced the basketball."; }; } } // creating objects const factory = new BallFactory(); const myFootball = factory.createBall("football"); const myBasketball = factory.createBall("basketball"); console.log(myFootball.roll()); // The football is rolling. console.log(myBasketball.roll()); // The basketball is rolling. console.log(myFootball.kick()); // You kicked the football. console.log(myBasketball.bounce()); // You bounced the basketball. ``` ### Prototype Pattern This pattern is an object-based creational design pattern. In this, we use a sort of a “skeleton” of an existing object to create or instantiate new objects. This pattern is specifically important and beneficial to JavaScript because it utilizes prototypal inheritance instead of a classic object-oriented inheritance. Hence, it plays to JavaScript’s strength and has native support. In this example, we have a _car_ object that we use as the prototype to create another object _myCar_ with JavaScript’s _Object.create_ feature and define an extra property _owner_ on the new object. ```javascript // using Object.create as was recommended by ES5 standard const car = { noOfWheels: 4, start() { return "started"; }, stop() { return "stopped"; }, }; // Object.create(proto[, propertiesObject]) const myCar = Object.create(car, { owner: { value: "John" } }); console.log(myCar.__proto__ === car); // true ``` ### Singleton Pattern Singleton is a special creational design pattern where only one instance of a class can exist. It works like this — if no instance of the singleton class exists then a new instance is created and returned but if an instance already exists then the reference to the existing instance is returned. A perfect real-life example would be that of _mongoose_ (the famous Node.js ODM library for MongoDB). It utilizes the singleton pattern. In this example, we have a _Database_ class that is a Singleton. First, we create an object _mongo_ by using the _new_ operator to invoke the _Database_ class constructor. This time an object is instantiated because none already exists. The second time, when we create the _mysql_ object, no new object is instantiated but instead the reference to the object that was instantiated earlier i.e. the _mongo_ object is returned. ```javascript class Database { constructor(data) { if (Database.exists) { return Database.instance; } this._data = data; Database.instance = this; Database.exists = true; return this; } getData() { return this._data; } setData(data) { this._data = data; } } // usage const mongo = new Database("mongo"); console.log(mongo.getData()); // mongo const mysql = new Database("mysql"); console.log(mysql.getData()); // mongo ``` ## Structural Patterns ### Adapter Pattern This is a structural pattern where the interface of one class is translated into another. This pattern lets classes work together that could not otherwise because of incompatible interfaces. This pattern is often used to create wrappers for new refactored APIs so that other existing old APIs can still work with them. This is usually done when new implementations or code refactoring (done for reasons like performance gains) result in a different public API while the other parts of the system are still using the old API and hence needs to be adapted to work together. In this example, we have an old API i.e. _OldCalculator_ class and a new API i.e. _NewCalculator_ class. The _OldCalculator_ class provides an _operation_ method for both addition and subtraction while the _NewCalculator_ provides separate methods for addition and subtraction. The Adapter class _CalcAdapter_ wraps the _NewCalculator_ to add the _operation_ method to the public facing API while using its own addition and subtraction implementation under the hood. ```javascript // old interface class OldCalculator { constructor() { this.operations = function (term1, term2, operation) { switch (operation) { case "add": return term1 + term2; case "sub": return term1 - term2; default: return NaN; } }; } } // new interface class NewCalculator { constructor() { this.add = function (term1, term2) { return term1 + term2; }; this.sub = function (term1, term2) { return term1 - term2; }; } } // Adapter Class class CalcAdapter { constructor() { const newCalc = new NewCalculator(); this.operations = function (term1, term2, operation) { switch (operation) { case "add": // using the new implementation under the hood return newCalc.add(term1, term2); case "sub": return newCalc.sub(term1, term2); default: return NaN; } }; } } // usage const oldCalc = new OldCalculator(); console.log(oldCalc.operations(10, 5, "add")); // 15 const newCalc = new NewCalculator(); console.log(newCalc.add(10, 5)); // 15 const adaptedCalc = new CalcAdapter(); console.log(adaptedCalc.operations(10, 5, "add")); // 15; ``` ### Composite Pattern This is a structural design pattern that composes objects into tree-like structures to represent whole-part hierarchies. In this pattern, each node in the tree-like structure can be either an individual object or a composed collection of objects. Regardless, each node is treated uniformly. ![](https://miro.medium.com/max/373/1*yAkeYCKDaRQtMRAV2Kx5sA.png) It is a bit complex to visualize this pattern. The easiest way to think about this is with the example of a multi-level menu. Each node can be a distinct option or it can be a menu itself which has multiple options as its child. A node component with children is a composite component while a node component without any child is a leaf component. In this example, we create a base class of _Component_ that implements the common functionalities needed and abstracts the other methods needed. The base class also has a static method that utilizes recursion to traverse a composite tree structure made with its subclasses. Then we create two subclasses extending the base class — _Leaf_ that does not have any children and _Composite_ that can have children and hence have methods handling adding, searching and removing child functionalities. The two subclasses are used to create a composite structure i.e. a tree in this case. ```javascript class Component { constructor(name) { this._name = name; } getNodeName() { return this._name; } // abstract methods that need to be overridden getType() {} addChild(component) {} removeChildByName(componentName) {} removeChildByIndex(index) {} getChildByName(componentName) {} getChildByIndex(index) {} noOfChildren() {} static logTreeStructure(root) { let treeStructure = ""; function traverse(node, indent = 0) { treeStructure += `${"--".repeat(indent)}${node.getNodeName()}\n`; indent++; for (let i = 0, length = node.noOfChildren(); i < length; i++) { traverse(node.getChildByIndex(i), indent); } } traverse(root); return treeStructure; } } class Leaf extends Component { constructor(name) { super(name); this._type = "Leaf Node"; } getType() { return this._type; } noOfChildren() { return 0; } } class Composite extends Component { constructor(name) { super(name); this._type = "Composite Node"; this._children = []; } getType() { return this._type; } addChild(component) { this._children = [...this._children, component]; } removeChildByName(componentName) { this._children = [...this._children].filter( component => component.getNodeName() !== componentName ); } removeChildByIndex(index) { this._children = [...this._children.slice(0, index), ...this._children.slice(index + 1)]; } getChildByName(componentName) { return this._children.find(component => component.name === componentName); } getChildByIndex(index) { return this._children[index]; } noOfChildren() { return this._children.length; } } // usage const tree = new Composite("root"); tree.addChild(new Leaf("left")); const right = new Composite("right"); tree.addChild(right); right.addChild(new Leaf("right-left")); const rightMid = new Composite("right-middle"); right.addChild(rightMid); right.addChild(new Leaf("right-right")); rightMid.addChild(new Leaf("left-end")); rightMid.addChild(new Leaf("right-end")); // log console.log(Component.logTreeStructure(tree)); /* root --left --right ----right-left ----right-middle ------left-end ------right-end ----right-right */ ``` ### Decorator Pattern This is also a structural design pattern that focuses on the ability to add behaviour or functionalities to existing classes dynamically. It is another viable alternative to sub-classing. The decorator type behaviour is very easy to implement in JavaScript because JavaScript allows us to add methods and properties to object dynamically. The simplest approach would be to just add a property to an object but it will not be efficiently reusable. In fact, there is a proposal to add decorators to the JavaScript language. Take a look at [**Addy Osmani’s post**](https://medium.com/google-developers/exploring-es7-decorators-76ecb65fb841) about decorators in JavaScript. If you want to read about the proposal itself — it’s available [**here**](https://tc39.github.io/proposal-decorators/). In this example, we create a _Book_ class. We further create two decorator functions that accept a book object and returns a "decorated" _book_ object — _giftWrap_ that adds one new attribute and one new function and _hardbindBook_ that adds one new attribute and edits the value of one existing attribute. ```javascript class Book { constructor(title, author, price) { this._title = title; this._author = author; this.price = price; } getDetails() { return `${this._title} by ${this._author}`; } } // decorator 1 function giftWrap(book) { book.isGiftWrapped = true; book.unwrap = function () { return `Unwrapped ${book.getDetails()}`; }; return book; } // decorator 2 function hardbindBook(book) { book.isHardbound = true; book.price += 5; return book; } // usage const alchemist = giftWrap(new Book("The Alchemist", "Paulo Coelho", 10)); console.log(alchemist.isGiftWrapped); // true console.log(alchemist.unwrap()); // 'Unwrapped The Alchemist by Paulo Coelho' const inferno = hardbindBook(new Book("Inferno", "Dan Brown", 15)); console.log(inferno.isHardbound); // true console.log(inferno.price); // 20 ``` ### Facade Pattern This is a structural design pattern that is widely used in the JavaScript libraries. It is used to provide a unified and simpler public facing interface for ease of use that shields away from the complexities of its consisting subsystems or subclasses. The use of this pattern is very common in libraries like jQuery. In this example, we create a public facing API with the class _ComplaintRegistry_. It exposes only one method to be used by the client i.e. _registerComplaint_. It internally handles instantiating required objects of either _ProductComplaint_ or _ServiceComplaint_ based on the type argument. It also handles all the other complex functionalities like generating a unique ID, storing the complaint in memory, etc. But, all these complexities are hidden away using the Facade pattern. ```javascript let currentId = 0; class ComplaintRegistry { registerComplaint(customer, type, details) { const id = ComplaintRegistry._uniqueIdGenerator(); let registry; if (type === "service") { registry = new ServiceComplaints(); } else { registry = new ProductComplaints(); } return registry.addComplaint({ id, customer, details }); } static _uniqueIdGenerator() { return ++currentId; } } class Complaints { constructor() { this.complaints = []; } addComplaint(complaint) { this.complaints.push(complaint); return this.replyMessage(complaint); } getComplaint(id) { return this.complaints.find(complaint => complaint.id === id); } replyMessage(complaint) {} } class ProductComplaints extends Complaints { constructor() { super(); if (ProductComplaints.exists) { return ProductComplaints.instance; } ProductComplaints.instance = this; ProductComplaints.exists = true; return this; } replyMessage({ id, customer, details }) { return `Complaint No. ${id} reported by ${customer} regarding ${details} have been filed with the Products Complaint Department. Replacement/Repairment of the product as per terms and conditions will be carried out soon.`; } } class ServiceComplaints extends Complaints { constructor() { super(); if (ServiceComplaints.exists) { return ServiceComplaints.instance; } ServiceComplaints.instance = this; ServiceComplaints.exists = true; return this; } replyMessage({ id, customer, details }) { return `Complaint No. ${id} reported by ${customer} regarding ${details} have been filed with the Service Complaint Department. The issue will be resolved or the purchase will be refunded as per terms and conditions.`; } } // usage const registry = new ComplaintRegistry(); const reportService = registry.registerComplaint("Martha", "service", "availability"); // 'Complaint No. 1 reported by Martha regarding availability have been filed with the Service Complaint Department. The issue will be resolved or the purchase will be refunded as per terms and conditions.' const reportProduct = registry.registerComplaint("Jane", "product", "faded color"); // 'Complaint No. 2 reported by Jane regarding faded color have been filed with the Products Complaint Department. Replacement/Repairment of the product as per terms and conditions will be carried out soon.' ``` ### Flyweight Pattern This is a structural design pattern focused on efficient data sharing through fine-grained objects. It is used for efficiency and memory conservation purposes. This pattern can be used for any kind of caching purposes. In fact, modern browsers use a variant of flyweight pattern to prevent loading same images twice. In this example, we create a fine-grained flyweight class _Icecream_ for sharing data regarding ice-cream flavours and a factory class _IcecreamFactory_ to create those flyweight objects. For memory conservation, the objects are recycled if the same object is instantiated twice. This is a simple example of flyweight implementation. ```javascript // flyweight class class Icecream { constructor(flavour, price) { this.flavour = flavour; this.price = price; } } // factory for flyweight objects class IcecreamFactory { constructor() { this._icecreams = []; } createIcecream(flavour, price) { let icecream = this.getIcecream(flavour); if (icecream) { return icecream; } else { const newIcecream = new Icecream(flavour, price); this._icecreams.push(newIcecream); return newIcecream; } } getIcecream(flavour) { return this._icecreams.find(icecream => icecream.flavour === flavour); } } // usage const factory = new IcecreamFactory(); const chocoVanilla = factory.createIcecream("chocolate and vanilla", 15); const vanillaChoco = factory.createIcecream("chocolate and vanilla", 15); // reference to the same object console.log(chocoVanilla === vanillaChoco); // true ``` ### Proxy Pattern This is a structural design pattern that behaves exactly as its name suggests. It acts as a surrogate or placeholder for another object to control access to it. It is usually used in situations where a target object is under constraints and may not be able to handle all its responsibility efficiently. A proxy, in this case, usually provides the same interface to the client and adds a level of indirection to support controlled access to the target object to avoid undue pressure on it. The proxy pattern can be very useful when working with network request heavy applications to avoid unnecessary or redundant network requests. In this example, we will use two new ES6 features [Proxy](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy) and [Reflect](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Reflect). A Proxy object is used to define custom behaviour for fundamental operations of a JavaScript object (remember, function and arrays are also object in JavaScript). It is a constructor method that can be used to create a _Proxy_ object. It accepts a _target_ object that is to be proxied and a _handler_ object that will define the necessary customization. The handler object allows defining some trap functions like _get_, _set_, _has_, _apply_, etc. that are used to add custom behaviour attached to their usage. _Reflect_, on the other hand, is a built-in object that provides similar methods that are supported by the handler object of Proxy as static methods on itself. It is not a constructor, it's static methods are used for interceptable JavaScript operations. Now, we create a function that can be thought of as a network request. We named it as *networkFetch*. It accepts a URL and responds accordingly. We want to implement a proxy where we only get the response from the network if it is not available in our cache otherwise we just return a response from the cache. The _cache_ global variable will store our cached responses. We create a proxy named _proxiedNetworkFetch_ with our original _networkFetch_ as the _target_ and use apply method in our _handler_ object to proxy the function invocation. The apply method gets passed on the _target_ object itself, this value as *thisArg* and the arguments passed to it in an array-like structure _args_. We check if the passed url argument is in the cache, if it exists in the cache we return the response from there, never invoking the original target function. If it does not, then we use the _Reflect.apply_ method to invoke the _target_ function with _thisArg_ (although it's not of any significance in our case here) and the arguments it was passed. ```javascript // Target function networkFetch(url) { return `${url} - Response from network`; } // Proxy // ES6 Proxy API = new Proxy(target, handler); const cache = []; const proxiedNetworkFetch = new Proxy(networkFetch, { apply(target, thisArg, args) { const urlParam = args[0]; if (cache.includes(urlParam)) { return `${urlParam} - Response from cache`; } else { cache.push(urlParam); return Reflect.apply(target, thisArg, args); } }, }); // usage console.log(proxiedNetworkFetch("dogPic.jpg")); // 'dogPic.jpg - Response from network' console.log(proxiedNetworkFetch("dogPic.jpg")); // 'dogPic.jpg - Response from cache' ``` ## Behavioural Pattern ### Chain of Responsibility Pattern This is a behavioural design pattern that provides a chain of loosely coupled objects. Each of these objects can choose to act on or handle the request of the client. A good example of the chain of responsibility pattern is the event bubbling in DOM in which an event propagates through a series of nested DOM elements, one of which may have an “event listener” attached to listen and act on the event. In this example, we create a class _CumulativeSum_ which can be instantiated with an optional _initialValue_. It has a method _add_ that adds the passed value to the _sum_ attribute of the object and returns the _object_ itself to allow chaining of _add_ method calls. This is a common pattern that can be seen in jQuery as well where almost any method call on a jQuery object returns a jQuery object so that method calls can be chained together. ```javascript class CumulativeSum { constructor(intialValue = 0) { this.sum = intialValue; } add(value) { this.sum += value; return this; } } // usage const sum1 = new CumulativeSum(); console.log(sum1.add(10).add(2).add(50).sum); // 62 const sum2 = new CumulativeSum(10); console.log(sum2.add(10).add(20).add(5).sum); // 45 ``` ### Command Pattern This is a behavioural design pattern that aims to encapsulate actions or operations as objects. This pattern allows loose coupling of systems and classes by separating the objects that request an operation or invoke a method from the ones that execute or process the actual implementation. The clipboard interaction API resembles the command pattern somewhat. If you are a Redux user, you have already come across the Command pattern. The actions, that allow the awesome time-travel debugging feature, are nothing but encapsulated operations that can be tracked to redo or undo operations. Hence, time-travelling made possible. In this example, we have a class _SpecialMath_ that has multiple methods and a _Command_ class that encapsulates commands that are to be executed on its subject i.e. an object of the _SpecialMath_ class. The _Command_ class also keeps track of all the commands executed which can be used to extend its functionality to include undo and redo type operations. ```javascript class SpecialMath { constructor(num) { this._num = num; } square() { return this._num ** 2; } cube() { return this._num ** 3; } squareRoot() { return Math.sqrt(this._num); } } class Command { constructor(subject) { this._subject = subject; this.commandsExecuted = []; } execute(command) { this.commandsExecuted.push(command); return this._subject[command](); } } // usage const x = new Command(new SpecialMath(5)); x.execute("square"); x.execute("cube"); console.log(x.commandsExecuted); // ['square', 'cube'] ``` ### Iterator Pattern It is a behavioural design pattern that provides a way to access the elements of an aggregate object sequentially without exposing its underlying representation. Iterators have a special kind of behaviour where we step through an ordered set of values one at a time by calling _next()_ until we reach the end. The introduction of Iterator and Generators in ES6 made the implementation of iterator pattern extremely straightforward. We have two examples below, first one _IteratorClass_ uses Iterator spec while the other one _iteratorUsingGenerator_ uses Generator functions. The *Symbol.iterator* ( *Symbol* - a new kind of primitive data type) is used to specify the default iterator for an object. It is must be defined for a collection to be able to use *for...of* looping construct. In the first example, we define the constructor to store some collection of data and then define _Symbol.iterator_ which returns an object with _next_ method for iteration. For the second case, we define a generator function passing it an array of data and return its elements iteratively using _next_ and _yield_. A generator function is a special type of function that works as a factory for iterators and can explicitly maintain its own internal state and yield values iteratively. It can pause and resume its own execution cycle. ```javascript // using Iterator class IteratorClass { constructor(data) { this.index = 0; this.data = data; } [Symbol.iterator]() { return { next: () => { if (this.index < this.data.length) { return { value: this.data[this.index++], done: false }; } else { this.index = 0; // to reset iteration status return { done: true }; } }, }; } } // using Generator function* iteratorUsingGenerator(collection) { var nextIndex = 0; while (nextIndex < collection.length) { yield collection[nextIndex++]; } } // usage const gen = iteratorUsingGenerator(["Hi", "Hello", "Bye"]); console.log(gen.next().value); // 'Hi' console.log(gen.next().value); // 'Hello' console.log(gen.next().value); // 'Bye' ``` ### Mediator Pattern It is a behavioural design pattern that encapsulates how a set of object interact with each other. It provides the central authority over a group of objects by promoting loose coupling by keeping objects from referring to each other explicitly. In this example, we have _TrafficTower_ as Mediator that controls the way _Airplane_ objects interact with each other. All the _Airplane_ objects register themselves with a _TrafficTower_ object and it is the mediator class object that handles how an _Airplane_ object receives coordinates data of all the other _Airplane_ objects. ```javascript class TrafficTower { constructor() { this._airplanes = []; } register(airplane) { this._airplanes.push(airplane); airplane.register(this); } requestCoordinates(airplane) { return this._airplanes.filter(plane => airplane !== plane).map(plane => plane.coordinates); } } class Airplane { constructor(coordinates) { this.coordinates = coordinates; this.trafficTower = null; } register(trafficTower) { this.trafficTower = trafficTower; } requestCoordinates() { if (this.trafficTower) return this.trafficTower.requestCoordinates(this); return null; } } // usage const tower = new TrafficTower(); const airplanes = [new Airplane(10), new Airplane(20), new Airplane(30)]; airplanes.forEach(airplane => { tower.register(airplane); }); console.log(airplanes.map(airplane => airplane.requestCoordinates())); // [[20, 30], [10, 30], [10, 20]] ``` ### Observer Pattern It is a crucial behavioural design pattern that defines one-to-many dependencies between objects so that when one object (publisher) changes its state, all the other dependent objects (subscribers) are notified and updated automatically. This is also called PubSub (Publisher/Subscribers) or Event Dispatcher/Listeners Pattern. The Publisher is sometimes called Subject and the Subscribers are sometimes called Observers. Chances are you are already somewhat familiar with this pattern if you have used addEventListener or jQuery’s on to write event handling code. It has its influences in Reactive Programming (think RxJS) as well. In the example, we create a simple _Subject_ class that has methods to add and remove objects of _Observer_ class from subscriber collection. Also, a _fire_ method to propagate any changes in the _Subject_ class object to the subscribed Observers. The _Observer_ class, on the other hand, has its internal state and a method to update its internal state based on the change propagated from the _Subject_ it has subscribed to. ```javascript class Subject { constructor() { this._observers = []; } subscribe(observer) { this._observers.push(observer); } unsubscribe(observer) { this._observers = this._observers.filter(obs => observer !== obs); } fire(change) { this._observers.forEach(observer => { observer.update(change); }); } } class Observer { constructor(state) { this.state = state; this.initialState = state; } update(change) { let state = this.state; switch (change) { case "INC": this.state = ++state; break; case "DEC": this.state = --state; break; default: this.state = this.initialState; } } } // usage const sub = new Subject(); const obs1 = new Observer(1); const obs2 = new Observer(19); sub.subscribe(obs1); sub.subscribe(obs2); sub.fire("INC"); console.log(obs1.state); // 2 console.log(obs2.state); // 20 ``` ### State Pattern It is a behavioural design pattern that allows an object to alter its behaviour based on changes to its internal state. The object returned by a State pattern class seems to change its class. It provides state-specific logic to a limited set of objects in which each object type represents a particular state. We will take a simple example of a traffic light to understand this pattern. The _TrafficLight_ class changes the object it returns based on its internal state which is an object of _Red_, _Yellow_ or _Green_ class. ```javascript class TrafficLight { constructor() { this.states = [new GreenLight(), new RedLight(), new YellowLight()]; this.current = this.states[0]; } change() { const totalStates = this.states.length; let currentIndex = this.states.findIndex(light => light === this.current); if (currentIndex + 1 < totalStates) this.current = this.states[currentIndex + 1]; else this.current = this.states[0]; } sign() { return this.current.sign(); } } class Light { constructor(light) { this.light = light; } } class RedLight extends Light { constructor() { super("red"); } sign() { return "STOP"; } } class YellowLight extends Light { constructor() { super("yellow"); } sign() { return "STEADY"; } } class GreenLight extends Light { constructor() { super("green"); } sign() { return "GO"; } } // usage const trafficLight = new TrafficLight(); console.log(trafficLight.sign()); // 'GO' trafficLight.change(); console.log(trafficLight.sign()); // 'STOP' trafficLight.change(); console.log(trafficLight.sign()); // 'STEADY' trafficLight.change(); console.log(trafficLight.sign()); // 'GO' trafficLight.change(); console.log(trafficLight.sign()); // 'STOP' ``` ### Strategy Pattern It is a behavioural design pattern that allows encapsulation of alternative algorithms for a particular task. It defines a family of algorithms and encapsulates them in such a way that they are interchangeable at runtime without client interference or knowledge. In the example below, we create a class _Commute_ for encapsulating all the possible strategies for commuting to work. Then, we define three strategies namely _Bus_, _PersonalCar_ and _Taxi_. Using this pattern we can swap the implementation to use for the _travel_ method of the _Commute_ object at runtime. ```javascript // encapsulation class Commute { travel(transport) { return transport.travelTime(); } } class Vehicle { travelTime() { return this._timeTaken; } } // strategy 1 class Bus extends Vehicle { constructor() { super(); this._timeTaken = 10; } } // strategy 2 class Taxi extends Vehicle { constructor() { super(); this._timeTaken = 5; } } // strategy 3 class PersonalCar extends Vehicle { constructor() { super(); this._timeTaken = 3; } } // usage const commute = new Commute(); console.log(commute.travel(new Taxi())); // 5 console.log(commute.travel(new Bus())); // 10 ``` ### Template Pattern This is a behavioural design pattern is based on defining the skeleton of the algorithm or implementation of an operation, but deferring some steps to subclasses. It lets subclasses redefine certain steps of an algorithm without changing the algorithm’s outward structure. In this example, we have a Template class _Employee_ that implements _work_ method partially. It is for the subclasses to implement responsibilities method to make it work as a whole. We then create two subclasses _Developer_ and _Tester_ that extend the Template class and implement the required method to fill the implementation gap. ```javascript class Employee { constructor(name, salary) { this._name = name; this._salary = salary; } work() { return `${this._name} handles ${this.responsibilities() /* gap to be filled by subclass */}`; } getPaid() { return `${this._name} got paid ${this._salary}`; } } class Developer extends Employee { constructor(name, salary) { super(name, salary); } // details handled by subclass responsibilities() { return "application development"; } } class Tester extends Employee { constructor(name, salary) { super(name, salary); } // details handled by subclass responsibilities() { return "testing"; } } // usage const dev = new Developer("Nathan", 100000); console.log(dev.getPaid()); // 'Nathan got paid 100000' console.log(dev.work()); // 'Nathan handles application development' const tester = new Tester("Brian", 90000); console.log(tester.getPaid()); // 'Brian got paid 90000' console.log(tester.work()); // 'Brian handles testing' ``` ## Conclusion Design patterns are crucial to software engineering and can be very helpful in solving common problems. But, this is a very vast subject and it is simply not possible to include everything about them in a short blog post. Therefore, I made the choice to shortly and concisely talk only about the ones I think can be really handy in writing modern JavaScript. To dive deeper, I suggest you take a look at these books - 1. **[Design Patterns: Elements Of Reusable Object-Oriented Software](https://en.wikipedia.org/wiki/Design_Patterns) **by *Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides (Gang of Four)* 2. [**Learn JavaScript Design Patterns** ](https://addyosmani.com/resources/essentialjsdesignpatterns/book/)by _Addy Osmani_ 3. **[JavaScript Patterns](https://www.amazon.com/JavaScript-Patterns-Stoyan-Stefanov/dp/0596806752)** by _Stoyan Stefanov_ ]]> https://hungvn.com/blog/javascript-design-patterns https://hungvn.com/blog/javascript-design-patterns Tue, 08 Oct 2019 04:15:00 GMT <![CDATA[Cách viết CV tốt hơn cho Web Developer]]> https://hungvn.com/blog/cach-viet-cv-tot-hon-cho-web-developer https://hungvn.com/blog/cach-viet-cv-tot-hon-cho-web-developer Thu, 12 Sep 2019 21:42:00 GMT <![CDATA[Tìm hiểu về npm-link]]> https://hungvn.com/blog/tim-hieu-ve-npm-link https://hungvn.com/blog/tim-hieu-ve-npm-link Fri, 06 Sep 2019 22:10:00 GMT <![CDATA[Giải thích chi tiết về Javascript Modules]]> https://hungvn.com/blog/giai-thich-chi-tiet-ve-javascript-modules https://hungvn.com/blog/giai-thich-chi-tiet-ve-javascript-modules Wed, 04 Sep 2019 19:20:00 GMT <![CDATA[CSS in JS trong dự án thực tế]]> Side note: Recently I’ve been a React developer and when I did the research I was focusing mainly on how I could utilize the technology in my projects, so therefore I will mostly focus on the ease of use in React. Ability to read JSX will help you to understand what the heck is going on. # CSS Modules Putting [CSS Modules](https://github.com/css-modules/css-modules) here can be a bit of a stretch, depending on how you define CSS in JS, because you write basically in CSS (with some cool additions). What’s change is the way of loading the styles into components. But they were the first, so treat it like a honorable mention on the list. Chances are that you probably seen CSS Modules somewhere. But let’s take a look at them (or, you know, you can always scroll to the next section). Let’s start with this simple example: ```js // styles.css .heading { color: gray; font-size: 1.5em; } .paragraph { font-size: 1.1em; } // component.js import React from 'react'; import styles from './styles.css'; const Article = () => { return (

Heading

Article's text

); }; ``` Okay, so as you can see, the CSS are still the same. You simply write them like you did for years. What changes is the way of loading them into your application. Now, while bundling, the CSS files are being parsed and turn into pure JS objects, that are easy to use inside code. Styles are imported explicitly and used like any other JS object, which is very cool from the semantic perspective. But that’s not where CSS Modules shine. ## Local Scope Having classnames parsed, CSS Modules is able to change the names of the output classnames into totally unique strings. This gives us local scope inside CSS. That’s huge! The generated output will look like this: ```html // output

Heading

Article's text

``` The unique classnames are awesome! Are the solution to everything! And are totally un-debuggable. But there’s a small fix for it: ```js // fix (in webpack.config.js) (...)&localIdentName=[path]_[name]_[local]_[hash:base64:5] // output

Heading

Article's text

``` Ah, much better! Now it’s clearly visible what styles come from what files. You can adjust the naming convention according to what’s suits you the most. Pros: - Pure CSS (no learning curve) - Some additional features - Local scoping - Nice semantics using JavaScript’s import statement - Easy debugging (with the right Webpack setting) Cons: - No more global styles, which is generally a good thing, but you need to invest some time to adjust to this approach - Additional Webpack (or other bundler) configuration ## SASS Modules / LESS Modules CSS Modules on their own bring some additional functionalities, like _composition_ or _global pseudo class_. But if you’re missing some of the cool stuff like _mixins_ or _variables_ you can always add [SASS](https://sass-lang.com/) or [LESS](http://lesscss.org/). Just add the respective loader to your webpack config. Now, you have a very powerful duo, fully pack with features and possibilities. Pros: - All of the CSS Modules features - All of the SASS/LESS features (!) Cons: - Similar as CSS Modules > For a long time I thought that using SASS with CSS Modules was the ultimate solution. Then, the other solutions came along. # Styled Components Although one can argue, that CSS Modules were the first CSS in JS, [Styled Components](https://github.com/styled-components/styled-components) were the one that started the whole avalanche of such solutions recently. Styled Components utilize tagged template strings and allow to put your CSS code inside JavaScript directly. You can still split it into 2 files, to get that feeling of logic and styles being separate. But it’s optional. So, how our example would look like in Styled Components? Let’s see: ```js // component.js import React from "react"; import styled from "styled-components"; const Heading = styled.h1` color: gray; font-size: 1.5em; `; const Paragraph = styled.p` font-size: 1.1em; `; const Article = () => { return (
Heading Article's text
); }; ``` It’s pretty straightforward. Just use tags provided by the library to render a component that you would like having styling added to inside the template string literal. As simple as that. ## Extending styles Let’s say, we would like to extend the styling of existing component and add some more. That’s very simple: ```js const SexyParagraph = styled(Paragraph)` text-decoration: underline; color: green; `; ``` Things get a little bit complicated, when you would like to add additional handlers to styled components. Let’s take a simple button and add a onClickhandler to it. Sadly, we can’t do it in one step. What we need to do, is basically create 2 components — one with logic, and one that brings styles: ```js // button.js import React from "react"; import styled from "styled-components"; const Button = ({ children }) => ; const StyledButton = styled(Button)` border: solid 2px green; `; // usage: My fancy button; ``` So this makes things a bit excessive. Every time you would like to add some logic to a component, you will end up with 2 components. While it is kinda in style of [HoC](https://reactjs.org/docs/higher-order-components.html), but it just doesn’t go well with other HoC, so it can’t be used with cool HoC helpers like [recompose](https://github.com/acdlite/recompose). I must admit, that I’m a big fan of HoC and not being able to use Styled Components in that fashion just misses the mark for me. Creating a separate component every time that a styling is needed seems like a good idea, but when I used such approach I suddenly missed the ability to just write a bit more complicated markup. So, in theory this approach is very appealing, but practice shows that sometimes you need to produce much more small components. This can lead to less readable code. Because if I can do something in 20 lines of JSX, I would prefer that over creating 10 small components. ## Dynamic Styles One of cool features of Styled Components, that was just not possible in CSS Modules, is the ability to read components’ props and generate the appropriate styling. Let’s assume that we have 2 props: important and width. They can be accessed inside the style in such manner: ```js const CustomButton = styled.button` color: ${props => props.important ? 'red' : 'black'}; width: ${props => props.width}px; } My button ``` Dynamic styles are a pretty cool feature. Although my concern is that it can lead to more logic-heavy styles. Depending on the project, that can be a double edged sword. ## Theming Another great feature is theme support. That’s right, you can simply define your theme or color palette (as a simple object) and access its properties whenever you like. But what if I could tell you, that you can change themes on the fly? Yup, it’s possible. Let’s see it in action: ```js // button.js const ThemableButton = styled.button` color: ${props => props.theme.textColor}; border: ${props => props.theme.borderColor}; `; // themes.js const theme = { textColor: "red", borderColor: "gray", }; const otherTheme = { ...theme, textColor: "green", }; // in app.js
Red button
I'm green! ; ``` The usage of ThemeProvider allows to add a theme (via property) to all components inside. If you’re in need of adding another theme, just place your components inside another ThemeProvider and enter a new theme property. As simple as that. The question arises, how many times you were in need of a theming that can be changed? I didn’t see much of such projects recently, but if you need it, it’s there. ## Debugging Now, from debugging perspective, the generated output is fairly good. The StyledButton from the example above will not render a component inside a component, which is good. At the very beginning only the class names are unreadable (such as in case of CSS Modules). But there’s a Babel [plugin for that](https://github.com/styled-components/babel-plugin-styled-components), and you’re good to go. Pros: - Easy to use, easy to understand. - Local scope - Dynamic styling based on props - Theming - Easy debugging (with babel plugin) - Works with React Native (although I didn’t test that) Cons: - Excessive creation of components (2 components each time handler or lifecycle method needs to be used) - Possible too much of too small components - Syntax highlighting needs an external plugin # Glamorous [Glamorous](https://glamorous.rocks/) takes inspiration from Styled Components and aims to change a bit the way you can use it. Notably, the biggest difference is the departure from tagged template strings in favor of plain objects. You still would use it in a similar way, but replacing string with objects. Just take a look: ```js import glamorous from 'glamorous'; const Heading = glamorous.h1({ fontSize: '2.4em', marginTop: 10, color: '#CC3A4B' }) // rendering render() { return (My Heading); } ``` To use media queries, pseudo classes and pseudo elements, simply create nested objects with selectors as their names, like so: ```js import glamorous from 'glamorous'; const Heading = glamorous.h1({ fontSize: '2.4em', marginTop: 10, color: '#CC3A4B', ':hover': { color: 'yellow' }, '@media only screen and (max-width: 500px)': { marginTop: 5, fontSize: '1.8em' } }); // rendering render() { return (My Heading); } ``` ## Animations Well, this is something that does not come with Styled Components. Glamorous has a build in helper for creating CSS animations. That’s something really cool. Nowadays fluid animations and transitions are important parts of good UX and everything that improves creation of those effects is more then welcome. ```js const AnimatedDiv = glamorous.div(props => { const bounce = glamor.css.keyframes({ "0%": { transform: `scale(1.01)` }, "100%": { transform: `scale(0.99)` }, }); return { animation: `${bounce} 0.2s infinite alternate`, }; }); ``` Okay, so it’s not a game changing functionality. But it allows to create unique keyframes animations in a simple manner. ## Dynamic Styling Just like in Styled Components, Glamorous has the ability to use dynamic styling. In my opinion, it does it in much clearer way. Because we work with objects, not with string literals, conditional operations are much more natural. Simply, instead of object, pass a function that receives props and returns a valid object. ```js const CustomButton = glamorous.button((props) => ({ color: props.important ? 'red' : 'black', width: props.width }); My button ``` Obviously, having the ability to pass a function into the component factory gives you much more flexibility, but allows to create even more logic-heavy styles. Double edged sword once again. ## Theming and reusing styles Theming for Glamorous looks like it was taken directly from Styled Components, just define a theme object and pass it to your components. They will have access to it via props.theme. Simple as that. Glamorous allows also to reuse and extend existing styles. For that you can use the glamorous object as a function, pass the component and then styles to override the existing ones. ```js const GreatButton = glamorous(CustomButton)({ padding: 20, }); ``` Moreover, it allows you to copy existing styles to a different tag via withComponent method: ```js const GreatLink = GreatButton.withComponent("a"); ``` ## Not HoC compliant When it comes to overall usage, Glamorous suffers from the same drawback of not really being in compliant with HoC approach. So, once again, to build a more advanced component with styling, you will need to create 2 components. Let’s revisit the example from Styled Components: ```js // button.js import React from "react"; import glamorous from "glamorous"; const Button = ({ children }) => ; const StyledButton = glamorous(Button)({ border: "solid 2px green", }); // usage: My fancy button; ``` So this comes with the same issue: too many small components. ## Debugging When it comes to debugging, Glamorous on it’s own is not very readable in the DevTools. But, obviously, there’s a [plugin](https://github.com/bernard-lin/babel-plugin-glamorous-displayname) for that. Pros: - ...styledComponents.pros - Object notation instead template literals - Keyframes helper Cons: - (Potentially) excessive components creation # Styletron When it comes to [Styletron](https://github.com/rtsao/styletron), I’m probably quite biased. I have become involved in a project using it and it quickly pushed me to do research on other similar solutions to migrate away to. I felt so limited and distracted by it so I couldn’t just bare with styling anymore. I get the impression, that Styletron does a lot of things similar to Glamorous, but fails to deliver really usable in real-life solution. Let’s start with basics: ```js import { styled } from 'styletron-react'; const Heading = styled('h1', { fontSize: '2.4em', marginTop: 10, color: '#CC3A4B' }); // rendering render() { return (My Heading); } ``` When it comes to simple usage, it’s almost the same as in Glamorous. ## Themes, dynamic styles and extending styles Styletron provides ways to extend existing styles, or to build dynamic styles. It also supports theming in a very similar fashion, as we have seen previously. Let’s see all of those features in action together: ```js import { styled } from 'styletron-react'; import ThemeProvider from './ThemeProvider'; import Button from './GenericButton'; const FancyButton = styled(GenericButton, ({ theme, size }) => { return { color: theme.button.color, background: theme.button.background, height: (size === 'big') ? '30px', '20px', width: (size === 'big') ? '100px', '60px' }; }); const MyTheme = { button: { color: '#ee3ae4', background: '#323c4d' } } // rendering Click me ``` Similar to previous solutions, Styletron does not allow to create more lifecycle-heavy components with styles. Instead, you need to create 2 components, one with logic, and one with styles: ```js class MyComponent extends React.Component { componendDidMount() { // some awesome logic here } render() { return
My Component
; } } const StyledComponent = styled(MyComponent, { /* styles */ }); ``` So, let’s see, what Styletron renders in HTML… ## Generated output The output for the example above will be something like: ```html
My Component
``` And two issues can be seen here. Firstly, that the rendered code is totally not debuggable. You can’t really deduce from which component any of the styles really come. Or even what component you’re looking at. Switching to React DevTools doesn’t help either. All you gonna see is that it’s ``. That’s really helpful. Oh, and each style property gets it’s own, unique class name. Imagine having a well styled component with over 30 properties. Yeah… ```html
Hi
``` And what’s even worse, there is **no debugging plugin** for it! Moreover, imagine that the example would have 10 nested components, one inside another. Could you tell the number of generated divs? Yup, 20. Because every time you need to have more advanced component, Styletron will need to add additional wrapper for styling purposes. That’s something I like to call a _Wrapper-iada_. And it’s no good. ## Other issues Styletron has a bug that’s basically prevents you from using dynamic tags (so the tags used depending on the props). Let me explain: ```js const headers = { h1: 'h1', h2: 'h2', h3: 'h3 } const DynamicHeader = ({ size, children }) => { const Element = headers[size]; return ( {children} ); }; ``` Now, if I would like to add styling to my DynamicHeader, I would go with: ```js const StyledHeader = styled(DynamicHeader, { /\* new styles \*/ }); ``` None of the new styles won’t be applied. Why? I don’t have an idea, but it’s not good. ## No animations That’s right, Styletron does not support css keyframes! Obviously, you can use animation like the following: ```js const BouncyDiv = styled("div", { animation: "bounce 1s", }); ``` And it will work. But you can’t define the keyframes of bounce using Styletron. If you would really like to somehow define keyframes, you need to use good, ol’ CSS. That’s a terrible solution. Let’s sum up: Pros: - Looks similar to Glamorous - Local scope - Theming, dynamic styles, extending styles Cons: - Undebuggable (!) - Wrapper-iada - No dynamic elements - No keyframes support # Styled JSX Next CSS-in-JS solution that I researched was [Styled JSX](https://github.com/zeit/styled-jsx). At the very beginning it looks different to the solutions above, it kinda looks more inline with JSX approach and I find it a bit more appealing. The basic example looks like this: ```js const MyComponent = () => { return (

Heading

Paragraph 1

Paragraph 2

); }; ``` Styled JSX uses template literals inside of a ` ); }; ``` What I like here, is that I can write styles and apply them to components with lifecycle methods. Another thing to like is that Styled JSX integrates nicely with React’s idea of rendering components. That was not possible with any of the previous libraries. But here I can decide when I should split component into smaller ones. That kind of freedom is something I really appreciate. Artificial code splitting forced by previous solutions does not always end up in a very readable code. ## Drawbacks I must say I really like this approach, but the drawbacks just kill it for me. The problems start when you want to extend existing styling. Or when you would like to alter the default styling of a child component. There is no easy way of doing such things. While in Glamorous all you needed was to call glamorous(DefaultButton)(newStyles), in Styled JSX you need to come up with your own approach to reusing existing styling. So as I said before, this kills the Styled JSX for me. Pros: - More inline with JSX approach - Doesn’t force artificial code splitting - Easy to understand - Local scope - Dynamic Styles, Themes support Cons: - Reusability of styles is hard if non-existent # JSS The last but not least — [JSS](http://cssinjs.org/). At first glance, JSS looks very similar to Glamorous. You create objects literals with styles, you apply them to components. But it also successfully adds the ability to write couple styles for multiple tags inside one component. ```js import withStyles from 'react-jss'; const styles = { heading: { fontSize: '1.6em' }, paragraph: { lineHeight: '1.4em' } }; const MyComponent ({ classes }) => { return (

Heading

Paragraph 1

); }; export default withStyles(styles)(MyComponent); ``` First what I have to admit, and what really got me excited about JSS is that finally, it’s a HoC! You pass a object with different class names to it, and the HoC will produce a wrapper that adds a classes property containing generated, unique class names. In a way, it brings the functionality of both Styled JSX and Glamorous neatly together. That’s off to a good start. ## Theming and dynamic styles Just like abovementioned solutions, JSS supports both themes and dynamic styles. It comes with build in ThemeProvider which is always a neat solution. ```js // component.js import withStyles from "react-jss"; // app.js import { ThemeProvider } from "react-jss"; const styles = theme => ({ wrapper: { fontSize: "1.4em", color: theme.primaryColor, height: props => props.size, }, }); const Component = ({ classes }) => { return
My fancy component
; }; export default withStyles(styles)(Component); const theme = { primaryColor: "#51abff", }; // rendering ; ``` The theme object is available when instead of styles object, you create a function that returns the styles object. Component’s props are available in a slightly more annoying way, as a argument for function returning value of each property. ## Reusing and overriding styles When it comes to extending styles, well, JSS does not provide any simple way of doing so. But, then again, they are all JS object, so we can export styles and extend them on our own using the spread operator. ```js // component.js export const styles = { wrapper: { // original styles }, }; const Component = () => { // Component's logic }; export default withStyles(styles)(Component); // fancy-component.js import { styles as defaultStyles } from './component'; export const styles = { wrapper: { ...defaultStyles.wrapper, color: 'red', }, }; ``` A bit of work, but it’s very explicit. No under-the-hood magic. There is a [extend-plugin](http://cssinjs.org/jss-extend), however its usage is very similar to the spread operator. JSS has a neat feature that is not available in other libraries, and that’s ability to override default styles of the component. You can call the withStyles HoC again and again on component, overriding it’s default styles, like so: ```js // componentA.js const styles = { wrapper: { color: 'red', fontSize: '1.4em' } paragraph: { fontSize: '1.2em', color: 'gray' } }; const ComponentA = () => { // ... }; export default withStyles(styles)(ComponentA); // componentB.js const stylesA = { wrapper: { color: 'blue' } }; const StyledA = withStyles(stylesA)(ComponentA); const ComponentB = () => { return (
); }; ``` Because withStyles performs a shallow merge of the style objects, the StyledA component will contain the original styles for paragraph, but it will have only the newest styles for wrapper. This means that it will have only the color: blue property but it will lose the fontSize: 1.4em property. You can obviously combine the two methods to override styles with extending the existing ones. However, since it is a HoC, you can write your own HoC that does just that. ## Other features JSS comes with variety of [plugins](http://cssinjs.org/plugins). You can use them, for example, to write styles inside template literals, if that’s your thing, or to extend existing classes via class names or objects. ## Debugging When it comes to debugging, JSS is very user-friendly. At the very beginning, it renders human-friendly class names, so you can quickly find your way around the generated HTML markup. It also does not change the generated components’ names, as it only works on the className property, which is quite nice. Pros: - Local Scope - Theming, dynamic styles - No artificial code splitting - Overriding default styles (!) - works as a HoC Cons - No native style extending solution (but you can work around this) # Conclusion It’s time to sum up. Is there a clear winner? In my opinion, yes. JSS takes the top spot. It gives me all of the features of other CSS-in-JS solutions and doesn’t forces me to create super-small components each time I need styling for a div. In addition to that, it works as a HoC, so if I don’t like the default behavior (like when overriding styles) I can always create my own HoC that wraps it and changes the behavior. It’s simple to use and flexible. And at the end of the day, it’s the solution that devs from the [Material UI](http://www.material-ui.com/#/) are [gonna use](https://material-ui-next.com/customization/css-in-js). For me, that’s a hell of a recommendation for JSS. > As I already mentioned, I thought that SASS + CSS Modules were the future. But now I can clearly see, that CSS in JS is at least as good, with JSS being my favorite. It’s really usable and works great in the real-life development. My personal pick after doing the research: JSS. ]]> https://hungvn.com/blog/css-in-js-trong-du-an-thuc-te https://hungvn.com/blog/css-in-js-trong-du-an-thuc-te Sun, 01 Sep 2019 12:45:00 GMT <![CDATA[JavaScript naming conventions: nên và không nên]]> _Most of these conventions are not for you today, but instead, for you and the people reading your code tomorrow._ ![](1_Xwatja8ddZXjumrmLFTjKw.png) ## References and continued learning 1. [“Clean Code” by Robert C. Martin](https://www.amazon.com/gp/product/0132350882/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=0132350882&linkCode=as2&tag=brandonwoz-20&linkId=8af093cb2b8d9a87993f285341ff015a) — _A great read for all languages. It goes beyond naming conventions and proposes the entire structure of your program. The examples are in Java, but the principles apply to JavaScript._ 2. [“Clean Code JavaScript” by Ryan Mcdermott](https://github.com/ryanmcdermott/clean-code-javascript) — _The above book, but remade for JavaScript. It is available online and is free._ 3. [Airbnb JavaScript Style Guide](https://github.com/airbnb/javascript) — _Possibly the most comprehensive style guide for JavaScript. It contains not only the what, but also the why. (If you’re on a small device, you may need to click on “view all readme” to see the entire document)._ 4. [W3Schools JavaScript Style Guide](https://www.w3schools.com/js/js_conventions.asp) — A s*hort and concise guide.* 5. [Google’s ES6 Style Guide](https://google.github.io/styleguide/jsguide.html) — _Google’s style guide for JavaScript._ Thanks for reading! ]]> https://hungvn.com/blog/javascript-naming-conventions-nen-va-khong-nen https://hungvn.com/blog/javascript-naming-conventions-nen-va-khong-nen Fri, 30 Aug 2019 18:15:00 GMT <![CDATA[Original DOM vs Shadow DOM vs Virtual DOM]]> {' '} -> document node {' '} -> element node - head HTML DOM -> text node -> element node - title -> element node - body ``` - **DOM APIs** _HTML DOM cung cấp các APIs để duyệt và chỉnh sửa các node._ _Ví dụ cụ thể về APIs có thể kể tới như getElementById() dùng để truy xuất một phần tử theo id cũng hay removeChild() dùng để loại bỏ một phần tử con dựa vào phần tử cha của nó._ ## Shadow DOM ### Overview Mozilla đã tóm tắt 3 đặc điểm cơ bản về **Shadow DOM**: > Shadow DOM can be thought of as: > > - Isolated DOM > - A “lite” version of the DOM > - NOT of a full standalone document Sở dĩ nói như vậy là do các stylesheet hay javascript từ bên ngoài **không-thể-tác-động** vào trong Shadow DOM được và ngược lại. Ví dụ như ta có thẻ ` https://hungvn.com/blog/original-dom-vs-shadow-dom-vs-virtual-dom https://hungvn.com/blog/original-dom-vs-shadow-dom-vs-virtual-dom Tue, 20 Aug 2019 10:40:00 GMT <![CDATA[Tìm hiểu về HTTP Status Code]]> Status-Code Reason-Phrase CRLF Ví dụ : HTTP/1.1 404 Not Found HTTP-Version : HTTP/1.1 Status-Code : 404 Reason-Phrase : Not Found ``` Status code (Mã hóa trạng thái thường được gọi là mã trạng thái) là một số nguyên 3 ký tự, trong đó ký tự đầu tiên của Status-Code định nghĩa loại Response và hai ký tự cuối không có bất cứ vai trò phân loại nào. Có 5 giá trị của ký tự đầu tiên: - 1xx: Information (Thông tin): Khi nhận được những mã như vậy tức là request đã được server tiếp nhận và quá trình xử lý request đang được tiếp tục. - 2xx: Success (Thành công): Khi nhận được những mã như vậy tức là request đã được server tiếp nhận, hiểu và xử lý thành công - 3xx: Redirection (Chuyển hướng): Mã trạng thái này cho biết client cần có thêm action để hoàn thành request - 4xx: Client Error (Lỗi Client): Nó nghĩa là request chứa cú pháp không chính xác hoặc không được thực hiện. - 5xx: Server Error (Lỗi Server): Nó nghĩa là Server thất bại với việc thực hiện một request nhìn như có vẻ khả thi. Status-Code HTTP là có thể co giãn và ứng dụng HTTP không được yêu cầu để hiểu ý nghĩa của tất cả các mã trạng thái được đăng ký. Một danh sách của tất cả các mã trạng thái đã được cung cấp trong một chương riêng biệt cho bạn tham khảo. ### I. 1xx Infomation (Thông tin) - 100 Continue: Chỉ một phần của Request được nhận bởi Server (có thể là header và Client cần gửi tiếp body), nhưng miễn là nó không bị loại bỏ, Client nên tiếp tục với Request. - 101 Switching Protocols: Requester đã hỏi Server về việc thanh đổi Protocol và Server đã chấp nhận điều đó ### II. 2xx Success (Thành công) - 200 OK: Request đã được tiếp nhận và xử lý thành công. Các Response thực tế trả về sẽ phụ thuộc vào phương thức HTTP của Request. Trong một GET Request, Response sẽ chứa một thực thể tương ứng với các tài nguyên yêu cầu, trong một POST Request, Response sẽ chứa một thực thể mô tả hoặc chứa các kết quả của các action. - 201 Created: Request được chấp nhận cho xử lý, nhưng việc xử lý chưa hoàn thành. - 203 Non-authoritative Information (Xuất hiện từ HTTP/1.1): Server là nơi chuyển đổi proxy (ví dụ một Web accelerator) đã nhận được 200 OK nhưng nó trả về một phiên bản thay đổi (có thể là header) của Response nguyên gốc. - 204 No Content: Server đã xử lý thành công request nhưng không trả về bất cứ content nào. - 205 Reset Content: Server đã xử lý thành công request nhưng không trả về bất cứ content nào. Không giống với 204 No Content Response này yêu cầu phía Client phải thiết lập lại document view. - 206 Partial Content: Server chỉ trả về một phần của resouce(dạng byte) do một range header được gửi bởi phía Client. Các Range Header được sửa dụng bởi Client để cho phép nối lại các phần của file download bị dán đoạn hoặc chia thành nhiều luồng download. ### III. 3xx Redirection (Sự chuyển hướng lại) - 300 Multiple Choices: Một danh sách các link. Người sử dụng có thể chọn một link và tới vị trí đó. Tối đa 5 địa chỉ. Ví dụ: List các file video với format khác nhau - 301 Moved Permanently: Request hiện tại và các request sau được yêu cầu di chuyển tới một URI mới. - 302 Found: Đây là một ví dụ cho thấy sự mâu thuẫn giữa thực tiễn và quy chuẩn. Ở phiên bản HTTP/1.0 nó có nghĩa là yêu cầu Client chuyển hướng đến một URL tạm thời (tương tự như là 301 Moved Permanently) nhưng phần lớn các browser lại thực hiện nó với ý nghĩa của 303 See Other(sẽ nói sau đây). Do đó từ phiên bản HTTP/1.1 có thêm hai mã 303 và 307 để phân biệt rõ hành vi, nhưng một số ứng dụng web và framework vẫn sử dụng 302 như thể là 303. - 303 See Other (Xuất hiện từ HTTP/1.1): Response trả về của Request có thể tìm thấy ở một URL khác bằng cách sử dụng phương thức GET. - 304 Not Modified: Đây là Status-Code tới một If-Modified-Since hoặc If-None-Match header, nơi mà URL không được chỉnh sửa từ ngày cụ thể. - 305 Use Proxy: Tài nguyên yêu cầu chỉ có sẵn thông qua một proxy, địa chỉ mà được cung cấp trong các Response. Nhiều HTTP Client (như Mozilla và Internet Explorer) không xử lý một cách chính xác phản ứng với mã trạng thái này, chủ yếu là vì các lý do an ninh. - 306 Switch Proxy: Mã này hiện không còn được sử dụng, ý nghĩa ban đầu của nó là "Các Request tiếp theo nên sử dụng các proxy được chỉ định". - 307 Temporary Redirect (xuất hiện từ HTTP/1.1): Trong trường hợp này, Request hiện tại cần được lặp lại một URI khác nhưng các Request trong tương lai vẫn sử dụng URI gốc. ### IV. 4xx: Client Error (Lỗi Client) ![](https://miro.medium.com/max/2400/1*8xtbzaB2Elv3AQx4GkV4oA.gif) - 400 Bad Request: Server không thể xử lý hoặc sẽ không xử lý các Request lỗi của phía client (ví dụ Request có cú pháp sai hoặc Request lừa đảo định tuyến ...) - 401 Unauthorized: Tương tự như 403 Forbidden nhưng được sử dụng khi yêu cầu xác thực là bắt buộc và đã không thành công. Các Response bắt buộc phải có thành phần WWW-Authenticate chứa các thách thức với tài nguyên được yêu cầu. Một số trang web vấn đề HTTP 401 khi một địa chỉ IP bị cấm từ các trang web (thường là các tên miền trang web) và địa chỉ cụ thể là từ chối quyền truy cập một trang web. - 402 Payment Required: Hiện tại mã này chưa được sử dụng và nó được dự trữ cho tương lai. Mục đích ban đầu là mã này có thể được sử dụng như là một phần của đề án tiền mặt hoặc micropayment kỹ thuật số, nhưng điều đó đã không xảy ra, và mã này thường không được sử dụng. Google API sử dụng Status-Code này nếu một nhà phát triển đặc biệt đã vượt quá giới hạn số lần yêu cầu. - 403 Forbidden: Request là hợp lệ nhưng server từ chối đáp ứng nó. Nó có nghĩa là trái phép, người dùng không có quyền cần thiết để tiếp cận với các tài nguyên. - 404 Not Found: Các tài nguyên hiện tại không được tìm thấy nhưng có thể có trong tương lai. Các request tiếp theo của Client được chấp nhận. - 405 Method Not Allowed: Request method không được hỗ trợ cho các tài nguyên được yêu cầu. Ví dụ Một GET request đến một POST resource, PUT Request gọi đến một tài nguyên chỉ đọc. - 406 Not Acceptable: Server chỉ có thể tạo một Response mà không được chấp nhận bởi Client. - 407 Proxy Authentication Required: Bạn phải xác nhận với một Server ủy quền trước khi Request này được phục vụ. - 408 Request Timeout: Request tốn thời gian dài hơn thời gian Server được chuẩn bị để đợi. - 409 Conflict: Request không thể được hoàn thành bởi vì sự xung đột, ví dụ như là xung đột giữa nhiều chỉnh sửa đồng thời. - 410 Gone: Các resource được yêu cầu không còn nữa và sẽ không có sẵn một lần nữa, khi gặp mã lỗi này Client không nên có gắng tìm kiếm các tài nguyên này ở những lần sau. - 411 Length Required: Content-Length không được xác định rõ. Server sẽ không chấp nhận Request nào không có nó. - 412 Precondition Failed: Server sẽ không đáp ứng một trong những điều kiện tiên quyết của Client trong Request. - 413 Payload Too Large: Server sẽ không chấp nhận yêu cầu, bởi vì đối tượng yêu cầu là quá rộng. Trước đây nó gọi là "Request Entity Too Large". - 414 URI Too Long: URI được cung cấp là quá dài để Server xử lý, thường là kết quả của quá nhiều dữ liệu được mã hóa như là một truy vấn chuỗi của một GET Request, trong trường hợp đó nó phải được chuyển đổi sang một POST Request. Trước đây được gọi là "Request-URI Too Long" - 415 Unsupported Media Type: Server sẽ không chấp nhận Request, bởi vì kiểu phương tiện không được hỗ trợ. Ví dụ khi Client upload một ảnh có định dạng image/svg+xml, nhưng server yêu cầu một định dạng khác. - 416 Range Not Satisfiable: Client yêu cầu một phần của tập tin nhưng server không thể cung cấp nó. Trước đây được gọi là "Requested Range Not Satisfiable" - 417 Expectation Failed: Máy chủ không thể đáp ứng các yêu cầu của trường Expect trong header. ### V. 5xx: Server Error (Lỗi Server) ![](https://miro.medium.com/max/1440/1*Y-BHUzdE1AhGNfuM-5-W6Q.png) - 500 Internal Server Error: Một thông báo chung chung, được đưa ra khi Server gặp phải một trường hợp bất ngờ, Message cụ thể là không phù hợp. - 501 Not Implemented: Server không công nhận các Request method hoặc không có khả năng xử lý nó. - 502 Bad Gateway: Server đã hoạt động như một gateway hoặc proxy và nhận được một Response không hợp lệ từ máy chủ nguồn. - 503 Service Unavailable: Server hiện tại không có sẵn (Quá tải hoặc được down để bảo trì). Nói chung đây chỉ là trạng thái tạm thời. - 504 Gateway Timeout: Server đã hoạt động như một gateway hoặc proxy và không nhận được một Response từ máy chủ nguồn. - 505 HTTP Version Not Supported: Server không hỗ trợ phiên bản “giao thức HTTP”. Trên đây là danh sách các Status-Code phổ biến nhất, ngoài ra còn nhiều các Status-Code tiêu chuẩn đã được nhưng nghĩa như : 418, 421, 506, 507, 508, 511 ... Cám ơn các bạn đã theo dõi. VI. Tài liệu tham khảo List of HTTP status codes (Wiki): [https://en.wikipedia.org/wiki/List_of_HTTP_status_codes](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes) ]]> https://hungvn.com/blog/tim-hieu-ve-http-status-code https://hungvn.com/blog/tim-hieu-ve-http-status-code Mon, 12 Aug 2019 18:45:00 GMT <![CDATA[React Hooks: Memoization]]> https://hungvn.com/blog/react-hooks-memoization https://hungvn.com/blog/react-hooks-memoization Mon, 05 Aug 2019 12:50:00 GMT <![CDATA[Bí Kíp Bạn Có Thể Dùng Khi Phạm Sai Lầm Với Git]]> " ``` ### Trường hợp muốn sửa lại commit từ lâu rồi ```git $ git rebase -i ==== # Sau lệnh này sẽ mở ra editor nên hãy sửa lại như sau rồi lưu lại # (trước khi sửa) các commit cũ từ trên xuống dưới pick aa11bbc commit message 1 pick b2c3c4d commit message 2 pick 4e56fgh commit message 3 ・・・ # (Sau khi sửa) Đổi commit cần sửa sang edit edit aa11bbc commit message 1 pick b2c3c4d commit message 2 pick 4e56fgh commit message 3 ・・・ ==== # Sau đó thì sửa tương tự $ git commit --amend -m "commit message" --author="user.name " # Trở lại như cũ $ git rebase --continue ``` ### (NGUY HIỂM) Viết lại toàn bộ lịch sử commit Khi muốn sửa các commit của người dùng (committer) nhất định thì có thể dùng cách sau để sửa Lịch sử commit sẽ bị thay đổi hoàn toàn ```git git filter-branch --commit-filter ' if [ "$GIT_COMMITTER_NAME" = "" ]; then GIT_COMMITTER_NAME=""; GIT_AUTHOR_NAME=""; GIT_COMMITTER_EMAIL=""; GIT_AUTHOR_EMAIL=""; git commit-tree "$@"; else git commit-tree "$@"; fi' HEAD ``` ## Sự cố ３: Khi đã lỡ tay commit một số file thừa nhưng sau khi nghĩ lại thì nên ignore thì hơn ### Trường hợp commit xoá Nếu có những phần thừa thì ta xoá đi rồi thêm vào ignore ```git # Đầu tiên là xoá các file đã commit khỏi repository $ git rm --cached # Sau đó là thêm vào gitignore $ echo '' >> .gitignore ``` ### Trường hợp muốn coi như là chưa từng có file đó Khi mà bạn muốn: "Hả, file nào cơ, là gì có file nào như thế ?" ```git # Trường hợp chỉ xoá khỏi lịch sử commit （để lại ở working tree） $ git filter-branch -f --index-filter 'git rm --cached -rf --ignore-unmatch ' HEAD # Trường hợp xoá khỏi lịch sử commit và cả ở working tree $ git filter-branch -f --index-filter 'git rm -rf --ignore-unmatch ' HEAD ``` ## Sự cố 4: Khi mà tên branh bạn đặt quá là "chuối" Nếu không ai nhìn thấy thì ta "bí mật" sửa lại tên branch thôi nào ! ```git $ git branch -m ``` ## Sự cố 5: Khi trong phút nông nổi bạn lỡ commit và giờ muốn commit đó biến mất ### Không để cho ai biết （＝ người khác vẫn chưa pull về） Sửa lại phần lịch sử commit ngay trước đó ```git # Tuỳ vào từng trường hợp mà ta có 3 cách sau để đưa lịch sử commit về như cũ # 1. Chỉ đưa HEAD về như cũ $ git reset --soft HEAD~ # 2. Đưa HEAD và index về như cũ $ git reset HEAD~ # 3. Đưa cả index, working tree về 1 commit trước đó $ git reset --hard HEAD~ ``` ### Trường hợp đã bị ai đó phát hiện（＝ người khác đã pull về） Nếu thay đổi lịch sử commit sẽ dẫn đến tình trạng lộn xộn nên ta cầm dùng commit xoá để giải quyết ```git $ git revert ``` ## Sự cố 6: Khi muốn tổng hợp những commit vụn vặt trước đây thành một commit Sử dụng rebase + squash (or fixup) để tổng hợp lại các commit cũ ```git # Rebase về n commit trước (có bao gồm cả HEAD) # Ví dụ) git rebase -i HEAD~3 $ git rebase -i HEAD~ ==== # Sau lệnh này sẽ mở ra editor nên hãy sửa lại như sau rồi lưu lại # (trước khi sửa) các commit cũ từ trên xuống dưới pick aa11bbc commit message 1 pick b2c3c4d commit message 2 pick 4e56fgh commit message 3 ・・・ # (sau khi sửa) các commit trước là squash sẽ được tổng hợp vào 1 commit ở đằng trước pick aa11bbc commit message 1 squash b2c3c4d commit message 2 squash 4e56fgh commit message 3 ・・・ ==== ``` Thay vì dùng squash có thể dùng fixup nhưng khi đó commit message của những commit được fixup sẽ bị mất ## Sự cố ７: Khi bạn muốn chia commit to thành những commit nhỏ hơn một cách thông minh Ở mục 6, tuy tổng hợp lại là tốt nhưng khi tổng hợp quá nhiều cũng sẽ trở thành vấn đề Rất tiện khi mà những commit chức năng bị lẫn vào những commit sửa bug ```git # Đây là việc không làm sau khi đã push code lên remote # Đầu tiên là đưa HEAD và index về 1 commit trước đó # Nói cách khác là ta coi như là chưa từng có commit to đùng kia và chỉ giữ lại trạng thái của working tree $ git reset HEAD~ # Dùng lệnh sau đây để thêm (y) hoặc không thêm (n) các phần nhỏ (=hunk) vào index # Nếu các phần nhỏ đó vẫn chưa đủ nhỏ thì dùng (s) để tiếp tục chia nhỏ hơn （Chi tiết của git add -p thì hãy hỏi anh Google nhé） $ git add -p # Khi các phần cần thay đổi đã có thì ta commit $ git commit -m "commit message" # Sau đó ta lặp đi lặp lại các bước như trên cho phần còn lại ``` ## Sự cố ８: Khi lỡ tay commit nhầm sang một branch khác Có những lúc ta sơ suất lỡ tay commit thẳng vào master trong khi thực ra là muốn commit vào một branch khác ```git # Đầu tiên là tạo một branch khác chứa trạng thái mà ta đã commit $ git branch other-branch # Đưa HEAD, index của master về 1 commit trước đó $ git reset --hard HEAD~ # Check out sang branch có commit trước đó $ git checkout other-branch ``` ## Sự cố ９: Khi muốn xoá hoàn toàn các file không cần thiết Có những lúc ta muốn 1 phát xoá tất tần tật những file tự động sinh ra hoặc những file tự động back up. Nếu không phải là những file cần git quản lý hoặc những file sẽ commit thì xoá đi thôi. Ơ mà cái này cũng ko phải là sự cố nhỉ... ```git # Đầu tiên là add＆commit tất cả những thứ cần thiết lại # Nếu không làm như thế này thì những file này cũng bị xoá mất đó $ git add $ git commit -m "commit message" # Dùng git stash để sơ tán cả những file untracked $ git stash -u # drop các thứ đã stash để xoá đi $ git stash drop ``` Tiện đây thì trong trường hợp chỉ là những file mà git không quản lý thì chỉ như sau là OK ```git # Kiểm tra lại các file sẽ xoá cho chắc $ git clean -n # Tiến hành xoá bỏ $ git clean -f ``` ## Sự cố 10: Khi tạm thời cần tạm dừng công việc hiện tại và chuyển sang một branch khác Tuy mình không xấu nhưng có những lúc cần phải tạm dừng công việc để làm việc khác ```git # Tạm thời lưu lại các phần công việc còn đang làm dở $ git stash -u # Chuyển sang một branch khác và làm việc $ git checkout -b other-branch ~làm việc, làm việc, làm việc~ $ git add $ git commit -m "commit message" # Trở về branch cũ $ git checkout origin-branch # Lấy lại các nội dung công việc đang làm dở trước đó $ git stash pop ``` ## Sự cố 11：Khi lỡ tay xoá mất một commit cực kì cực kì quan trọng Đây hẳn là sự cố khủng khiếp nhất. Có thể xảy ra khi lỡ tay git reset --hard Tuy nhiên, commit nào cũng có thể hồi phục được ```git # Đầu tiên là xem lại toàn bộ lịch sử commit $ git reflog # Từ đó chọn commit muốn phục hồi và khôi phục lại # ví dụ）git reset --hard HEAD@{2} $ git reset --hard ``` ## Sự cố 12: Khi lỡ tay xoá mất branch và muốn lấy lại Nếu vẫn còn reflog thì không có sao. Vẫn có thể hồi phục lại được Nếu commit lên một branch không tên, sau đó check out sang một branch khác bị xoá mất thì cũng tương tự Tương tự giống như sự cố 13 dưới đây ```git # Đầu tiên là xem lại toàn bộ lịch sử commit $ git reflog # Từ các commit này, chọn rồi tạo branch mới # ví dụ）git branch new-branch HEAD@{2} $ git branch ``` ## Sự cố 13: Khi muốn thay đổi một phần nội dung commit Khi có những typo nhỏ và muốn chỉnh sửa thì ko cần thiết phải tạo commit mới để sửa mà hãy tiến hành sửa lại luôn ```git # Chỉ định commit muốn sửa lại $ git rebase -i ==== # Sau lệnh này sẽ mở ra editor nên hãy sửa lại như sau rồi lưu lại # (trước khi sửa) các commit cũ từ trên xuống dưới pick aa11bbc commit message 1 pick b2c3c4d commit message 2 pick 4e56fgh commit message 3 ・・・ # (Sau khi sửa) Đổi commit cần sửa sang edit edit aa11bbc commit message 1 pick b2c3c4d commit message 2 pick 4e56fgh commit message 3 ・・・ ==== # Commit cần sửa sẽ được khai triển working tree nên ta chỉ cần sửa rồi sau đó add lại $ git add # Sửa lại commit $ git commit --amend # Hoàn tất rebase để trở lại như cũ $ git rebase --continue # Khi muốn huỷ bỏ rebase $ git rebase --abort ``` ## Sự cố 14: Khi có conflict trong quá trình rebase Khi không merge mà tiến hành rebase thì nếu có conflict, chắc hẳn là hoảng loạn rồi ```git # Khi đang ở branch1 rồi rebase từ branch2 vào $ git rebase branch2 ~~ Phát sinh conflict ~~ # Sẽ trở thành branch không tên nền cần phải chú ý $ git branch * (no branch, rebasing branch2) branch1 branch2 master # Hãy cố gắng giải quyết các conflict # Sau khi hoàn thành, ta add rồi tiến hành rebase $ git add # Thay đổi commit $ git commit --amend $ git rebase --continue ``` ### Sự cố 15: Khi đã merge nhưng lại muốn trở lại như lúc trước Chỉ cho trường hợp mà người khác vẫn chưa pull code về ```git # tiến hành merge $ git checkout $ git merge # Sau khi merge, nhưng lại muốn trở lại như trước thì làm như sau # Nếu chỉ định là ORIG_HEAD thì có thể trở lại trạng thái trước khi merge $ git reset --hard ORIG_HEAD ``` # Ở trên Remote ## Sự cố 16: Khi pull từ remote về thì có quá nhiều conflict nên tạm thời muốn trở lại như cũ Sau khi pull code về cập nhật nhưng thấy conflict nhiều như núi thì quả là muốn trở lại như cũ Gần giống như sự cố 15 ```git # Lấy từ code mới remote $ git pull origin master # Phát sinh conflict # Suy nghĩ lại thì trong pull(fetch + merge) muốn bỏ phần merge đi $ git reset --hard ORIG_HEAD ``` ## Sự cố 17: Lỡ tay push force lên master trên remote Việc push -f lên origin/master là việc bị cấm Tuy nhiên thì thỉnh thoảng vẫn có một số người làm... Ta sẽ sửa lại như sau ### Trường hợp chỉ cần push về 1 commit trước đó ```git # Cái này ko được làm đâu nhé, push force $ git commit -m "commit message" $ git push -f origin master # Nếu là một công ty nghiêm túc thì đến đây chắc chắn sẽ nổi giận đấy # Nếu muốn đưa về 1 commit tước đó thì làm như sau $ git push -f origin HEAD~:master ``` Nếu trên local cũng muốn như vậy thì tiến hành reset cũng tốt ```git $ git reset HEAD~ $ git push -f origin master ``` ### Nếu muốn xoá đi vài commit trước đó ```git # Cái này ko được làm đâu nhé, push force $ git commit -m "commit message" $ git push -f origin master # Khi bị mắng và muốn trở về như cũ thì $ git rebase -i ==== # Sau lệnh này sẽ mở ra editor nên hãy sửa lại như sau rồi lưu lại # (trước khi sửa) các commit cũ từ trên xuống dưới pick aa11bbc commit message 1 pick b2c3c4d commit message 2 ・・・ # (Sau khi sửa) Xoá các commit không cần thiết đi pick b2c3c4d commit message 2 ・・・ ==== # push force lại một lần nữa $ git push -f origin master ``` ## Sự cố 18: Sau khi release phát hiện thấy có bug và muốn trở về như cũ Do phát sinh thiệt hại nên những thứ đã merge và maste cần phải chuyển tạm thời về như cũ Tuy nhiên không thể revert từng commit 1 nếu có nhiều commit ```git # Kiểm tra commit log $ git log --oneline --graph ==== * 1x3y5z7 - Merge pull request #4 from develop |\ | * a2b45c7 - (develop) commit 3 * | dbc65f4 - commit 2 * | f0b0a91 - commit 1 # Chỉ định điểm muốn revert về (Cơ bản 1 là OK) ==== # Nếu merge develop vào master thì chỉ định master sẽ là １、develop là ２ rồi revert # Ví dụ）git revert -m 1 1x3y5z7 $ git revert -m 1 commit merge> ``` Nếu vẫn chưa có ai kéo phần code này về thì có thể làm đươc cả những việc sau nữa（Cái này nguy hiểm） ```git # Trở về trạng thái trước khi merge $ git reset ORIG_HEAD # PUSH FORCE $ git push -f origin master ``` ## Sự cố 19：Khi sau khi chuyển lại và đã commit thêm một số commit mới nhưng không thể merge lại được Ở sự cố 18, khi đã xoá bỏ merge, tiến hành chỉnh sửa nhưng merge lại không được commit revert không có nghĩa là sẽ ko còn commit merge nữa mà là làm ngược lại những việc mà commit merge làm Thế nên, khi merge lại thì cần phải revert lại commit revert ```git # Tiếp tục của sự cố 18 # Thêm commit vào develop branch $ git checkout develop $ git commit -m "commit message" # Checkout sang master $ git checkout master # revert lại commit revert $ git revert # merge develop $ git merge develop ``` # Khi muốn thử những điều trên ở một môi trường an toàn thì Đúng là nếu chưa quen mà tự nhiên lại thực hành luôn thì rất vất vả. Những ai đã có sản phầm thì có thể clone về và dùng cái đó để test thử Nếu thế thì cho dù có bị thất bại thì cũng không gây ảnh hưởng gì đến môi trường làm việc chính. Những ai chưa có sản phẩm có thể lên Github, tìm hiếm 1 repo nào đó nổi tiếng, clone về rồi thực hành Tuy nhiên cần chú ý 1 điều là những cái này chỉ được thử ở trên môi trường local thôi nhé Nếu muốn thử cả ở trên remote nữa thì có thể chuẩn bị sẵn môi trường test trên Github, clone về rồi thử Hình dung cơ bản như sau ```git # git clone về $ git clone # Thử nghiệm trên local # Kiểm tra remote hiện tại $ git remote -v # Xoá remote đã đăng ký $ git remote rm origin # Tạo remote đã được chuẩn bị sẵn cho test ở Github và thay đổi lại remote $ git remote add origin # Sau đó là thử nghiệm trêm remote ``` ]]> https://hungvn.com/blog/bi-kip-ban-co-the-dung-khi-pham-sai-lam-voi-git https://hungvn.com/blog/bi-kip-ban-co-the-dung-khi-pham-sai-lam-voi-git Sat, 03 Aug 2019 15:20:00 GMT <![CDATA[Cách xử lý các lỗi thường gặp trong Git]]> ``` **3\. Clone project** - Bạn phát hiện ra là bạn đã có url của project sẵn rồi thì tội gì phải khởi tạo git mới nữa. Thay vào đó hãy dùng clone ```git git clone ``` **4\. Làm việc cùng branch** - Git là một hệ thống quản lý phiên bản phân tán, vì thế mô hình của nó giống như một cái cây. Vậy bạn có thể nhận ra luôn là mỗi cái cây luôn có một thân cây chính, và các cành, nhánh nhỏ. Tương tự trong git ta có branch thể hiện mỗi nhánh nhỏ của một cái cây và nhánh chính tương đương với thân cây thường được gọi là master. Nếu từng làm việc thực tế trong các dự án bạn thường thấy nhánh master sẽ là nhánh rỗng, thay vào đó những developer sử dụng các nhánh có tên như development, product, test,.... Điều này giúp cho các lập trình viên phân biện và thao tác trên những môi trường tương ứng quan quá trình phát triển phần mềm một cách dễ dàng và minh bạch hơn. ![](https://images.viblo.asia/3b171116-23fb-4bd2-a8ac-65b63fe65372.png) - Một số lệnh cơ bản ```git # Danh sách branch git branch # tạo mới branch git branch () # Di chuyển từ branch hiện tại đến một branch khác bằng tên branch đó git checkout # Tạo và di chuyển từ branch hiện tại đến một branch mới git checkout -b ``` **5\. Hợp nhất branch** - Đây là một trong những câu lệnh cơ bản thường dùng của quy trình. Nhưng với việc các tool hỗ trợ như github, gitlab,... thì việc sử dụng câu lệnh này chỉ còn nằm ở dưới local mà thôi. ```git # để hợp nhất nhánh branch-name vào nhánh master git merge ``` **6\. Cập nhật code mới nhất về** Khi làm việc một mình thực tế bạn sẽ không cần đến git nhưng khi làm việc nhóm và muốn lấy code mới nhất từ một nhánh nào đó trên repo online về thì bạn sẽ dùng lệnh sau: ```git git pull origin ``` **7\. xem status và một vài thứ nữa** ```git git status git diff –-stat ``` ## Những sự cố thường gặp trong Git ### 1\. Viết sai message commit - Để thay đổi nộ dung commit, thêm, sửa file vào commit rất đơn giản bạn chỉ cần sử dụng ```git git commit --amend ``` ### 2\. Đặt sai tên branch - Việc gõ nhầm hay thiết thành phần theo convention khi đặt tên branch là không hiếm. Lúc mới tiếp cận bạn thường lựa chọn giải pháp là tạo một branch mới. Có một cách nhanh hơn rất nhiều giống như rename trong các phần làm việc với file đó là dùng câu lệnh: ```git git branch -m ``` ### 3\. Commit chơi chơi và giờ muốn nó bay màu - Việc làm ngốc ngếch này diễn ra thường xuyên trong quá trình làm việc, vậy làm thế nào để code dữ nguyên và xóa commit đó đi, đầu tiên bạn phải tìm hiểu một số lý thuyết sau: **Note: HEAD, Working tree, Index trong git là gì?** - Git giữ một con trỏ đặc biệt có tên HEAD. Trong Git, đây là một con trỏ tới nhánh nội bộ mà bạn đang làm việc - Trên Git, những thư mục được đặt trong sự quản lý của Git mà mọi người đang thực hiện công việc trong thực tế được gọi là working tree. - Giữa repository và working tree tồn tại một nơi gọi là index. Index là nơi để chuẩn bị cho việc commit lên repository #### Cách 1: Sử dụng reset (khi chưa có ai pull về) - `git reset HEAD~` Di chuyển HEAD về vị trí commit reset và vẫn giữ nguyên tất cả các thay đổi của file, nhưng loại bỏ các thay đổi khỏi stage (Đưa HEAD và index về như cũ) ```git git reset {commit_id} ``` - `git reset --hard HEAD~` - Di chuyển con trỏ HEAD về vị trí commit reset và loại bỏ tất cả sự thay đổi của file sau thời điểm commit reset - HEAD~ có ý nghĩa giống với HEAD^ hay @^, nghĩa là quay về trước 1 commit - Muốn quay về trước n commit, VD 5 commit thì có thể thay bằng HEAD~5. - --hard có nghĩa là bỏ commit đi và bỏ cả những thay đổi chưa được commit trong working space. Khi này môi trường sẽ hoàn toàn "sạch sẽ" như thời điểm trước khi commit - `git reset --soft HEAD~` - Lệnh này chỉ di chuyển HEAD về vị trí commit reset. Trạng thái của stage và tất cả sự thay đổi của file sẽ được giữ nguyên - --soft có nghĩa là bỏ commit đi nhưng giữ nguyên những thay đổi chưa được commit trong working space. - --soft hữu dụng khi bạn muốn giữ lại những thay đổi chưa commit cho lần commit tiếp theo #### Cách 2: Sử dụng revert (người khác đã pull về) ```git # commit_hash là mã commit git revert ``` #### Cách 3: Sử dụng --amend ```git git commit --amend # Bạn có thể sử dụng lệnh này để viết lại commit message # Option --no-edit sử dụng khi bạn chỉ muốn thêm file mà không muốn sửa commit message git commit --amend --no-edit ``` ### 4\. Khi lỡ tay commit nhầm sang một branch khác - Có những lúc ta sơ suất lỡ tay commit thẳng vào master trong khi thực ra là muốn commit vào một branch khác ```git #Đầu tiên là tạo một branch khác chứa trạng thái mà ta đã commit $ git branch other-branch #Đưa HEAD, index của master về 1 commit trước đó $ git reset --hard HEAD~ #Check out sang branch có commit trước đó $ git checkout other-branch ``` ### 5\. Gộp nhiều commit thành một commit Sử dụng rebase + squash (or fixup) để tổng hợp lại các commit cũ - Squash: giữa nguyên commit message của những commit trước - Fixup: xoá commit message của những commit trước ```git Rebase về n commit trước (có bao gồm cả HEAD) # Ví dụ) git rebase -i HEAD~3 $ git rebase -i HEAD~ # Sau lệnh này sẽ mở ra editor nên hãy sửa lại như sau rồi lưu lại # Note: Với vim bấm “a” để bắt đầu edit → Bấm ECS để dừng thao tác edit → Bấm “shift + z + z” để save # (trước khi sửa) các commit cũ từ trên xuống dưới pick aa11bbc commit message 1 pick b2c3c4d commit message 2 pick 4e56fgh commit message 3 ・・・ # (sau khi sửa) các commit trước là squash sẽ được tổng hợp vào 1 commit ở đằng trước pick aa11bbc commit message 1 squash b2c3c4d commit message 2 squash 4e56fgh commit message 3 ``` ### 6\. Chia commit to thành nhiều commit nhỏ ```git # Đầu tiên là đưa HEAD và index về 1 commit trước đó. # Nói cách khác là ta coi như là chưa từng có commit to đùng kia và chỉ giữ lại trạng thái của working tree $ git reset HEAD~ # Dùng lệnh sau đây để thêm các phần nhỏ vào index $ git add -p # Khi các phần cần thay đổi đã có thì ta commit $ git commit -m "commit message" # Sau đó ta lặp đi lặp lại các bước như trên cho phần còn lại ``` ### 7\. Chuyển xang nhánh khác khi đang làm việc giở ```git # Tạm thời lưu lại các phần công việc còn đang làm dở $ git stash -u # Chuyển sang một branch khác và làm việc $ git checkout -b other-branch $ git add $ git commit -m "commit message" # Trở về branch cũ $ git checkout origin-branch # Lấy lại các nội dung công việc đang làm dở trước đó $ git stash pop ``` ### 8\. Hồi phục commit quan trọng khi lỡ tay xóa nó đi - Đây hẳn là sự cố khủng khiếp nhất. Có thể xảy ra khi lỡ tay git reset --hard .Tuy nhiên, commit nào cũng có thể hồi phục được ```git # Đầu tiên là xem lại toàn bộ lịch sử commit $ git reflog # Từ đó chọn commit muốn phục hồi và khôi phục lại # ví dụ: git reset --hard HEAD@{2} $ git reset --hard ``` ### 9\. Khôi phục branch đã xóa ```git # Đầu tiên là xem lại toàn bộ lịch sử commit $ git reflog # Từ các commit này, chọn rồi tạo branch mới # ví dụ: git branch new-branch HEAD@{2} $ git branch ``` ### 10\. Khôi phục về trạng thái trước khi merge - Note: Chỉ cho trường hợp mà người khác vẫn chưa pull code về ```git git reset --hard ORIG_HEAD # Commit trước khi reset được tham chiếu bằng ORIG_HEAD ``` ### 11\. Khôi phục về trạng thái trước khi pull từ remote - Sau khi pull code về cập nhật nhưng thấy conflict nhiều như núi thì quả là muốn trở lại như cũ ```git # Lấy từ code mới remote $ git pull origin master # Phát sinh conflict # Suy nghĩ lại thì trong pull(fetch + merge) muốn bỏ phần merge đi: $ git reset --hard ORIG_HEAD ``` ### 12\. Khi bạn muốn rename 1 nhánh cả ở local và trên remote (github) ```git git branch -m new-name git push remote-name :old-name new-name ``` ### 13\. Khi bạn muốn xoá 1 branch trên remote từ xa ```git git push origin --delete remote-branch-name ``` Đó là các thao tác cơ bản và cách sửa một số lỗi thường gặp khi làm việc với git của mình. Rất mong các bạn góp ý để mình cải thiện bài viết này và các bài sau hơn nữa. ]]> https://hungvn.com/blog/cach-xu-ly-cac-loi-thuong-gap-trong-git https://hungvn.com/blog/cach-xu-ly-cac-loi-thuong-gap-trong-git Fri, 02 Aug 2019 10:20:00 GMT <![CDATA[Clean Up Redux Code with React-Redux Hooks]]> ({ type: "CHANGE_COUNT", payload: count + 1, }); export const decrement = count => ({ type: "CHANGE_COUNT", payload: count - 1, }); ``` Here are some action creators to increment and decrement the counter in our store. I could have declared a CHANGE_COUNT constant to protect against misspellings, but the store is small enough to skip that step. ```javascript import { createStore } from "redux"; const initialState = { count: 0, }; const counterReducer = (state = initialState, action) => { switch (action.type) { case "CHANGE_COUNT": return { ...state, count: action.payload, }; default: return state; } }; ``` This is business as usual for Redux. The new hooks API doesn’t reduce this part of the boilerplate. Now let’s look at how we connect our store to the React app with the counter: ```javascript import React from "react"; import { render } from "react-dom"; import { Provider } from "react-redux"; import App from "./components/App.jsx"; import store from "./reducers/counterReducer"; render( , document.getElementById("root") ); ``` Now let’s look at how our App component would get access to data from the Redux store without using the React-Redux hooks API: ```javascript import React from "react"; import { connect } from "react-redux"; import * as actions from "../actions/actions"; class App extends React.Component { constructor(props) { super(props); } render() { const { count, increment, decrement } = this.props; return (

The count is {count}

); } } const mapStateToProps = store => ({ count: store.count, }); const mapDispatchToProps = dispatch => ({ increment: count => dispatch(actions.increment(count)), decrement: count => dispatch(actions.decrement(count)), }); export default connect(mapStateToProps, mapDispatchToProps)(App); ``` This is how we get our simple counter app to work with React and Redux. But that’s a lot of boilerplate for something so simple. Let’s take a look at what’s going on here. First of all, we have a constructor that does nothing but give our class component access to the props being passed down to it. This component doesn’t actually need to be a class component since it’s not using local state or any lifecycle methods, so let’s quickly refactor it to a functional component so we can bring in the hooks: ```javascript import React from "react"; import { connect } from "react-redux"; import * as actions from "../actions/actions"; const App = props => { const { count, increment, decrement } = props; return (

The count is {count}

); }; const mapStateToProps = store => ({ count: store.count, }); const mapDispatchToProps = dispatch => ({ increment: count => dispatch(actions.increment(count)), decrement: count => dispatch(actions.decrement(count)), }); export default connect(mapStateToProps, mapDispatchToProps)(App); ``` Okay, that’s a bit nicer, but it’s still more complicated than it needs to be. We still need to definemapStateToProps() and mapDispatchToProps()functions to connect to the Redux store, and wrap our App component in the connect()higher-order component so we can pass these pieces of the store and dispatching functions down to our App component as props. We also have to write this.props over and over again (or, to avoid that, we can use [object destructuring](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment#Object_destructuring) assignment like I did to assign our props to variables) in order to access these pieces of the store and dispatching functions. It’s all a bit messy, isn’t it? Let’s clean this up a bit. First, let’s look at [useSelector()](https://react-redux.js.org/next/api/hooks#useselector). This new React-Redux hook takes the place of mapStateToProps() and allows you to directly hook into your Redux store without needing to pass state as props from a higher-order component. This function takes a callback as an argument. That callback takes the entire Redux store as its argument, but you don’t have to worry about grabbing the store yourself, because useSelector() gets it from the Provider that we wrapped our App component in. In the body of the callback, you can return whichever piece of the store you want to have access to and save it as a variable in your component. Since our Redux store’s initial state has a countproperty with the initial value of 0, we can write _const count = useSelector(store => store.count)\_which \_selects_ the countproperty from our store and assigns it to the countconstant we just declared. Before we press any buttons, that variable will have the value of0. Let’s refactor our component to use the useSelector() hook. ```javascript import React from "react"; import { useSelector, connect } from "react-redux"; import * as actions from "../actions/actions"; const App = props => { const { increment, decrement } = props; const count = useSelector(store => store.count); return (

The count is {count}

); }; const mapDispatchToProps = dispatch => ({ increment: count => dispatch(actions.increment(count)), decrement: count => dispatch(actions.decrement(count)), }); export default connect(null, mapDispatchToProps)(App); ``` This is a lot nicer already. We can get direct access to values from our Redux store now, and not rely on some higher-order component we didn’t write to pass it to our component as props. We can reference our count constant anywhere in the body of our component and it will have the current value from our Redux store. If any actions are dispatched that update the countproperty in our store, our countconstant will be updated as well. We can simply call useSelector()again with a different selector and assign it to another variable if we need to make another selection from the store. But, speaking of dispatching actions, our mapDispatchToProps() function still forces us to use connect() to get functions as props that we’d rather directly access in our component. Let’s do something about this. The other main React-Redux hook, [useDispatch()](https://react-redux.js.org/next/api/hooks#usedispatch), takes care of this for us. This one is super simple. Just call useDispatch() in your component, and it will return a function you can use to dispatch actions to your Redux store. Pass a call to an action creator to this returned function, and it will work just like a function from mapDispatchToProps(). Let’s refactor our component one last time to implement the useDispatch() hook: ```javascript import React from "react"; import { useSelector, useDispatch } from "react-redux"; import * as actions from "../actions/actions"; const App = () => { const dispatch = useDispatch(); const count = useSelector(store => store.count); return (

The count is {count}

); }; export default App; ``` Now that we can access our store and the dispatch function directly in our component, there’s no longer any need to wrap App in a higher-order component to pass anything to it as props. This results in much cleaner code where everything is defined where it’s relevant. If you need to change any logic pertaining to Redux, you won’t have to look outside of the body your component anymore. Now, everything is nicely contained. Obviously, this example is so simple that it hardly makes sense to use Redux here (or even React, really). But these hooks can be used the exact same way they are here, even if they’re in a more complex component that also uses React hooks like [useState()](https://reactjs.org/docs/hooks-state.html) or [useEffect()](https://reactjs.org/docs/hooks-effect.html). Admittedly, there still is a lot of time-consuming boilerplate writing you need to do to set up a React-Redux app, even if you’re using the hooks APIs. Prototyping apps such as [preducks](https://www.preducks.com/) (pictured at the top of the article) can help you eliminate a lot of the mindless setup and truly optimize your developer experience. (There’s even a [node module](https://www.npmjs.com/package/preducks?activeTab=readme) for extremely quick setup: think [_create-react-app_](https://www.npmjs.com/package/create-react-app) but with Redux boilerplate too). preducks also uses [TypeScript](https://www.typescriptlang.org/). Much like hooks, TypeScript also improves your developer experience by bringing strict, static type checking into JavaScript, letting you eliminate bugs and keep better track of the shape you expect your data to be. This gets useful when your React-Redux apps get large and your data gets complex. Give preducks a try if you’re interested in seeing React Redux hooks in action (along with React hooks and TypeScript). (For a more complex example of how to use React-Redux hooks along with TypeScript, check out this [GitHub repo](https://github.com/palgorhythm/todoTShooks) showing how to build a to-do app with these technologies.) ]]> https://hungvn.com/blog/clean-up-redux-code-with-react-redux-hooks https://hungvn.com/blog/clean-up-redux-code-with-react-redux-hooks Tue, 23 Jul 2019 08:20:00 GMT <![CDATA[3 Cách thực thi Child method từ Parent Component]]> Previously, refs were only supported for Class-based components. With the advent of [React Hooks](https://reactjs.org/docs/hooks-intro.html), that's no longer the case ## Using Hooks and Function Components (`>= react@16.8`) ```javascript import React, { forwardRef, useRef, useImperativeHandle } from "react"; // We need to wrap component in `forwardRef` in order to gain // access to the ref object that is assigned using the `ref` prop. // This ref is passed as the second parameter to the function component. const Child = forwardRef((props, ref) => { // The component instance will be extended // with whatever you return from the callback passed // as the second argument useImperativeHandle(ref, () => ({ getAlert() { alert("getAlert from Child"); }, })); return

Hi

; }); const Parent = () => { // In order to gain access to the child component instance, // you need to assign it to a `ref`, so we call `useRef()` to get one const childRef = useRef(); return (
); }; ``` [Functioning example](https://codesandbox.io/s/8lxr0pq179) Documentation for `useImperativeHandle()` is [here](https://reactjs.org/docs/hooks-reference.html#useimperativehandle): > `useImperativeHandle` customizes the instance value that is exposed to parent components when using `ref`. ## Using Class Components (`>= react@16.4`) ```javascript class Parent extends Component { constructor(props) { super(props); this.child = React.createRef(); } onClick = () => { this.child.current.getAlert(); }; render() { return (
); } } class Child extends Component { getAlert() { alert("getAlert from Child"); } render() { return

Hello

; } } ReactDOM.render(, document.getElementById("root")); ``` [Functioning Example](https://codesandbox.io/embed/kw5mn93wmr) ## Legacy API (`<= react@16.3`) For historical purposes, here's the callback-based style you'd use with React versions before 16.3: ```javascript const { Component } = React; const { render } = ReactDOM; class Parent extends Component { render() { return (
{ this.child = instance; }} />
); } } class Child extends Component { getAlert() { alert("clicked"); } render() { return

Hello

; } } render(, document.getElementById("app")); ``` ]]> https://hungvn.com/blog/3-cach-thuc-thi-child-method-tu-parent-component https://hungvn.com/blog/3-cach-thuc-thi-child-method-tu-parent-component Fri, 12 Jul 2019 11:50:00 GMT <![CDATA[Tại sao các React developer nên modularize các ứng dụng của mình]]> https://hungvn.com/blog/tai-sao-cac-react-developer-nen-modularize-cac-ung-dung-cua-minh https://hungvn.com/blog/tai-sao-cac-react-developer-nen-modularize-cac-ung-dung-cua-minh Tue, 25 Jun 2019 19:45:00 GMT <![CDATA[Cách tổ chức các ứng dụng React tốt hơn]]> https://hungvn.com/blog/cach-to-chuc-cac-ung-dung-react-tot-hon https://hungvn.com/blog/cach-to-chuc-cac-ung-dung-react-tot-hon Wed, 12 Jun 2019 12:15:00 GMT <![CDATA[Tại sao nên sử dụng object cho một danh sách trong Redux]]> comment.id === commentId); // object comments[commentId]; ``` #### Update comment id 1 ```javascript const updatedComment = { id: "1", text: "add code examples, please" }; // array comments.map(comment => { if (comment.id === updatedComment.id) { return updatedComment; } return comment; }); // object comments[updatedComment.id] = updatedComment; ``` #### Delete comment id 3 ```javascript const commentId = "3"; // array comments.filter(comment => comment.id !== commentId); // object delete comments[commentId]; ``` #### Adding a new comment We have to assume that we don’t know whether it already exists or not ```javascript const newComment = { id: '4', text: 'thanks for the code examples!' }; // array if (comments.find((comment) => comment.id === newComment.id) { comments = comments.map((comment) => { if (comment.id === newComment.id) { return newComment; } return comment; }); } else { comments = comments.concat([newComment]); } // object comments[newComment.id] = newComment; ``` ### What if you need an array somewhere in your code? Sometimes, you might find that it’s easier to use an array for your list of items. For example, when you are rendering a list. It’s easier to have an array, use a map and create the element in each iteration. This has an easy solution. Instead of accessing directly the state, use a function. What is also known as a **selector**. A selector is a function that takes some state and returns the data you need. Usually in the schema or structure you want. ```javascript // object const comments = { 1: { id: "1", text: "please add code examples" }, 2: { id: "2", text: "examples would be great for this article" }, 3: { id: "3", text: "hi there" }, }; // transform to array const commentsSelector = commentsObj => { return Object.keys(commentsObj).map(commentKey => commentsObj[commentKey]); }; // usage of the selector const commentsArray = commentsSelector(comments); ``` ### Conclusion Using an object will save your future self some time and bugs. Do her/him a favor and use an object to store a list of items. Even as a beginner, I recommend you to to use objects instead of arrays to store lists of items. The struggle pays off at the end. As most struggles do :) More on best practices in state shapes in [Redux Docs on Normalization](https://redux.js.org/recipes/structuring-reducers/normalizing-state-shape). Thank you for reading. I would love to hear your thought in the comments. ]]> https://hungvn.com/blog/tai-sao-nen-su-dung-object-cho-mot-danh-sach-trong-redux https://hungvn.com/blog/tai-sao-nen-su-dung-object-cho-mot-danh-sach-trong-redux Mon, 27 May 2019 19:45:00 GMT <![CDATA[Xây dựng hệ thống Component có thể tái sử dụng với React và Styled-components]]> { return console.log("clicked")}>Click me; }; ``` As you can see, you can basically put any kind of CSS in the style declaration. Styled-components exports all of the common HTML elements, so you can use them from the imported package, for example styled.div`or styled.a or anything else. Maybe you have noticed the backticks` around the styles, this is plain JavaScript (ES6) and is called template literals. I assume you have seen something like this before console.log(`Bob is ${age} years old.`) , enabling you to put JavaScript within a string. Styled-components behaves no different and you can use **any kind of JavaScript** inside your style declaration. But wait, there’s more. Since we’re using React.js to build our application, we highly depend on state and props. Wouldn’t it be useful to have styles based on our Application state? Yes it would, and styled-components provides a simple solution for that. You can pass a function to your style declarations, with one parameter, being the component’s props. You can then use props to adjust your styling. Here is an example: ```javascript import React from "react"; import ReactDOM from "react-dom"; import styled from "styled-components"; const StyledButton = styled.button` border-radius: 5px; background-color: ${props => (props.secondary ? "#F7A072" : "#a1cdf1")}; color: #fff; padding: 10px 15px; outline: none; border: none; cursor: pointer; margin: 15px; `; const Application = () => { return (
Click me Click for secondary Action
); }; ``` There is some more functionality provided by styled-components, for example extending styles, the ability to style any component, theming or the css -helper (which we’re going to use later). For now, this should be a good starting point to build our component system, but feel free to have a look at the [docs](https://www.styled-components.com/docs). #### Summary: Advantages of styled-components over css files Traditional CSS is hard to keep clean. To prevent selector collisions, you would have to use specific class-naming terminology to ensure isolation (i.e. BEM). Conditional styling would be implemented by passing ternary / logical statements to the className prop, for example: ```javascript ); }; ``` ```javascript import React from "react"; import styled, { css } from "styled-components"; const StyledButton = styled.button` border-radius: 5px; background-color: ${props => (props.secondary ? "#F7A072" : "#a1cdf1")}; color: #fff; padding: 10px 15px; font-size: ${props => { if (props.big) return "20px"; return "16px"; }}; outline: none; border: none; cursor: pointer; margin: 15px; border: 2px solid ${props => (props.secondary ? "#F7A072" : "#a1cdf1")}; ${props => { return ( props.inverse && css` background-color: #fff; color: #a1cdf1; ` ); }} `; const Button = ({ secondary, big, inverse, ...props }) => { return ; }; export default Button; ``` As you can see, it is very easy to recognize what props you can pass to the Button component. Lastly, it is still possible to override and extend any styles with inline styles. ![Photo by David Pisnoy on Unsplash](https://cdn-images-1.medium.com/max/1600/1*Sa1xgXyCno2Gyhb6ZQiwxA.jpeg) #### Multiple types: css`` vs each property individually Hopefully you spotted that I used the `css` helper in the extended Button example. There are different ways to apply styles based on props, either with inline ternary / conditional operators (Button.jsx:6) for one style property, full JavaScript block (Button.jsx:9–12) for one style property or the css helper (Button.jsx:19–27) for multiple style properties. Obviously, you may use what fits your coding style best. However, I tend to use the `css` helper for mostly separated chunks of styling, that are not mixed with other props and usually use separate conditionals for one style property, just to keep my code clean. --- Here is the Button example on codesandbox.io: `codesandbox: l27mlxk449` --- ### Building the component system Let’s get to the real work. We saw how the basic principles work, now let’s build a more sophisticated system. > A full working example with all components is available on [Github](https://github.com/gisderdube/react-component-system). #### Container ![Default container, 25px — ](https://cdn-images-1.medium.com/max/2400/1*Kcyyq-E_LhAp6m3ukb-l7Q.jpeg) One component I very often use is a container component. Usually, you don’t want your content to overflow a certain width on your page. I would aim for 900–1000px, depending on application content. You could have a component with the desired width and position it with flex, but what if you want to have a full width background(-color)? There is an easy trick for that, using padding and calc() it, depending on your viewport width. This is will create a nice container, has full width, centers the content and can easily be nested and reused. Here’s the code for that Container component: ```javascript import React from "react"; import styled from "styled-components"; const Container = styled.div` padding-left: ${props => { if (props.full) return 0; return "calc((100vw - 960px) / 2)"; }}; padding-right: ${props => { if (props.full) return 0; return "calc((100vw - 960px) / 2)"; }}; padding-top: ${props => { if (props.fullVertical) return 0; if (props.small) return "15px"; return "25px"; }}; padding-bottom: ${props => { if (props.fullVertical) return 0; if (props.small) return "15px"; return "25px"; }}; `; export default Container; ``` I added a couple of other props to the Container, being small , full and fullVertical. Sometimes you want a full-width image or similar. Feel free to extend or change the component as you wish, I just found these rules useful. Here’s some visual examples: ![](https://cdn-images-1.medium.com/max/2400/1*99Y_P7Z07QrpYG2vDLS8kQ.jpeg) --- ![](https://cdn-images-1.medium.com/max/2400/1*6kaf52ZydJTzemF0wqQnwQ.jpeg) --- > You can set global styles for your application, such as font-family or base font-size, with styled-component’s [`createGlobalStyle`](https://www.styled-components.com/docs/api#createglobalstyle) helper. --- #### Flexbox With the Container in place, let’s have a look at our second component, which we will also use for layout: a flex wrapper and child components. This component simply saves us time to type display: flex, flex-direction: …, justify-content: ..., and all of the other flex properties over and over again. ![…](https://cdn-images-1.medium.com/max/2400/1*dPIao5k5EgoVR1A5WtylAA.jpeg) Way easier than thinking of a class, assigning it and giving the styling properties manually, isn’t it? Let’s even add another sub-component, declared in the same file / module, that gives us a nice column, either half, a third or a quarter of our parent element. ![(x3)](https://cdn-images-1.medium.com/max/2400/1*9WP-l7ZEonOCgm5r_OgstQ.jpeg) We can also use a smaller Column, use it fewer times and spread it over the Flex parent: ![(x3)](https://cdn-images-1.medium.com/max/2400/1*YS3MxZD1yiNAX3pxfXZzHA.jpeg) Here is the code: ```javascript import React from "react"; import styled from "styled-components"; const Flex = styled.div` display: flex; flex-wrap: ${props => { if (props.wrapReverse) return "wrap-reverse"; else if (props.noWrap) return "nowrap"; return "wrap"; }}; justify-content: ${props => { if (props.justifyContent) return props.justifyContent; if (props.justifyCenter) return "center"; else if (props.justifyAround) return "space-around"; else if (props.justifyBetween) return "space-between"; else if (props.justifyEnd) return "flex-end"; return "flex-start"; }}; align-items: ${props => { if (props.alignItems) return props.alignItems; else if (props.alignStretch) return "stretch"; else if (props.alignEnd) return "flex-end"; if (props.alignCenter) return "center"; else if (props.alignBaseline) return "baseline"; return "flex-start"; }}; align-content: ${props => { if (props.alignContent) return props.content; else if (props.contentStart) return "flex-start"; else if (props.contentEnd) return "flex-end"; else if (props.contentCenter) return "center"; else if (props.contentBetween) return "space-between"; else if (props.contentAround) return "contentAround"; return "stretch"; }}; flex-direction: ${props => (props.column ? "column" : "row")}; `; export const Column = styled.div` width: ${props => { if (props.three) return "33.33%"; if (props.four) return "25%"; return "50%"; }}; padding: ${props => (props.noPadding ? 0 : "15px")}}; `; export default Flex; ``` #### Button Having implemented basic layout components, we can now proceed to a bit more approachable stuff. Let’s try to improve our Button that we saw in the introduction. What if we could have a loading sign being displayed, based on props. Remember, we want to have one entry point for the component, the component itself should take care of the rest, logic, styling and markup. For the loading sign to be displayed, we don’t want our caption, meaning React children, to be visible. Our component instance could look somewhat like this: ```javascript ); } ``` This is a simple, **correctly implemented** counter, which increments or decrements on user click. #### Level 1: setInterval ```javascript export default function Level01() { console.log('renderLevel01'); const [count, setCount] = useState(0); setInterval(() => { setCount(count + 1); }, 500); return
count => {count}
; } ``` Intention of this code is to increase counter every 500ms. This code has a huge **resource leak** and is **implemented incorrectly.** It will easily crash browser tab. Since Level01 function is called every time render happens, this component creates new interval every time render is triggered. > Mutations, subscriptions, timers, logging, and other side effects are not allowed inside the main body of a function component (referred to as React’s _render phase_). Doing so will lead to confusing bugs and inconsistencies in the UI. 🔗 [Hooks API Reference](https://reactjs.org/docs/hooks-reference.html): [useEffect](https://reactjs.org/docs/hooks-reference.html#useeffect) #### Level 2: useEffect ```javascript export default function Level02() { console.log('renderLevel02'); const [count, setCount] = useState(0); useEffect(() => { setInterval(() => { setCount(count + 1); }, 500); }); return
Level 2: count => {count}
; } ``` Most side-effects happen inside [useEffect](https://reactjs.org/docs/hooks-reference.html#useeffect). This code also has a huge **resource leak** and is **implemented incorrectly**. Default behavior of useEffect is to run after every render, so new interval will be created every time count changes. 🔗 [Hooks API Reference](https://reactjs.org/docs/hooks-reference.html): [useEffect](https://reactjs.org/docs/hooks-reference.html#useeffect), [Timing of Effects](https://reactjs.org/docs/hooks-reference.html#timing-of-effects). #### Level 3: run only once ```javascript export default function Level03() { console.log('renderLevel03'); const [count, setCount] = useState(0); useEffect(() => { setInterval(() => { setCount(count + 1); }, 300); }, []); return
count => {count}
; } ``` Giving [] as second argument to useEffect will call function once, after mount. Even though setInterval is called only once, this code is **implemented incorrectly.** count will increase from 0 to 1 and stay that way**.** Arrow functionwill be created once and when that happens, count will be 0. This code has **subtle resource leak**. Even after component unmounts, setCount will still be called. 🔗 [Hooks API Reference](https://reactjs.org/docs/hooks-reference.html): [useEffect](https://reactjs.org/docs/hooks-reference.html#useeffect), [Conditionally firing an effect](https://reactjs.org/docs/hooks-reference.html#conditionally-firing-an-effect). #### Level 4: cleanup ```javascript useEffect(() => { const interval = setInterval(() => { setCount(count + 1); }, 300); return () => clearInterval(interval); }, []); ``` To prevent **resource leaks**, everything must be disposed when lifecycle of a hook ends. In this case returned function will be called after component unmounts. This code **does not have resource leaks**, but is **implemented incorrectly**, just like previous one. 🔗 [Hooks API Reference](https://reactjs.org/docs/hooks-reference.html): [Cleaning up an effect](https://reactjs.org/docs/hooks-reference.html#cleaning-up-an-effect). #### Level 5: use count as dependency ```javascript useEffect(() => { const interval = setInterval(() => { setCount(count + 1); }, 500); return () => clearInterval(interval); }, [count]); ``` Giving array of dependencies to useEffect will change its lifecycle. In this example useEffect will be called once after mount and every time count changes. Cleanup function will be called every time count changes to dispose previous resource. This code **works correctly**, without any bugs, but it’s slightly **misleading**. setInterval is created and disposed every 500ms. Each setInterval is always called once. 🔗 [Hooks API Reference](https://reactjs.org/docs/hooks-reference.html): [useEffect](https://reactjs.org/docs/hooks-reference.html#useeffect), [Conditionally firing an effect](https://reactjs.org/docs/hooks-reference.html#conditionally-firing-an-effect). #### Level 6: setTimeout ```javascript useEffect(() => { const timeout = setTimeout(() => { setCount(count + 1); }, 500); return () => clearTimeout(timeout); }, [count]); ``` This code and the code above **work correctly**. Since useEffect is called every time count changes, using setTimeout has same effect as calling setInterval . This example is inefficient, new setTimeout is created every time render happens. React has a better way for fixing the problem. #### Level 7: functional updates for useState ```javascript useEffect(() => { const interval = setInterval(() => { setCount(c => c + 1); }, 500); return () => clearInterval(interval); }, []); ``` In previous example we ran useEffect on each count change. The was necessary because we needed to have always up-to-date current value. useState provides API to update previous state without capturing the current value. To do that, all we need to do is provide lambda to setState . This code **works correctly** and more efficiently. We are using a single setInterval during the lifecycle of a component. clearInterval will only be called once after component is **unmounted**. 🔗 [Hooks API Reference](https://reactjs.org/docs/hooks-reference.html): [useState](https://reactjs.org/docs/hooks-reference.html#usestate), [Functional updates](https://reactjs.org/docs/hooks-reference.html#functional-updates). #### Level 8: local variable ```javascript export default function Level08() { console.log('renderLevel08'); const [count, setCount] = useState(0); let interval = null; const start = () => { interval = setInterval(() => { setCount((c) => c + 1); }, 500); }; const stop = () => { clearInterval(interval); }; return (
count => {count}
); } ``` We’ve added start and stop buttons. This code is **implemented incorrectly,** stop button does not work. New reference is created during each render, so stop will have reference to null. 🔗 [Hooks API Reference](https://reactjs.org/docs/hooks-reference.html): [Is there something like instance variables?](https://reactjs.org/docs/hooks-faq.html#is-there-something-like-instance-variables) #### Level 9: useRef ```javascript export default function Level09() { console.log('renderLevel09'); const [count, setCount] = useState(0); const intervalRef = useRef(null); const start = () => { intervalRef.current = setInterval(() => { setCount((c) => c + 1); }, 500); }; const stop = () => { clearInterval(intervalRef.current); }; return (
count => {count}
); } ``` useRef is the go-to hook if mutable variable is needed. Unlike local variables, React makes sure same reference is returned during each render. This code seems correct, but has a **subtle bug**. If start is called multiple times, setInterval will be called multiple times triggering **resource leak**. 🔗 [Hooks API Reference](https://reactjs.org/docs/hooks-reference.html): [useRef](https://reactjs.org/docs/hooks-reference.html#useref) #### Level 10: useCallback ```javascript export default function Level10() { console.log('renderLevel10'); const [count, setCount] = useState(0); const intervalRef = useRef(null); const start = () => { if (intervalRef.current !== null) { return; } intervalRef.current = setInterval(() => { setCount((c) => c + 1); }, 500); }; const stop = () => { if (intervalRef.current === null) { return; } clearInterval(intervalRef.current); intervalRef.current = null; }; return (
count => {count}
); } ``` To avoid resource leak, we simply ignore calls if interval is already started. Although calling clearInterval(null) does not trigger any errors, it’s still good practice to dispose resource only once. This code has **no resource leaks**, is **implemented correctly**, but might have a **performance problem**. memoization is main performance optimization tool in React. React.memo does shallow comparison and if references are same, render is skipped. If start and stop were passed to a memoized component, the whole optimization would fail, because new reference is returned after each render. 🔗 [**React Hooks: Memoization**](https://medium.com/@sdolidze/react-hooks-memoization-99a9a91c8853) #### Level 11: useCallback ```javascript export default function Level11() { console.log('renderLevel11'); const [count, setCount] = useState(0); const intervalRef = useRef(null); const start = useCallback(() => { if (intervalRef.current !== null) { return; } intervalRef.current = setInterval(() => { setCount((c) => c + 1); }, 500); }, []); const stop = useCallback(() => { if (intervalRef.current === null) { return; } clearInterval(intervalRef.current); intervalRef.current = null; }, []); return (
count => {count}
); } ``` To enable React.memo to do its job properly, all we need to do it to memoize functions, using useCallback hook. This way, same reference will be provided after each render. This code has **no resource leaks**, is **implemented correctly**, has **no performance problem**, but code is **quite complex,** even for a simple counter. 🔗 [Hooks API Reference](https://reactjs.org/docs/hooks-reference.html): [useCallback](https://reactjs.org/docs/hooks-reference.html#usecallback) #### Level 12: custom hook ```javascript function useCounter(initialValue, ms) { const [count, setCount] = useState(initialValue); const intervalRef = useRef(null); const start = useCallback(() => { if (intervalRef.current !== null) { return; } intervalRef.current = setInterval(() => { setCount(c => c + 1); }, ms); }, []); const stop = useCallback(() => { if (intervalRef.current === null) { return; } clearInterval(intervalRef.current); intervalRef.current = null; }, []); const reset = useCallback(() => { setCount(0); }, []); return { count, start, stop, reset }; } ``` To **simplify code**, we need to encapsulate all complexity inside useCounter custom hook and expose clean api: `{ count, start, stop, reset }` . ```javascript export default function Level12() { console.log('renderLevel12'); const { count, start, stop, reset } = useCounter(0, 500); return (
count => {count}
); } ``` 🔗 [Hooks API Reference](https://reactjs.org/docs/hooks-reference.html): [Using a Custom Hook](https://reactjs.org/docs/hooks-custom.html#using-a-custom-hook) --- ### React Hooks Radar ![](https://cdn-images-1.medium.com/max/1600/0*Px-sg5tvCOOlPcJb.jpeg) All React Hooks are equal, but some hooks are **more equal** than others. #### ✅ Green Green hooks are main building blocks of modern React applications. They are safe to use almost everywhere without much thinking. 1. [useReducer](https://reactjs.org/docs/hooks-reference.html#usereducer) 2. [useState](https://reactjs.org/docs/hooks-reference.html#usestate) 3. [useContext](https://reactjs.org/docs/hooks-reference.html#usecontext) #### 🌕 Yellow Yellow hooks provide useful performance optimizations by using memoization. Managing lifecycle and inputs should be done with caution. 1. [useCallback](https://reactjs.org/docs/hooks-reference.html#usecallback) 2. [useMemo](https://reactjs.org/docs/hooks-reference.html#usememo) #### 🔴 Red Red hooks interact with mutable world using side effects. They are most powerful and should be used with extreme caution. Customs hooks are recommended for all non-trivial use-cases. 1. [useRef](https://reactjs.org/docs/hooks-reference.html#useref) 2. [useEffect](https://reactjs.org/docs/hooks-reference.html#useeffect) 3. [useLayoutEffect](https://reactjs.org/docs/hooks-reference.html#uselayouteffect) --- ### React Hooks Checklist ![](https://cdn-images-1.medium.com/max/1600/0*yDzaJvKh8gKFHiGH.jpg) 1. Obey [Rules of Hooks](https://reactjs.org/docs/hooks-rules.html). 2. Don’t do any side-effects in main render function. 3. Unsubscribe/dispose/destroy all used resources. 4. Prefer useReducer or functional updates for useState to prevent reading and writing same value in a hook. 5. Don’t use mutable variables inside render function, use useRef instead. 6. If what you save in useRef has smaller lifecycle than the component itself, don’t forget to unset the value when disposing the resource. 7. Be cautions with infinite recursion and resource starvation. 8. Memoize functions and objects when needed to improve performance. 9. Correctly capture input dependencies (undefined => every render, [a, b] => when a or b change, [] => only once). 10. Use customs hooks for non-trivial use-cases. ### GitHub Repo [**sdolidze/react-hooks-interval**](https://github.com/sdolidze/react-hooks-interval) ]]> https://hungvn.com/blog/tim-hieu-chi-tiet-ve-react-hooks https://hungvn.com/blog/tim-hieu-chi-tiet-ve-react-hooks Wed, 01 May 2019 14:35:00 GMT <![CDATA[Mẫu thiết kế React nâng cao P3: Render Props]]> https://hungvn.com/blog/mau-thiet-ke-react-nang-cao-p3-render-props https://hungvn.com/blog/mau-thiet-ke-react-nang-cao-p3-render-props Thu, 25 Apr 2019 13:45:00 GMT <![CDATA[Mẫu thiết kế React nâng cao P2: Context API]]> ); } } export default App; ``` The reason we are able to this is because we used some React API helper functions to pass the desired props to each child in the tree ; the ‘stage’ and ‘handleClick’ props are accessible to the components that need them. ![](https://cdn-images-1.medium.com/max/1600/1*14Xc1evO1VUe7ZbtaswMWA.png) There is one major flaw with this technique though. Props are only able to be passed down to their direct children. This makes the API very rigid and the ‘Stepper.Steps’ component has to be a direct child of the ‘Stepper’ component otherwise it will break. This has massive implications in terms of flexibility. What if we wanted to go a bit crazy and use a bit of flexbox magic to add a title? ```javascript class App extends Component { render() { return (
); } } ``` ![](https://cdn-images-1.medium.com/max/1600/1*Qd-eBIPrVF9yUx2SlHMb6g.png) By adding a simple div we completely break the component. The ‘Stepper.Steps’ component is no longer a direct child of the ‘Stepper’ component and is therefore unable to receive its props. Wouldn’t it be great to have the flexibility to add small adjustments when ever we wanted? Context to the Rescue!! ### React Context API React Context has been around a while but React’s engineers made it very clear it was experimental and would likely break in the near future. The great news is that as of React 16.3, this is now stable and can be used throughout your React applications. So what is this Context we keep hearing about? I couldn’t come up with a clearer definition than the one in React’s official documentation: > Context provides a way to pass data through the component tree without having to pass props down manually at every level. This is exactly what we need to solve our problem! Using Context, we no longer need to loop through and clone each child to pass down required props. Context is designed so that we can share ‘global’ state that can be shared anywhere in the React tree. ![Using Context, all of our components have access to the ‘stage’ and ‘handleClick’ props.](https://cdn-images-1.medium.com/max/1600/1*ceym3XmxMn8phkR5yk5HCg.png) So, let me guide you through the Context API, and the steps you need to take to get it up and running. ### 1: Create a new context React now comes with a method called ‘createContext’. All we need to do is simply call this method and assign it to a variable. ```javascript export const StepperContext = React.createContext(); ``` The new context we created provides us access to a Provider and Consumer pair. The Provider, believe it or not, provides the ability for us to share state changes throughout our React Tree. The Consumer allows us to subscribe to these state changes anywhere in the tree. ### 2\. Create Context Provider Our Context we just created has a Static Class method called ‘Provider’ that creates a React component. This component accepts a value property. This is extremely important as it is this property that will represent our global state that we need to pass to components further down in the tree. In our case all we want to share globally is the ‘stage’ prop and ‘handleClick’ method. By using the props.children technique that we used in the first part of this series, we can dynamically expose any child components to the Provider, regardless of how deep it is in the tree. ```javascript class StepperProvider extends Component { state = { stage: 1, }; render() { return ( this.setState({ stage: this.state.stage + 1, }), }} > {this.props.children} ); } } ``` ### 3\. Wrap our Provider around our Stepper Component By simply wrapping the ‘StepperProvider’ component around our original ‘Stepper’ component, any child components further down the tree now have exposure to our context. ```javascript class App extends Component { render() { return ( ); } } ``` As it stands our Stepper code looks almost identical, however by simply wrapping it in the StepperProvider component all of our child Components will have access to ‘stage’ and ‘handleClick’ without manually drilling them down to each component. ### 4\. Refactor our components Originally, our state was managed by the Stepper component and we cloned each child element to be able to receive the props required. ```javascript class Stepper extends Component { state = { stage: this.props.stage, }; static defaultProps = { stage: 1, }; static Progress = Progress; static Steps = Steps; static Stage = Stage; static Step = Step; handleClick = () => { this.setState({ stage: this.state.stage + 1 }); }; render() { const { stage } = this.state; const children = React.Children.map(this.props.children, child => { return React.cloneElement(child, { stage, handleClick: this.handleClick, }); }); return
{children}
; } } ``` Almost all of this code is no longer required. We no longer need to create state, and we no longer need to pass down any props. We could do away with this code altogether but it’s a good place to declare our static methods to create a clean, readable API. ```javascript class Stepper extends Component { static Progress = Progress; static Steps = Steps; static Stage = Stage; static Step = Step; render() { return
{children}
; } } export default Stepper; ``` ### 5\. Subscribe to state changes using a Consumer I will use the the Stepper.Step component to demonstrate how to wire up the Consumer component. Previously, the Stepper.Step component required its parent to directly pass down the stage prop in order for it to function properly: ```javascript export const Step = ({num, text,stage}) => ( return stage === num ?
{text}
: null ) ``` With our application wired up with Context we no longer need this as a prop. We can use the Consumer to subscribe to it instead: ```javascript {value => /* render something based on the context value */} ``` The Consumer requires a function as a child and provides this function with our global context value. When the function is complete, it returns a react node. What on earth does that mean? It’s a bit of a head scratcher at first but lets take a look at the ‘consumed’ Step component. ```javascript export const Step = ({ num, text }) => ( {value => { const { stage } = value; return stage === num ? (
{text}
) : null; }} ); ``` Instead of adding the ‘Step’ markup directly as a child to the Consumer, we instead add a function. This function provides the values we created from our Provider earlier and we can then use ES6 destructuring to pull off the stage prop. The ‘Step’ component now has access to the stage prop like before but this time it is pulled from the context. from here we are free to do with it as we wish; in this case we use it to determine what React node is returned. The technique being used here may seem a little strange. It is called _render props_ and the [official react docs explain it here](https://reactjs.org/docs/render-props.html). This is an extremely powerful technique that I’ll be talking about in part 3 of this series. ### 6\. Repeat Stages 4 & 5 for all components that either require props or pass down props I wont go into step by step detail here but by repeating stages 4 & 5 for the Stepper.Steps, Stepper.Progress and Stepper.Stage components you should end up with your component looking and functioning exactly the same as before. `codesandbox: yjm2563jz9` None of our components are now reliant on being direct descendants of others. Boom! We now have much more flexible code and should be able to add the heading we were unable to do earlier! ```javascript class App extends Component { render() { return (
); } } ``` The Stepper.Steps and Stepper.Step are no longer pulling the ‘stage’ prop directly from their parents. They are subscribing to it from context so the extra div in place is not blocking props being passed further down the tree. The App still works! ![](https://cdn-images-1.medium.com/max/1600/1*ceym3XmxMn8phkR5yk5HCg.png) This now gives us a huge amount of flexibility. We can reuse our component to dynamically create complex variations of our Stepper component without worrying if our Application will break `codesandbox: lp6mn91557` Although we can use this component anywhere in our application, it’s still not truly reusable.We still need the boilerplate of context in order for it to work. In the next part of this series I will discuss how we can use render props to achieve the same goals without having to rely on wiring up context to share state between components in our application. ]]> https://hungvn.com/blog/mau-thiet-ke-react-nang-cao-p2-context-api https://hungvn.com/blog/mau-thiet-ke-react-nang-cao-p2-context-api Wed, 24 Apr 2019 10:15:00 GMT <![CDATA[Mẫu thiết kế React nâng cao P1: Compound Components]]> ; } } export default App; ``` As you can see, the ‘Stepper’ component’s flexibility ends at the stage prop; we are only able to change the stage to where it starts. What if I need to position the progress block on the right hand side? What if I need a similar Stepper with extra stages? What if I need to change the content of the stages? What if I wanted to change the order of the stages? As it stands, the only way I could I achieve these changes is by completely re-writing the component. Re-writing it in the same fashion would yield a similar outcome. However, if more changes are needed again in the future, the component would need to be re-written again. So, let’s try a different approach and rewire the component so it has flexibility and reusability to be used in any future configurations. In the first part of this series we will discuss a design pattern called “Compound Components” ### Using the Compound Component design pattern To start, let’s take a look at the ‘Stepper’ component. ```javascript class Stepper extends Component { state = { stage: this.props.stage, }; static defaultProps = { stage: 1, }; handleClick = () => { this.setState({ stage: this.state.stage + 1 }); }; render() { const { stage } = this.state; return (
); } } export default Stepper; ``` The ‘Stepper’ component is basically a component that contains a state object which stores the current stage, a method that increases value of the stage property, and a render method that returns a div with 2 child components. Currently, we are explicitly placing the ‘Progress’ and ‘Steps’ components directly inside the ‘Stepper’ component. To alleviate this static approach we can use the props object to dynamically inject the child components. ![](https://cdn-images-1.medium.com/max/1600/1*m9qWcyCa_j9DRnITVN5Uwg.png) Using this alternative approach, we can instead use the props.children object inside the Stepper.js file and place the ‘Progress’ and ‘Steps’ components inside the ‘Stepper’ component. Just this simple change gives us instant benefits. We can now choose which component in the tree is rendered first; we can choose if the progress block is on the left or the right hand side. There is one major problem with this approach, however. The ‘Progress’ and ‘Steps’ components no longer have access to the ‘stage’ and ‘handleClick’ props. In order for each child component to receive the props they need, we need to manually loop through the each child and inject the props inside them. We can do that using a number of helper methods provided by the react API. Two options include:- Children.map() and cloneElement(). ```javascript const children = React.Children.map(this.props.children, child => { return React.cloneElement(child, { stage, handleClick: this.handleClick }); }); ``` The Children.map() is similar to the Array.map() method. It is needed because the children.props has an opaque data structure making the Array.map() method unsuitable for this use case. The cloneElement does as the name suggests and clones the child component passed into it. Crucially, it also comes with the added ability of injecting extra props. Boom! ```javascript // Render method of Stepper.js const { stage } = this.state; const children = React.Children.map(this.props.children, child => { return React.cloneElement(child, { stage, handleClick: this.handleClick }); }); return
{children}
; ``` Now we can add the ‘Progress’ and ‘Stage’ as children to the ‘Stepper’ component and everything works the same as before. This time we can decide the position of each component, or if we want to be really crazy, we could have a progress block on both sides. ```javascript import React, { Component } from "react"; import Stepper from "./Stepper"; import Progress from "./components/Progress"; import Steps from "./components/Steps"; class App extends Component { render() { return (
); } } export default App; ``` ### Static Properties Another cool technique to improve readability and ease of use is using static properties of classes. This allows us to call methods directly on the class. What on earth does this mean? Lets take a look…. First, we need to create static methods inside the Stepper component and assign them to the ‘Progress’ and ‘Steps’ components: ```javascript static Progress = Progress static Steps = Steps ``` So now, instead of us importing the Progress and Steps components in numerous places we can instead call them directly from the Stepper component: ```javascript import React, { Component } from "react"; import Stepper from "./Stepper"; class App extends Component { render() { return ( ); } } export default App; ``` We have started to generate a simple, readable API that is somewhat flexible. Why not use some of the same techniques for the ‘Progress’ component? Lets take a look at it… ```javascript export default class Progress extends Component { render() { const { stage } = this.props; return (
); } } ``` You may notice that its rigidity is very similar to the Stepper component we looked at before. Let’s replace the 4 Stage components with the more dynamic children.props object, loop through the children adding the required props and then add a static method so it can called directly from the Stepper class. ```javascript export default class Progress extends Component { render() { const { stage } = this.props; const children = React.Children.map(this.props.children, child => { return React.cloneElement(child, { stage }); }); return
{children}
; } } ``` Once that is done we can dynamically add as many Stage components as we want in whatever position we want: ```javascript import React, { Component } from "react"; import Stepper from "./Stepper"; class App extends Component { render() { return ( ); } } export default App; ``` We can do the same thing with the Steps component although this one is a little trickier as each child needs to be wrapped in a [React’s Transition Group](https://reactcommunity.org/react-transition-group/) Transition component. The same loop technique will need to be applied, but the component will only be visible if the stage prop matches the component’s num prop. If there is a match, its wrapped in a Transition component (the ReactTransitionGroup docs explain the purpose of this) and is rendered on screen. ```javascript class Steps extends Component { render() { const { stage, handleClick } = this.props; const children = React.Children.map(this.props.children, child => { console.log(child.props); return ( stage === child.props.num && ( {child} ) ); }); return (
{children}
); } } export default Steps; ``` By adding the relevant static methods on the Stepper.js component we can add as many Step components as we want, in what ever order we want. ```javascript import React, { Component } from "react"; import Stepper from "./Stepper"; class App extends Component { render() { return ( ); } } export default App; ``` We have created a way more flexible and reusable component. We can now choose how many stages, what text will go in each stage, the order of each stage, and whether we would like the progress bar on the left or the right. `codesandbox: 5x22900pnl` We are still constrained in terms of flexibility though! What if we wanted to add a title block just above the Steps block? ```javascript class App extends Component { render() { return (
Title
 ); } } export default App; ``` This would break our application as the ‘Stepper.Steps’ component is no longer a direct child of the ‘Stepper’ component and does not have access to the stage prop. This is why the release of React 16.3 is quite a big deal! Up until now, React’s context API was in an experimental phase but now it’s been made official! In Part 2 of this series I will discuss how we can implement the context API to be able to pass down props anywhere in the tree, so regardless of where the ‘Stepper.Steps’ component is positioned it will always be able to access the stage prop. ]]> https://hungvn.com/blog/mau-thiet-ke-react-nang-cao-p1-compound-components https://hungvn.com/blog/mau-thiet-ke-react-nang-cao-p1-compound-components Sat, 20 Apr 2019 12:50:00 GMT <![CDATA[Các mẫu thiết kế trong phát triển JavaScript hiện đại]]> Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. In software development, architecture is the process of constructing an application in a healthy, robust and maintainable way and patterns provide a way of giving names to solutions for common problems. These solutions can range from abstract/conceptual to very precise and technical and allow developers to effectively communicate with each other. ![Efficient.](https://cdn-images-1.medium.com/max/2400/1*pdCoxUhmMHI5tBnGVdnNJQ.jpeg) If two or more developers on a team are knowledgeable about patterns, talking about solutions to problems becomes very efficient. If only one developer knows about patterns, explaining them to the rest of the team is usually easy. **The goal of this article is to whet your appetite for a somewhat formal representation of knowledge in software development by introducing you to the idea of software design patterns and presenting a couple of patterns which are interesting because they get used considerably in modern JavaScript projects.** ### Singleton pattern #### The what The singleton pattern isn’t one of the most widely used ones, but we’re starting here because it’s relatively easy to grasp. The singleton pattern stems from the mathematical concept of a singleton which is: > In mathematics, a **singleton**, also known as a **unit set**, is a set with exactly one element. For example, the set {null} is a singleton. In software, it simply means that we limit the instantiation of a class to a single object. The first time an object of a class implementing the singleton pattern should be instantiated, it is actually going to get instantiated. Any subsequent try is just going to return that first instance. ![Who needs two superheroes when there is Batman?](https://cdn-images-1.medium.com/max/2400/1*JsnR25Uewd4wZLzZ-a9frg.png) #### The why Apart from allowing us to only have one superhero ever (which would obviously be Batman), why would we ever use the singleton pattern? Although the singleton pattern isn’t without its problems (it’s been called evil before with singletons being [called pathological liars](http://misko.hevery.com/2008/08/17/singletons-are-pathological-liars/)), it still has its uses. The most notable one would be for instantiating configuration objects. You probably only want one configuration instance for your application, unless a feature of your application is providing multiple configurations. #### The where Angular’s services are a prime example of the singleton pattern being used in a big popular framework. There is a [dedicated page in Angular’s documentation](https://angular.io/guide/singleton-services) explaining how to make sure that a service is always provided as a singleton. Services being singletons makes a lot of sense, since services are used as a place to store state, configuration and allow communication between components and you want to make sure that there aren’t multiple instances messing up these concepts. As an example, let’s say that you have a trivial application which is used for counting how many times buttons have been clicked. ![](https://cdn-images-1.medium.com/max/2400/1*PZpt4afyPY10CnuRADJx5w.png) You should keep track of the number of button presses in one object which provides: - the functionality of counting - and providing the current number of clicks. If that object wasn’t a singleton (and the buttons would each get their own instance) the click count wouldn’t be correct. Also, which of the counting instances would you provide to the component showing the current count? ### Observer pattern #### The what The observer pattern is defined as follows: > The **observer pattern** is a software design pattern in which an object, called the **subject**, maintains a list of its dependents, called **observers**, and notifies them automatically of any state changes, usually by calling one of their methods. It’s really easy to understand the observer pattern if we try comparing it to an example in the real world — newspaper subscriptions. The usual scenario when buying a newspaper is that you walk to the newsstand and ask if the new issue of your favourite newspaper is out. If it isn’t, it’s a sad affair of inefficiency where you have to walk home and try again later. In JavaScript terms, this would be the same as looping until you get the desired result. When you finally get your hands on the newspaper, you can do what you meant to do the whole time — sit down with a cup of coffee and enjoy your newspaper (or, in JavaScript terms, execute the callback function that you wanted to do the whole time). ![Finally.](https://cdn-images-1.medium.com/max/2400/1*arrsn5kxG1GRbVpn7tlZkw.jpeg) The smart thing to do (and get your beloved newspaper each day) would be to subscribe to the newspaper. That way, the publishing company would let you know when a new issue of the newspaper is out and deliver it to you. No more running to the newsstand. No more disappointment. Bliss. In JavaScript terms, you wouldn’t be looping and asking for the result until you run a function any more. You would, instead, let a subject know that you are interested in events (messages) and would provide a callback function which should be called when new data is ready. You are, then, the observer. ![Never miss your morning paper again.](https://cdn-images-1.medium.com/max/2400/1*Umz-GYQk5skILT07e0Kr4A.png) The nice thing is — you don’t have to be the only subscriber. As you would be disappointed by missing your newspaper, so would other people, too. That’s why multiple observers can subscribe to the subject. #### The why The observer pattern has many use cases but generally, it should be used when you want to create a one-to-many dependency between objects which isn’t tightly coupled and have the possibility to let an open-ended number of objects know when a state has changed. JavaScript is a great place for the observable pattern because everything is event-driven and, rather than always asking if an event happened, you should let the event inform you (like the old adage _“Don’t call us we’ll call you”_). Chances are you already did something which looks like the observer pattern — addEventListener. Adding an event listener to an element has all the markings of the observer pattern: - you can subscribe to the object, - you can unsubscribe from the object, - and the object can broadcast an event to all its subscribers. The big payoff from learning about the observer pattern is that you can implement your own subject or grasp an already existing solution much faster. #### The where Implementing a basic observable shouldn’t be too hard, but there is a great library being used by many projects and that’s [ReactiveX](http://reactivex.io/) of which [RxJS](https://github.com/ReactiveX/rxjs) is its JavaScript counterpart. RxJS allows you not only to subscribe to subjects, but also gives you the possibility of transforming the data in any way you can imagine, combining multiple subscriptions, making asynchronous work more manageable and much much more. If you ever wanted to bring your data processing and transformation level to a higher level, RxJS would be a great library to learn. Apart from the observer pattern, ReactiveX also prides itself with implementing the iterator pattern which gives subjects the possibility of letting its subscribers know when a subscription ended, effectively ending the subscription from the subject’s side. I am not going to be explaining the iterator pattern in this article, but it would be a great exercise for you to learn more about it and see how it fits in with the observable pattern. ### Facade pattern #### The what The facade pattern is a pattern which takes its name from architecture. In architecture: > A **facade** is generally one exterior side of a building, usually the front. It is a foreign loan word from the French _façade_, which means “frontage” or “face”. As the facade in architecture is an exterior of the building, hiding its inner workings, the facade pattern in software development tries to hide the underlying complexity behind a front, effectively allowing you to work with an API which is easier to grasp while providing the possibility to change the underlying code however you want. #### The why You can use the facade pattern in a myriad of situations but the most notable ones would be to make your code easier to understand (hide complexity) and to make dependencies as loosely coupled as possible. ![Fus Ro Dah!](https://cdn-images-1.medium.com/max/2400/1*Unh3rSLKfaMzs3gweZF7UQ.png) It is easy to see why a facade object (or layer with multiple objects) would be a great thing. You don’t want to be dealing with dragons if it can be avoided. The facade object is going to provide you a nice API and deal with all the dragon shenanigans itself. Another great thing that we can do here is change out the dragon from the background without ever touching the rest of the application. Let’s say that you want to change that dragon out with a kitten. It still has claws, but is much easier kept fed. Changing it out is a matter of rewriting the code in the facade without changing any of the dependent objects. #### The where A place where you will see facades often is Angular using its services as a means of simplifying background logic. But it doesn’t have to only be Angular, as you will see in the next example. Let’s say that you want to add state management to your application. You could take Redux, NgRx, Akita, MobX, Apollo or any of the new kids on the block that have been popping up left and right. Well, why not choose them all and take them for a spin? What are the basic functionalities a state management library is going to provide you? Probably: - a way of letting the state management know that you want a state change - and a way of getting the current (slice of) state. That doesn’t sound too bad. Now, with the power of the facade pattern under your belt, you can write facades for each part of the state which are going to provide a nice API for you to work with — something like facade.startSpinner(), facade.stopSpinner() and facade.getSpinnerState(). These methods are really easy to understand and reason about. After that, you can tackle the facade and write the code which is going to transform your code so that it works with Apollo (managing state with GraphQL — so hot right now). You may notice that it doesn’t suit your coding style at all or that the way unit tests have to be written really isn’t your cup of tea. No problem, write a new facade which is going to support MobX. ![Might as well be dragons…](https://cdn-images-1.medium.com/max/2400/1*O3pSZ9xOfBkk7lO0CtGCPA.png) ### Where to go from here You’ve probably noticed that there was no code or implementation of the design patterns I’ve talked about. That’s because each of these design patterns could be at least a chapter in a book for itself. Now that we’re talking about books, it wouldn’t hurt to take a look at one or two dealing with design patterns in depth. The first and biggest recommendation has to be [**Design Patterns: Elements of Reusable Object-Oriented Software**](http://wiki.c2.com/?DesignPatternsBook)by _Erich Gamma_, _Richard Helm_, _Ralph Johnson_, and _John Vlisside_ also known as the _Gang of Four_. The book is a gold mine and the _de facto_ bible of software design patterns. If you are looking for something that’s a bit easier to digest, there is [**Head First Design Patterns**](https://www.goodreads.com/book/show/58128.Head_First_Design_Patterns) by _Bert Bates_, _Kathy Sierra_, _Eric Freeman_ and _Elisabeth Robson_. It’s a very nice book which tries to convey the message of design patterns through a visual perspective. **Last but not least, nothing beats just Googling, reading and trying out different approaches. Even if you end up never using a pattern or technique, you’ll learn something and grow in ways you never expected.** ]]> https://hungvn.com/blog/cac-mau-thiet-ke-trong-phat-trien-javascript-hien-dai https://hungvn.com/blog/cac-mau-thiet-ke-trong-phat-trien-javascript-hien-dai Fri, 12 Apr 2019 20:35:00 GMT <![CDATA[Băm và lưu password đúng cách]]> điểm chung là ta cần **thử** và **đoán** password nhiều lần cho tới khi đúng cái cần tìm. Một cách khác đó là ta có thể **tính toán trước** giá trị hash của tất cả các trường hợp và của tất cả các thuật toán -> cách này khó, tốn thời gian, nhưng bây giờ với tốc độ tính toán của máy tính, ta vẫn có thể làm được. Bảng lưu trữ password + hash_value của password gọi là **[Rainbow Table](http://project-rainbowcrack.com/table.htm)**, có thể tự tạo hoặc tải một số bản miễn phí hoặc trả tiền để mua. Từ bây giờ nếu ta có hash_value ta có thể mapping để suy ra được password. Tuy nhiên nếu ta chỉ hash mỗi password, ta gặp vấn đề đó là: - **2 password giống nhau** (user vô tình trùng password) thì chuỗi `hash(password)` sẽ giống nhau. - User cố tình đặt password đơn giản và phổ biến (ví dụ password < 4 kí tự, toàn số, toàn chữ) -> dễ nhớ cho user nhưng dễ tra ngược. Và nếu chỉ hash password thì nếu mất hash_value, có thể tra trong rainbow table để tìm ra được password của người dùng. Giờ ta thử thay vì `hash(password)` ta sẽ `hash(salt + password)`: Từ `md5(123456)` ``` id | hash_md5 | --------------------------------------- 1 | e10adc3949ba59abbe56e057f20f883e | ``` Thành `md5(7nWZLcCK0vsPzIM + 123456)` ``` id | hash_md5 | salt | --------------------------------------------------------- 1 | 0510210d4b370165658bdc0d0b005244 | 7nWZLcCK0vsPzIM | ``` Giờ giả sử, ta mất bảng dữ liệu gồm `hash_md5, salt`, kẻ tấn công sẽ phải **tính toán lại** rainbow table của tất cả các trường hợp cộng với salt. Nếu salt là random cho từng user, kẻ tấn công sẽ phải tính toán toàn bộ trường hợp cộng với riêng từng salt cho toàn bộ user. Chi phí cho 2 phép tính trên là vô cùng lớn và tốn rất nhiều thời gian để thực hiện. Vậy tóm lại mục đích của salt và random-salt là: - Bảo vệ user kể cả khi user dùng password phổ biến và password không mạnh vì user không thể nhớ được các password phức tạp nhưng tốc độ tính toán của máy tính thì càng ngày càng nhanh. - Tạo ra nhiều chi phí tính toán, kẻ tấn công không thể tính toán trước rainbow table. \=> Ta trả lời đc 3 câu hỏi: - Salt có thể lưu trong database, cùng với hash_value. - Không cần tìm cách giữ bí mật salt, nhưng cũng đừng **tự ý công khai** salt. - Nhưng bắt buộc phải random salt cho từng user. ## 3\. Hash ở đâu? Giờ giả sử `hash(password)` ở client-side thì vấn đề là gì? - Biết được thuật toán dùng để hash. - Salt sẽ phải sinh ra ở client, vì ta cần hash password với salt (`hash(salt + password)`), và db chỉ lưu kết quả hash, không lưu salt. - Nhưng nếu salt sinh ra ở client và salt random thì làm sao để compare với hash_value trong database? Vì lần chứng thực tới, salt sẽ lại random và sẽ khác với kết quả trong database -> salt phải duy nhất cho tất cả các trường hợp. - Hoặc salt có thể lưu ở DB, nhưng server phải gửi salt về trước cho user trước khi thực hiện hash -> dễ dàng biết được salt hơn. Nhìn sơ thì thấy việc dùng duy nhất một salt đã chống lại luận điểm ở mục số 2. Vậy quy trình chứng thực đúng là như thế nào? - User sẽ gửi plain-text password lên server và over HTTPs. - Server sẽ kiểm tra trong database lấy ra salt của user đó, cộng chuỗi ta được `salt + password`. - Thực hiện `hash(salt + password)` trên server side. - Compare kết quả trên với `hash_md5` trong database. ## 4\. Tại sao dùng bcrypt thay cho SHA-512 Kết quả của SHA-512 có độ dài 128 kí tự, độ dài của key là 64 bytes. Trông có vẻ cũng khá chắc chắn, vậy tại sao OWASP recommend sử dụng PBKDF2, bcrypt hoặc scrypt hơn là SHA2? SHA2 là hash algorithm (tất nhiên), nó được thiết kế với mục tiêu là tốc độ, với các CPU hiện đại, có thể generate hàng triệu kết quả trên giây. Nếu dùng một thuật toán có tốc độ như SHA2 tức là bạn đã đem lợi điểm tới cho kẻ tấn công brute-force. Thuật toán nhanh + cấu hình server mạnh, việc brute-force càng trở lên nhanh chóng hơn. Trong khi đó, bcrypt được gọi là slow-hash algorithm, `bcrypt()` mất 100ms để tính toán ra chuỗi hash, chậm hơn 10.000 lần so với sha1(). Có nghĩa là vẫn đạt được mục đích hash nhưng giảm thiểu nguy cơ tấn công brute-force. **Tóm lại**: SHA-512 không phải là một thuật toán yếu, mà vấn đề là SHA-512 không phù hợp cho việc hash password. Nếu cần hash password thì ta nên dùng các thuật toán slow hash như PBKDF2, bcrypt và scrypt. ## 5\. Tại sao cần Pepper? Một thực tế là nếu bạn chỉ có “muối” mà không có “tiêu”, ăn thịt gà luộc sẽ không ngon :v. Giả sử, database bạn chạy RAID-1, một ổ cứng hư và cần thay một ổ cứng mới. Nhưng như ta biết, đĩa bị hư là mirror của đĩa còn lại, bạn phải tiêu hủy ổ cứng hư đó nếu không ai đó có thể lục thùng rác và tái tạo lại một phần dữ liệu trong đĩa hư đó. Xin lưu ý, bạn cần `wipe` trước khi vứt bỏ một ổ cứng có dữ liệu dù cá nhân hay server, tuy nhiên đĩa bị sốc điện, bad-sector thì `wipe` cũng chưa đủ an toàn, tốt nhất nên ngiền ra bã. Dù random-salt đã làm tăng chi phí tạo ra rainbow table nhưng đời không biết đâu mà lần, kẻ tấn công luôn có những động lực không tưởng để đạt được cái mình muốn. Giả sử kẻ tấn công có một siêu siêu máy tính và một mirror ổ cứng hư lục từ một cái thùng rác nào đó. Với siêu máy tính đó, ta có rainbow-table để tra ngược ra password cần tìm. Vậy làm sao để giảm thiểu nguy cơ trên? Nguyên tắc là không bỏ tất cả trứng trong một giỏ, đó là pepper. Pepper là một chuỗi tương tự như salt, nhưng khác biệt là ta cần **giữ bí mật pepper**, lưu ở một chỗ khác ngoài database, và không cần pepper-per-user, chỉ cần 1 pepper là đủ. Từ ``` hash(salt + password) ``` Thành ``` hash(pepper + salt + password) ``` Ta nên lưu pepper ở application hoặc ở một service khác, nếu database bị compromise, thì kẻ tấn công cũng không có pepper để tạo ra rainbow-table. ## 6\. Bonus ![dropbox-store-password](https://dropboxtechblog.files.wordpress.com/2016/09/layers.png) Trong khi tìm câu trả lời để viết bài này, mình tìm được một bài blog của dropbox nói về cách họ lưu password như thế nào. Thấy có 2 điểm khá hay nên muốn nói thêm. - Trước khi hash password với salt-per-user, họ có `SHA512(password)` trước để **cố định** độ dài của input-password. Theo Dropbox thì việc này giải quyết 2 issues của `bcrypt` - Một số implementation của bcrypt cắt đầu vào còn 72 bytes. - Một số implementation khác của bcrypt thì không cắt đầu vào nhưng dẫn tới một vấn đề khác là DoS attack bởi vì cho phép độ dài mật khẩu tùy ý. - Dropbox cũng có **global pepper** nhưng thay vì dùng nó để hash thì họ encrypt. Tức là thay vì `hash(pepper + salt + password)` thì họ `AES256(salt + password) + global-pepper-key`. Theo như họ giải thích thì pepper là một lớp phòng thủ sâu hơn và lưu trữ ở một nơi riêng biệt. Nhưng đồng nghĩa với việc là nơi lưu trữ pepper vẫn có thể bị compromise, và khi bị compromise thì việc rotate key không dễ dàng. Dùng pepper để encrypt vẫn đạt được mục đích bảo mật tương tự nhưng thêm khả năng rotate key khi bị compromise. ## 7\. Migrate Sau khi viết bài này, bạn [@vanhtuan0409](https://github.com/vanhtuan0409) có một câu hỏi về việc làm thế nào migrate một hệ thống dùng SHA1 –> bcrypt. Mình thấy đây là một điểm cũng khá cần thiết nên xin phép note thêm. Ở đây có 2 trường hợp: - Hash password bằng SHA1 nhưng không có salt -> mình gọi là `sha1_value`. - Hash password bằng SHA1 + trong DB có salt-per-user, mình có `sha1_value, salt`. Về ý tưởng thì ta sẽ dùng SHA1 như cách Dropbox dùng SHA512 để cố định độ dài input. Với trường hợp đầu ta cần sinh ra thêm salt-per-user và migrate `bcrypt(salt, sha1_value)` trong đó `sha1_value = SHA1(password)` -> Tương tự cách của dropbox, **may mắn** là do sai thiết kế từ đầu (thiếu salt) nên migrate dễ. Với trường hợp thứ 2 thì hơi lằng nhằng hơn 1 xíu, ta cần migrate kiểu `bcrypt(salt, SHA1(salt, password))` nếu thực sự muốn bcrypt với salt hoặc thực ra chỉ cần `bcrypt(SHA1(salt, password)` cũng được. Tùy tình huống bạn cần tradeoff có thể lựa chọn cách phù hợp. ## 8\. Thông tin của bạn có an toàn? Như ta thấy, ta đã làm rất nhiều thứ để đảm bảo rằng thông tin của chúng ta trở lên an toàn. Vậy thực sự thông tin của chúng ta đã an toàn hay không? Câu trả lời rất tiếc là KHÔNG? Thông tin của chúng ta có thể an toàn với “bên ngoài” nhưng không an toàn với “bên trong”. Tại sao lại vậy? Giờ bắt đầu với thông tin cơ bản nhất như địa chỉ, email, sở thích … Khi ta build staing environment, thông tin user được copy sang một môi trường khác, developer có thể overwrite hash_value của user bằng value của `hash(salt + 654321)` và dễ dàng đăng nhập trên staing environment với password là `654321` và tất cả các thông tin cơ bản của user đã có thể đọc được. Nhưng ít nhất developer vẫn không biết chính xác password của user là gì. Nhưng, lại là nhưng. Người quản trị hệ thống có mọi quyền trên server mà họ quản trị, password dù đã over HTTPs nhưng tới server vẫn là plain-text. Vẫn có thể capture request ngay ở đầu server và output ra plain-text password của user và cuối cùng thì người quản trị hệ thống vẫn biết được chính xác password của user là gì. Đó là lí do tại sao ta không nên dùng một password cho tất cả các dịch vụ. Vậy làm thế nào để bảo vệ info của user trong trường hợp này, rất tiếc về mặt kỹ thuật không có cách nào để đảm bảo việc này. Ta chỉ có thể áp dụng policy, NDA về mặt con người để hạn chế vấn đề này thôi. ## 9\. Ref - [https://security.stackexchange.com/questions/211/how-to-securely-hash-passwords](https://security.stackexchange.com/questions/211/how-to-securely-hash-passwords) - [https://blogs.dropbox.com/tech/2016/09/how-dropbox-securely-stores-your-passwords](https://blogs.dropbox.com/tech/2016/09/how-dropbox-securely-stores-your-passwords) **Lưu ý**: - Trong bài viết dùng MD5 để minh họa cho đơn giản, trong thực tế ta không dùng MD5. - Trong bài viết giả định kẻ tấn công bằng cách nào đó có db users, trong thực tế việc này rất khó do có các tầng bảo mật khác như thiết kế infrastructure, define rule/policy về con người … Trong bài này mình không bàn đến các vấn đề đó. ]]> https://hungvn.com/blog/bam-va-luu-password-dung-cach https://hungvn.com/blog/bam-va-luu-password-dung-cach Mon, 11 Mar 2019 15:35:00 GMT <![CDATA[Cách đặt breakpoints CSS chính xác nhất]]> “Is the medium breakpoint _up to_ 768px, or including 768? I see… and that's iPad landscape, or is that ‘large'? Oh, large is 768px _and up._ I see. And small is 320px? What is this range from 0 to 319px? A breakpoint _for ants_?” I could proceed to show you the correct breakpoints and leave it at that. But I find it very curious that the above method (“silly grouping”) is so widespread. Why should that be? I think the answer to this problem, like so many problems, comes down to misaligned terminology. After all, _waterboarding at Guantanamo Bay_ sounds super rad if you don't know what either of those things are. (Oh [I wish](https://www.reddit.com/r/Showerthoughts/comments/2ucx09/waterboarding_at_guantanamo_bay_sounds_super_rad/) that was my joke.) I think we mix up “boundaries” and “ranges” in our discussions and implementations of breakpoints. Tell me, if you do breakpoints in Sass, do you have a variable called `$large` that is, say, 768px? Is that the lower boundary of the range you refer to as large, or the upper boundary? If it's the lower, then you must have no $small because that should be 0, right? And if it's the upper boundary then how would you define a breakpoint `$large-and-up`? That must be a media query with a `min-width` of `$medium`, right? And if you are referring to just a boundary when you say large, then we're in for confusion later on because a media query is always a _range_. This situation is a mess and we're wasting time thinking about it. So I have three suggestions: 1. Get your break*points* right 2. Name your _ranges_ sensibly 3. Be declarative ### Tip #1: Get your breakpoints right So what are the _right_ breakpoints? Your kindergarten self already drew the circles. I'll just turn them into rectangles for you. ![](https://cdn-images-1.medium.com/max/2600/1*-ldpo5wcYVnuyRFbO24WPQ.png) 600px, 900px, 1200px, and 1800px if you plan on giving the giant-monitor people something special. On a side note, if you're ordering a giant monitor online, make sure you specify it's for a computer. You don't want to [get a giant lizard in the mail](http://metro.co.uk/2016/06/16/this-monster-lizard-at-the-door-is-absolutely-terrifying-5947737/). Those dots your channeled young self has been playing with actually represent the 14 most common screen sizes: ![image credit](https://cdn-images-1.medium.com/max/1600/1*199KbL2oM2P5d4pFMBXYxQ.png) So we can make a pretty little picture that allows for the easy flow of words between the folks dressed up as business people, designers, developers, and testers. ![I'm regretting my choice of orange and green, but I'm not redoing all of these pictures now.](https://cdn-images-1.medium.com/max/2400/1*7YeOvzoYgUEDJdfQy2ERXg.png) ### Tip #2: Name your ranges sensibly Sure, you could name your breakpoints [papa-bear and baby-bear](https://css-tricks.com/naming-media-queries/) if you like. But if I'm going to sit down with a designer and discuss how the site should look on different devices, I want it to be over as quickly as possible. If naming a size _portrait tablet_ facilitates that, then I'm sold. Heck, I'd even forgive you for calling it “iPad portrait.” “But the landscape is changing!” you may shout. “Phones are getting bigger, tablets are getting smaller!” But your website's CSS has a shelf life of about three years (unless it's Gmail). The iPad has been with us for twice that time, and it has yet to be dethroned. And we know that Apple no longer makes new products, they just remove things from existing ones (buttons, holes, etc). So 1024 x 768 is here to stay, folks. Let's not bury our heads in the sand. (Fun fact: ostriches don't live in cities because there is no sand, and thus nowhere to hide from predators.) Conclusion: communication is important. Don't purposefully detach yourself from helpful vocabulary. ### Tip #3: Be declarative I know, I know, that word “declarative” again. I'll put it another way: your CSS should define _what_ it wants to happen, not _how_ it should happen. The “how” belongs hidden away in some sort of mixin. As discussed earlier, part of the confusion around breakpoints is that variables that define a _boundary_ of a range are used as the _name_ of the range. $large: 600px simply makes no sense if large is a range. It's the same as saying var coordinates = 4;. So we can hide those details inside a mixin rather than expose them to be used in the code. Or we can do one better and not use variables at all. At first I did the below snippet as a simplified example. But really I think it covers all the bases. To see it in action, [check out this pen](http://codepen.io/davidgilbertson/pen/aBpJzO). I'm using Sass because I can't imagine building a site without it. The logic applies to CSS or Less just the same. ```scss @mixin for-phone-only { @media (max-width: 599px) { @content; } } @mixin for-tablet-portrait-up { @media (min-width: 600px) { @content; } } @mixin for-tablet-landscape-up { @media (min-width: 900px) { @content; } } @mixin for-desktop-up { @media (min-width: 1200px) { @content; } } @mixin for-big-desktop-up { @media (min-width: 1800px) { @content; } } // usage .my-box { padding: 10px; @include for-desktop-up { padding: 20px; } } ``` Note that I'm forcing the developer to specify the -up or -only suffix. > Ambiguity breeds confusion. An obvious criticism might be that this doesn't handle custom media queries. Well good news, everybody. If you want a custom media query, write a custom media query. (In practice, if I needed more complexity than the above I'd cut my losses and run into the loving embrace of [Susy](http://susydocs.oddbird.net/en/latest/toolkit/#breakpoint)'s toolkit.) Another criticism might be that I've got eight mixins here. Surely a single mixin would be the sane thing to do, then just pass in the required size, like so: ```scss @mixin for-size($size) { @if $size == phone-only { @media (max-width: 599px) { @content; } } @else if $size == tablet-portrait-up { @media (min-width: 600px) { @content; } } @else if $size == tablet-landscape-up { @media (min-width: 900px) { @content; } } @else if $size == desktop-up { @media (min-width: 1200px) { @content; } } @else if $size == big-desktop-up { @media (min-width: 1800px) { @content; } } } // usage .my-box { padding: 10px; @include for-size(desktop-up) { padding: 20px; } } ``` Sure, that works. But you won't get compile-time errors if you pass in an unsupported name. And to pass in a sass variable means exposing 8 variables just to pass to a switch in a mixin. Not to mention the syntax `@include for-desktop-up {...}` is totes more pretty than `@include for-size(desktop-up) {...}`. A criticism of both these code snippets might be that I'm typing out 900px twice, and also 899px. Surely I should just use variables and subtract 1 when needed. If you want to do that, go bananas, but there are two reasons I wouldn't: 1. These are not things that change frequently. These are also not numbers that are used anywhere else in the code base. No problems are caused by the fact that they _aren't_ variables — unless you want to expose your Sass breakpoints to a script that injects a JS object with those variables into your page. 2. The syntax is _nasty_ when you want to turn numbers into strings with Sass. Below is the price you pay for believing that repeating a number twice is the worst of all evils: ```scss @mixin for-size($range) { $phone-upper-boundary: 600px; $tablet-portrait-upper-boundary: 900px; $tablet-landscape-upper-boundary: 1200px; $desktop-upper-boundary: 1800px; @if $range == phone-only { @media (max-width: #{$phone-upper-boundary - 1}) { @content; } } @else if $range == tablet-portrait-up { @media (min-width: $phone-upper-boundary) { @content; } } @else if $range == tablet-landscape-up { @media (min-width: $tablet-portrait-upper-boundary) { @content; } } @else if $range == desktop-up { @media (min-width: $tablet-landscape-upper-boundary) { @content; } } @else if $range == big-desktop-up { @media (min-width: $desktop-upper-boundary) { @content; } } } // usage .my-box { padding: 10px; @include for-size(desktop-up) { padding: 20px; } } ``` Oh and since I've taken on a ranty tone over the last few paragraphs … I pity the fool who does something magical like store breakpoints in a Sass list and loop over them to output media queries, or something similarly ridiculous that future developers will struggle to decipher. > Complexity is where the bugs hide. Finally, you may be thinking “shouldn't I be basing my breakpoints on content, not devices?”. Well I'm amazed you made it this far and the answer is yes … for sites with a single layout. Or if you have multiple layouts and are happy to have a different set of breakpoints for each layout. Oh and also if your site design doesn't change often, or you're happy to update your breakpoints when your designs update since you'll want to _keep_ them based on the content, right? For complex sites, life is much easier if you pick a handful of breakpoints to use across the site. We're done! But this post has not been as furry as I would like, let me see if I can think of an excuse to include some… Oh, I know! ### Bonus tips for breakpoint development ![Yes, even flickr has breakpoints at 768 and 1400](https://cdn-images-1.medium.com/max/2400/1*ClU6ZZNLtd0ux8nqRPfhng.png) 1. If you need to experience CSS breakpoints for screen sizes bigger than the monitor you're sitting at, use the `responsive` mode in Chrome DevTools and type in whatever giant size you like. 2. The blue bar shows `max-width` media queries, the orange bar is `min-width` media queries, and the green bar shows media queries with both a min and a max. 3. Clicking a media query sets the screen to that width. If you click on a green media query more than once, it toggles between the max and min widths. 4. Right click a media query in the media queries bar to go to the definition of that rule in the CSS. --- Hey, thanks for reading! Comment with your tops ideas, I'd love the hear them. And click the little heart if you think I deserve it, or leave it hollow and empty, like my sense of self-worth will be if you don't. ]]> https://hungvn.com/blog/cach-dat-breakpoints-css-chinh-xac-nhat https://hungvn.com/blog/cach-dat-breakpoints-css-chinh-xac-nhat Fri, 22 Feb 2019 22:20:00 GMT <![CDATA[3 lỗi perfomance thường mắc phải với JavaScript]]> x)` are inferior to the veteran slice `arr.slice()` and concatenate `[].concat(arr)`. ```javascript Duplicate using Slice, average: ~367 microseconds Duplicate using Map, average: ~469 microseconds Duplicate using Spread, average: ~512 microseconds Duplicate using Concat, average: ~366 microseconds Duplicate using Array From, average: ~1,436 microseconds Duplicate manually, average: ~412 microseconds ``` #### **3\. Iterating Objects** Another frequent scenario is iterating over objects, this is mainly necessary when we try to traverse JSON’s and objects, and while not looking for a specific key value. Again there are the veteran solutions like the for-in `for(let key in obj)`, or the later `Object.keys(obj)` (presented in es6) and `Object.entries(obj)` (from ES8) which returns both key and value. Performance analysis of 10k objects iterations, each of which contains 1,000 random keys and values, using the above methods, reveals the following. ```javascript Object iterate For-In, average: ~240 microseconds Object iterate Keys For Each, average: ~294 microseconds Object iterate Entries For-Of, average: ~535 microseconds ``` The cause is the creating of the enumerable array of values in the two later solutions, instead of traversing the object directly without the keys array. But the bottom line result is still causing concerns. #### **Bottom Line** My conclusion is clear — if blazing fast performance is key for your application, or if your servers require to handle some load — using the coolest, more readable, cleaner options will blow a major punch to your application performance — which can get up to 10 times slower! Next time, before blindly adopting the slickest new trends, make sure they also align with your requirements — for a small application, writing fast and a more readable code is perfect — but for stressed servers and huge client-side applications, this might not be the best practice. ]]> https://hungvn.com/blog/3-loi-perfomance-thuong-mac-phai-voi-javascript https://hungvn.com/blog/3-loi-perfomance-thuong-mac-phai-voi-javascript Fri, 18 Jan 2019 21:20:00 GMT <![CDATA[Web Architecture 101]]> Người dùng search trên Google từ khóa “Strong Beautiful Fog And Sunbeams In The Forest”. Kết quả đầu tiên đến từ Storyblocks, trang stock và vector của chúng tôi. Người dùng click vào kết quả và được chuyển tiếp đến trang chi tiết về bức ảnh. Về cơ bản là trình duyệt của người dùng gửi một request đến server DNS để tìm cách liên hệ với Storyblocks, và sau đó gửi request. > > --- > > Request này sẽ gửi đến load balancer, và nó chọn ngẫu nhiên 1 trong số các web server chúng tôi đang chạy để xử lý request. Web server tìm thông tin về ảnh từ caching service và lấy dữ liệu còn lại từ database. Cũng lưu ý rằng "hồ sơ màu" của bức ảnh chưa được tính toán, nên chúng tôi gửi một job đến hàng đợi "job queue", và job server sẽ xử lý đồng bộ, đồng thời cập nhật database với kết quả có được sau khi xử lý. > > --- > > Tiếp đó, chúng tôi thử tìm những bức ảnh tương tự bằng cách gửi một request đến service "full text search" với đầu vào là tiêu đề bức ảnh. Người dùng tình cờ đăng nhập vào Storyblocks với tư cách thành viên thì chúng tôi tìm thông tin tài khoản từ "account service". Cuối cùng, chúng tôi bắn một sự kiện đến firehose để lưu lại trên hệ thống lưu trữ đám mây và load vào data warehouse, thứ sẽ được phân tích để trả lời những câu hỏi về business. > > --- > > Server render HTML view và gửi nó trở lại trình duyệt của người dùng, trước hết thông qua load balancer. Trang web chứa JavaScript và CSS được load từ hệ lưu trữ đám mấy, nó kết nối với CDN, nên trình duyệt của người dùng có thể liên hệ với CDN để nhận nội dung. Sau cùng, trình duyệt hiển thị trang web cho người dùng. Giờ tôi sẽ đi lần lượt từng thành phần, giới thiệu theo kiểu "101 ..." nhằm cung cấp cho bạn một mô hình chuẩn để suy nghĩ về kiến trúc web (web architecture) về sau. ### 1\. DNS DNS là viết tắt của "Domain Name Server" và nó là công nghệ xương sống để để www (world wide web) trở nên khả dĩ. Ở mức độ cơ bản thì DNS cung cấp một tham chiếu key/value từ domain name (chẳng hạn [google.com](http://google.com) ...) đến một địa chỉ IP (chẳng hạn 85.129.83.120 ...), giúp máy tính điều hướng request đến server tương ứng. Tương tự với số điện thoại, sự khác biệt giữa domain và địa chỉ IP chính là sự khác biệt giữa việc "gọi John Doe" và "gọi đến số 201-867-5309". Bạn cần một danh bạ để tìm số của John, và tương tự, bạn cần DNS để tìm địa chỉ IP cho domain (tên miền). Thế nên bạn có thể xem DNS là một cuốn danh bạ cho internet. Còn nhiều điều chi tiết hơn mà chúng ta có thể đề cập đến nhưng tôi sẽ bỏ qua vì nó không phải ở mức giới thiệu kiểu "101". P/S: 101 là gì thì đọc ở đây nhé [http://www.slate.com/articles/news_and_politics/explainer/2006/09/101_101.html](http://www.slate.com/articles/news_and_politics/explainer/2006/09/101_101.html) ### 2\. Load Balancer (Cân bằng tải) Trước khi đi sâu vào cân bằng tải, chúng ta cần thảo luận về "**horizontal scaling**" (mở rộng theo chiều ngang) và "**vertical scaling**" (mở rộng theo chiều dọc). Chúng là gì và khác nhau như thế nào? Đơn giản "horizontal scaling" nghĩa là mở rộng quy mô bằng cách thêm nhiều máy tính vào nguồn tài nguyên, trong khi "vertical scaling" nghĩa là tăng cường sức mạnh cho một máy tính đã có (chẳng hạn như CPU, RAM). Trong web development, gần như bạn luôn muốn mở rộng theo kiểu "horizontal". Vì, server có thể bỗng dưng bị chết, mạng gặp sự cố, toàn bộ trung tâm dữ liệu thường xuyên mất mạng. Có nhiều hơn một server cho phép bạn lập kế hoạch cho các sự cố để ứng dụng vẫn tiếp tục chạy (fault tolerant). Lý do thứ hai, "horizontal scaling" sẽ cho bạn kết hợp tối thiểu các phần backend khác nhau của ứng dụng (web server, database, service X, ...) bằng cách để chúng chạy trên nhiều server. Cuối cùng, bạn có thể mở rộng quy mô đến một mức mà "vertical scaling" không thể làm được. Đó là vì không có một máy tính nào trên thế giới đủ lớn để thực hiện tất cả tính toán cho ứng dụng. Hãy nghĩ nền tảng tìm kiếm của Google như một ví dụ điển hình (dù điều này ứng dụng cho các công ty ở quy mô bé hơn nhiều). **Storyblocks**, chạy từ 150 đến 400 AWS EC2 tại thời điểm viết bài này, để đạt được khối lượng tính toán ấy bằng "vertical scaling" là một thách thức rất lớn. Trở lại với cân bằng tải, chúng là ma thuật để mở rộng theo kiểu "horizontal", điều hướng _incoming request_ đến một trong nhiều server và gửi phản hồi từ server về client. Bất kỳ server nào cũng phải xử lý request theo cùng một cách, do đó chỉ còn lại một vấn đề là phân bổ request qua nhiều server để chúng không bị quá tải (overload). Vậy đó, khái niệm cân bằng tải khá đơn giản. Tất nhiên công nghệ nằm phía sau nó rất phức tạp nhưng không cần đề cập với phiên bản "101" làm chi. ### 3\. Web Application Servers Web server là nơi thực thi business logic, xử lý request của user và gửi lại HTML đến trình duyệt của user. Để làm việc đó, chúng kết nối với nhiều infra phía back-end như database, caching layer, job queue, search service, microservice, data/logging queue, ... Như đã đề cập ở trên, ít nhất 2 server thường được kết nối với cân bằng tải để xử lý request của người dùng. Bạn nên biết rằng triển khai server yêu cầu một ngôn ngữ cụ thể (Node.js, Ruby, PHP, Scala, Java, C# .NET, ...) và một web framework cho ngôn ngữ đó (Express, Ruby on Rails, Play, Laravel, ...). Tuy nhiên đi sâu vào chi tiết của những ngôn ngữ này nằm ngoài phạm vi của bài viết. ### 4\. Database Servers Mọi ứng dụng web hiện đại đều sử dụng một hoặc nhiều database để lưu trữ thông tin. Database cung cấp phương thức để định nghĩa cấu trúc dữ liệu, insert dữ liệu mới, tìm dữ liệu đã có, cập nhật hoặc xóa dữ liệu, thực hiện tính toán, ... Dù tôi tránh đào sao vào một công nghệ cụ thể cho mỗi thành phần của kiến trúc web, sẽ rất tệ nếu tôi không đề cập đến SQL và NoSQL. SQL là viết tắt của "Structured Query Language" (ngôn ngữ truy vấn có cấu trúc) được phát minh vào thập niên 70 của thế kỷ trước, cung cấp một chuẩn để truy vấn dữ liệu. SQL database lưu trữ dữ liệu theo bảng, được liên kết với nhau thường bằng ID. Hãy lấy một ví dụ cơ bản về lưu trữ địa chỉ của người dùng. Bạn có 2 bảng, _users_ và _user_addresses_, liên kết với nhau bằng id của người dùng. ![sql](646f6ef3-7806-4835-bc29-950c6532657b.png) NoSQL, nghĩa là "Non-SQL", là một công nghệ cơ sở dữ liệu mới hơn, dùng để xử lý khối lượng dữ liệu lớn được sinh ra bởi những ứng dụng web có quy mô lơn (hầu hết các biến thể của SQL không scale theo kiểu "horizontal" tốt và chỉ có thể scale theo kiểu "vertical" đến một mức độ nhất định). Nếu bạn không biết gì về NoSQL, tôi đề nghị xem những tài liệu dưới đây: - [https://www.w3resource.com/mongodb/nosql.php](https://www.w3resource.com/mongodb/nosql.php) - [http://www.kdnuggets.com/2016/07/seven-steps-understanding-nosql-databases.html](http://www.kdnuggets.com/2016/07/seven-steps-understanding-nosql-databases.html) - [https://resources.mongodb.com/getting-started-with-mongodb/back-to-basics-1-introduction-to-nosql](https://resources.mongodb.com/getting-started-with-mongodb/back-to-basics-1-introduction-to-nosql) ### 5\. Caching Service Một _caching service_ (dịch vụ lưu bộ nhớ đệm) cung cấp lưu trữ dữ liệu theo kiểu "key/value" đơn giản giúp nó tìm kiếm thông tin với thời gian gần như bằng 0\. Các ứng dụng thường tận dụng _caching service_ để lưu kết quả của những tính toán đắt đỏ để nhận kết của từ bộ nhớ đệm thay vì phải tính toán lại một lần nữa khi cần. Ứng dụng có thể cache kết quả của một truy vấn cơ sở dữ liệu, gọi đến một dịch vụ bên ngoài, cache HTML của một đường link, ... Dưới đây là một vài ví dụ thực tế: - Google lưu kết quả tìm kiếm cho những truy vấn thông thường như "dog" hoặc "Taylor Swift" để không phải tính toán lại mỗi lần - Facebook lưu nhiều dữ liệu bạn nhìn thấy khi đăng nhập, chẳng hạn bài viết, bạn bè... Bạn có thể đọc chi tiết về Facebook caching ở [đây](https://medium.com/@shagun/scaling-memcache-at-facebook-1ba77d71c082). - Storyblocks lưu HTML output, kết quả tìm kiếm, ... Hai công nghệ caching phổ biến nhất là Redis và Memcache. ### 6\. Job Queue & Servers Hầu hết ứng dụng web đều cần làm một số công việc bất đồng bộ ở phía back-end mà không kết hợp trực tiếp vào dữ liệu trả về cho người dùng. Chẳng hạn, Google cần crawl và index toàn bộ internet để trả về kết quả tìm kiếm. Nó không được làm mỗi lần bạn tìm kiếm. Thay vào đó, nó crawl các trang web một cách bất đồng bộ, và cập nhật index theo thời gian. Mặc dù có nhiều kiến trúc khác nhau cho các công việc bất đồng bộ, nhưng phố biến nhất là kiến trúc "job queue". Nó chứa 2 thành phần: một hàng đợi "job" cần được chạy, và một hoặc nhiều "job server" (hay còn lại là worker) để chạy job trong hàng đợi. Job queue chứa một danh sách job cần được chạy bất đồng bộ. Hàng đợi đơn giản nhất là FIFO (first in first out) mặc dù hầu hết ứng dụng sẽ cần một vài hàng đợi có ưu tiên. Mỗi khi ứng dụng cần chạy job thì nó chỉ cần thêm job đó vào hàng đợi. Storyblocks, chẳng hạn, tận dụng "job queue" để hỗ trợ rất nhiều công việc phía back-end nhằm phục vụ thị trường của chúng tôi. Chúng tôi chạy job để encode video và ảnh, xử lý file CSV, thống kê người dùng, gửi mật khẩu reset email, ... Lúc đầu chúng tôi sử dụng hàng đợi FIFO đơn giản, sau đó nâng cấp lên hàng đợi ưu tiên để đảm bảo rằng những hoạt động khẩn như gửi mật khẩu reset email được hoàn thành càng sớm càng tốt. Job server xử lý job. Chúng thăm dò "job queue" để xác định có job cần làm hay không, và nếu có thì chúng sẽ đẩy job vào hàng đợi và thực thi nó. ### 7\. Full-text Search Service Hầu hết ứng dụng web hỗ trợ một vài chức năng tìm kiếm mà người dùng thường sẽ cung cấp một tham số văn bản (còn gọi là "query") và ứng dụng trả về kết quả "liên quan". Công nghệ hỗ trợ đặc tính này thường gọi là "full-text search", sử dụng index để nhanh chóng tìm tài liệu chứa từ khóa cần truy vấn. ![full-text search](eba8d45b-27eb-4e56-8380-6db35a45329d.png) Dù có thể thực hiện "full-text search" trực tiếp từ database (chẳng hạn MySQL hỗ trợ full-text search), nó thường chạy một "search service" riêng để tính toán và lưu trữ chỉ mục và cung cấp một giao diện truy vấn riêng. Nền tảng full-text search phổ biến nhất hiện nay là Eltasticsearch, bên cạnh một số lựa chọn khác như Sphinx hoặc Apache Solr. ### 8\. Services Khi ứng dụng đạt đến quy mô nhất định, sẽ có một số "service" được tahcs ra để chạy như một ứng dụng riêng. Chúng không được public bên ngoài nhưng ứng dụng và các service khác có thể tương tác với chúng. Storyblocks có một số service như vậy: - Account service để lưu trữ dữ liệu người dùng trên tất cả các trang web của chúng tôi, cho phép chúng tôi dễ dàng cung cấp các cơ hội "cross-sell" và tạo những trải nghiệm người dùng nhất quán hơn - Content service lưu trữ metadata cho video, audio, ảnh. Nó cũng cung cấp giao diện để download nội dung và xem lịch sử download. - Payment service cung cấp giao diện thanh toán bằng thẻ tín dụng. - HTML → PDF service cung cấp giao diện đơn giản để sinh ra file PDF từ HTML. ### 9\. Data Ngày nay, công ty muốn tồn tại thì phải dựa trên cách họ khai thác dữ liệu. Hầu hết những ứng dụng bây giờ, mỗi lần đạt đến một quy mô nhất định, hãy tận dụng kênh dữ liệu (data pipeline) để đảm bảo rằng dữ liệu được thu thập, lưu trữ và phân tích. Một kênh dữ liệu bao gồm 3 giai đoạn chính: 1. Ứng dụng gửi dữ liệu, sự kiện về tương tác của người dùng cho "firehose" (cung cấp giao diện streaming để nhập và xử lý dữ liệu). Thông thường dữ liệu thô được xử lý sẽ được gửi đến firehose khác. AWS Kinesis và Kafka là hai công nghệ phố biến nhất cho mục đích này. 2. Dữ liệu thô cũng như dữ liệu đã được chuyển đổi được lưu trữ đến cloud. AWS Kinesis cung cấp một setting gọi là "firehose" sẽ lưu dữ liệu thô vào S3 để dễ cấu hình. 3. Dữ liệu được chuyển đổi sẽ được tải vào data warehouse để phân tích. Chúng tôi sử dụng AWS Redshift, mặc dù các công ty lớn khác thường dùng Oracle hoặc công nghệ warehouse độc quyền. Nếu bộ dữ liệu đủ lớn, công nghệ NoSQL MapReduce như Hadoop sẽ được sử dụng để phân tích. Một bước khác không được mô tả trong biểu đồ kiến trúc là: tải dữ liệu từ database của ứng dụng và service vào data warehouse. Chẳng hạn ở Storyblocks, chúng tôi tải VideoBlocks, AudioBlocks, Storyblocks, account service, ... vào Redshift mỗi đêm. Điều này cung cấp cho bộ phân tích những dữ liệu tổng thể bằng cách cấp phát dữ liệu business cùng với dữ liệu tương tác của người dùng. ### 10\. Cloud storage Dịch vụ đám mây là cách đơn giản nhất để lưu trữ, truy xuất và chia sẻ dữ liệu trên internet, theo AWS. Bạn có thể dùng nó để lưu trữ và truy cập với lợi thế là tương tác với nó quả RESTful API. Amazon S3 là dịch vụ lưu trữ đám mây phổ biến nhất ngày nay, và chúng tôi dựa vào nó để lưu trữ video, ảnh, audio, CSS và JavaScript, dữ liệu sự kiện người dùng và hơn thế nữa. ### 11\. CDN CSN là viết tắt của "Content Delivery Network" và công nghệ cung cấp một cách để phục vụ nội dung tĩnh như HTML, CSS, JavaScript và ảnh trên web nhanh hơn so với việc chỉ dùng một server. Nó hoạt động bằng cách phân tán nội dung qua nhiều "edge server" khắp thế giới để người dùng cuối có thể download nội dung từ "edge server" thay vì từ server gốc. Chẳng hạn như ảnh dưới đây, một người dùng từ Tây Ban Nha request một trang web mà có server gốc là ở New York, nhưng các tài nguyên tĩnh của trang web lại được tải về từ "edge server" của CDN từ Anh. ![cdn](0bf32d18-11cf-496a-98b7-ccbbe31ec4b5.png) ]]> https://hungvn.com/blog/web-architecture-101 https://hungvn.com/blog/web-architecture-101 Sun, 06 Jan 2019 23:31:00 GMT <![CDATA[Một mô hình sử dụng Git branches hiệu quả]]> https://hungvn.com/blog/mot-mo-hinh-su-dung-git-branches-hieu-qua https://hungvn.com/blog/mot-mo-hinh-su-dung-git-branches-hieu-qua Sun, 06 Jan 2019 23:24:00 GMT <![CDATA[Giới thiệu về Atomic CSS]]> a:first-child { color: unicorn; } #header p > a.text::before { content: "⛓"; font-family: Comic Sans; } ``` Rồi khi bạn đã quen với CSS và bắt tay vào làm dự án thực tế, bạn bàng hoàng nhận ra kẻ thù không ở đâu xa, chúng đang lởn vởn quanh ta í mà. Bạn bước vào cuộc chiến gọi là [“specificity war”](https://css-tricks.com/a-specificity-battle/), đánh nhau tơi bời khói lửa với class được viết bởi các chiến hữu trong team. Quả là một trận đấu kinh hoàng khi ai cũng muốn đè đầu cưỡi cổ (override) người đi trước. Kẻ nắm giữ !important trong tay cứ nghĩ đã gần với chiến thắng, nào ngờ xuất hiện tiểu nhân dùng inline style + !important. Tình anh em sứt mẻ, chiến hữu quay đầu không nhìn mặt nhau. Bạn ức chế và gào lên "đậu phộng CSS 🥜". > **Specificity là gì?** > > Specificity là một trọng số được trình duyệt sử dụng để quyết định CSS style nào sẽ được áp dụng cho các element. Specificity được tính toán dựa vào phân loại selector và số lượng selector áp dụng lên một element. Bạn có thể đọc thêm về chủ đề này [ở đây](http://gockinhnghiem.com/2011/11/09/specificity-trong-css-la-gi/) hoặc trên trang [MDN](https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity). [http://cssspecificity.com](http://cssspecificity.com) minh hoạ khá cụ thể cách tính specificity. ### Block\_\_Element--Modifier Dân tay to mặt bự đọc đến đây có lẽ đang âm thầm (hoặc công khai) cười khẩy: "Ai kêu gà, xài BEM là được rồi". Chíp chíp 🐥 > **Cho những bạn chưa biết:** > > [BEM - Block Element Modifier](https://css-tricks.com/bem-101/) là một phương pháp đặt tên CSS class được phát triển bởi Yandex. Theo lý thuyết, BEM giúp bạn xây dựng các class theo từng block, mỗi block lại có element con, và các element này có thể sẽ có giao diện khác nhau tuỳ thuộc vào modifier của nó. > > Ví dụ đây là CSS: > > ```javascript > /* Block */ > .btn { > } > > /* Element */ > .btn__price { > } > > /* Modifier */ > .btn--big { > } > > .btn--green { > } > ``` > > Áp dụng vào HTML: > > `` Hoàn toàn không sai. BEM là một phương pháp hiệu quả để chia nhỏ trang thành từng component, và bạn hoàn toàn có thể tránh được cuộc thánh chiến ở trên bằng cách chỉ sử dụng class được đặt tên theo BEM. Ngoài ra, khi một component không còn được dùng nữa, bạn có thể tự tin xoá đi class của nó mà không sợ ảnh hưởng đến các component khác. Tuy nhiên BEM cũng có những vấn đề “khó chịu” mà bạn có thể xem thêm ở bài viết [Battling BEM CSS: 10 Common Problems And How To Avoid Them](https://www.smashingmagazine.com/2016/06/battling-bem-extended-edition-common-problems-and-how-to-avoid-them/). Kinh nghiệm cá nhân là khi làm việc với BEM, có thể bạn sẽ bỏ kha khá thời gian chỉ để suy nghĩ về ngữ nghĩa (semantics) của class. Bạn sẽ phải cân nhắc block này nên đặt tên là gì, những thành phần con của nó có nên là element hay là một component khác, rồi element này nên có tên chi, nên gọi nó là wrapper, container, hay body, v.v… Đừng coi thường việc đặt tên nhé, một trong những vấn đề khó nhai nhất của khoa học máy tính đấy. Ngoài ra tên class thường dính liền với cấu trúc/ nội dung HTML mà nó được sử dụng, dẫn đến việc khi refactor code lại (chuyển thành component tổng quát hơn), chúng ta phải tốn thời gian suy nghĩ tên khác cho hợp lý. Với mình, việc suy nghĩ thêm về ngữ nghĩa cho CSS class không đem lại hiệu quả đáng kể. Vì không giống như HTML, trình duyệt và crawlers không quan tâm bạn đặt tên class có ý nghĩa hay không. Chúng chỉ có giá trị với lập trình viên, và thường thì chúng ta chỉ muốn viết HTML/CSS sao cho giống với thiết kế từ designers nhất mà thôi. ### Tính tái sử dụng và kích thước tập tin CSS Mỉa mai thay, tính chất “cascading” của CSS vốn được sinh ra để hỗ trợ tái sử dụng code lại là một con dao 2 lưỡi và đem đến phiền muộn cho biết bao nhiêu người. Cascading cùng với specificity làm cho CSS trở nên khó dự đoán và lời khuyên là hạn chế cascading được bao nhiêu hay bấy nhiêu. Điều này dẫn đến tập tin CSS chứa nhiều khai báo bị trùng lắp. ```javascript .ie6 #footer-content .flex-control-nav li a, .ie7 #footer-content .flex-control-nav li a, .ie8 #footer-content .flex-control-nav li a { float: left; } #nav.challenger-a li.menu-products { float: left; } ``` Khi dự án của bạn phát triển, nhiều component xuất hiện đồng nghĩa với kích thước tập tin CSS ngày càng to ra. Đáng buồn là, không phải tất cả CSS được gửi xuống cho người dùng sẽ thật sự được sử dụng trong trang. ![](https://res.cloudinary.com/duqeezi8j/image/upload/f_auto,c_scale,w_1000/v1545725390/1_qoyWe6NLqjzVRlDb5YWQAA_nhykgd.jpg) _Kích thước tập tin CSS của các website lớn, tính đến tháng 11 năm 2016\. Nguồn: [1]_ ## Vậy atomic CSS giải quyết được những vấn đề trên à? Có thể. Nhưng trước hết hãy xem atomic CSS là gì đã. Atomic CSS là cách khai báo các class sao cho mỗi class chỉ mô tả một tính năng duy nhất. Để xây dựng component lớn hơn, chúng ta sẽ kết hợp các class nguyên tử này lại với nhau. Chẳng hạn như: ```css .white { color: #fff; } .bg-green { background-color: #3d9970; } .px-10 { padding-left: 10px; padding-right: 10px; } /* Oát đờ hợi (ಠ_ಠ) */ ``` Trong ví dụ trên, class white chỉ làm duy nhất một việc là đổi chữ sang màu trắng, bg-green sẽ thiết lập nền sang màu xanh, trong khi px-10 chỉnh padding ở bên trái và phải (trục x/ trục hoành) thành 10px. Một component được viết theo atomic CSS sẽ giống như thế này: ```html ``` See the Pen [BEM vs atomic CSS](https://codepen.io/ehkoo/pen/KbmGEq/) by Ehkoo ([@ehkoo](https://codepen.io/ehkoo)) on [CodePen](https://codepen.io). Atomic CSS đang được sử dụng bởi các công ty như [npm](https://www.npmjs.com/), [StackOverflow](https://stackoverflow.design/product/guidelines/using-stacks#goals), [Heroku](https://design.herokai.com/purple3), v.v… **Chuyện bên lề: Functional CSS, Atomic CSS, hay Utility-first CSS?** “Functional CSS” là tên gọi đầu tiên mình bắt gặp khi tìm hiểu về cách viết CSS này. Từ “functional” ngoài nghĩa như trong “functional programming” còn có nghĩa là “hoạt động” (trích [từ điển Oxford](https://en.oxforddictionaries.com/definition/functional)). Do đó “functional CSS” có thể hiểu là "CSS hoạt động được", hoàn toàn không liên quan đến ý tưởng chính: đặt CSS class thành từng hàm nhỏ. Một tên gọi khác là "Atomic CSS", theo nghĩa mỗi class là một “nguyên tử” độc lập. Tên gọi này rất phù hợp với tiêu chí chia nhỏ class, nhưng đáng tiếc thay khi nó “có thể” nhầm lẫn là có liên quan tới phương thức [Atomic Design](http://atomicdesign.bradfrost.com/chapter-2/). Ngoài ra, có một thư viện của Yahoo! cũng tên là [Atomic CSS](https://acss.io/). Cuối cùng, “Utility-first CSS” có lẽ là tên gọi mô tả chính xác nhất. “Utility-first” mang nghĩa "tập trung xây dựng các class hỗ trợ". Điểm trừ của thuật ngữ này là…tên dài quá. Suy đi xét lại thiệt hơn thì trong bài viết này mình chọn “atomic CSS” (chữ “a” viết thường) vì…gõ nhanh thôi. Nhưng bạn để ý là 3 thuật ngữ này đều dùng chung cho một cách viết CSS nhé. ## Vậy có gì hay? ### Tránh cảnh binh đao Lợi ích đầu tiên là cũng giống như BEM, atomic CSS chỉ cho phép khai báo các class nên chúng không xảy ra tranh chấp specificity. Đồng thời vì mỗi class chỉ mô tả một tính năng duy nhất, việc các thuộc tính giẫm chân lên nhau được hạn chế ở mức thấp nhất. Còn vẫn ghét nhau quá, muốn đạp nhau cho chết thì đây: ```html
Roses are red
Violets are blue
Honey is sweet
But not as sweet as you
``` _Credit: @huytd_ ### Tập tin CSS nhẹ hơn Bằng cách xây dựng component bằng những class nguyên tử, bạn không cần phải lặp đi lặp lại những khai báo đã có. Khi nhận được thiết kế cho component mới, bạn chỉ cần kết hợp những class đã có sẵn với nhau hoặc viết thêm atomic classes. Những class mới xuất hiện sẽ tiếp tục được tái sử dụng nên số lượng class bạn thêm vào sẽ ngày càng giảm đi khi tuổi thọ của dự án dài ra. Trong bài viết [By The Numbers: A Year and Half with Atomic CSS](https://medium.com/@johnpolacek/by-the-numbers-a-year-and-half-with-atomic-css-39d75b1263b4), John Polacek đã thử nghiệm chuyển đổi từ CSS truyền thống sang atomic CSS và kết quả là dung lượng tập tin giảm từ 123.1KB xuống còn 72.7KB (chưa nén gzip). ![](https://res.cloudinary.com/duqeezi8j/image/upload/c_scale,f_auto,w_1000/v1545725434/1_Tvxaigmr3ve2GrWDwHB9Pw_qtsoai.jpg) Kết quả cuối cùng là càng ngày bạn sẽ càng viết ít CSS lại. ### Không phải suy nghĩ chuyện đặt tên class Vì các atomic classes được đặt tên gần với thuộc tính của chúng, bạn không cần phải suy nghĩ nên đặt tên gì. Một lợi ích nữa là nhìn vào HTML bạn có thể tương đối biết được style của một element. Lấy ví dụ: ```html ``` Với BEM, bạn có thể sơ đoán "à cái nút này là cái nút màu xanh bự nè", nhưng “bự” là cái gì "bự", font size hay height, và cái gì "xanh", chữ xanh, nền xanh hay viền xanh. Khi đi đến btn\_\_price thì hoàn toàn không thể biết được style của nó. So sánh với atomic CSS, bạn có thể đọc ngay là "nút này có viền 1px, viền màu xanh, nền xanh, chữ trắng, bo tròn góc 5px, margin ở bốn phía 10px, font ở level 3, chữ được chuyển thành chữ hoa có font weight 400, padding bốn phía 10px". Tương tự với thẻ SPAN, bạn có thể đọc là "nền đen có opacity 0.4, chữ trắng, padding trái phải 12px, font weight 600, bo tròn góc bên trái 5px". Liệu việc đọc style như thế này có cần thiết? Nếu bạn mới bắt đầu, câu trả lời có thể là không, nhưng khi đã quen rồi, đọc class nhanh giúp bạn debug và thay đổi style dễ dàng hơn. ### Xây dựng prototype nhanh hơn Prototyping, hay là chuyện làm những giao diện giả để kiểm tra UI/UX, không còn lạ với dân làm frontend nữa. Một trong những lý do bạn chọn Bootstrap, Foundation, hay Bulma… cho dự án vì đơn giản chúng cung cấp những component được xây dựng sẵn, cùng với hệ thống grid và các class hỗ trợ. Nhưng rồi bạn sẽ lâm vào cảnh đánh nhau với các class của framework để tuỳ biến cho phù hợp với chuẩn thiết kế. Kết quả ra sao thì bạn biết rồi. Các framework được thiết kế theo hướng atomic không có nhiều component, nhưng bù lại chúng không đặt quá nhiều ý kiến riêng và ép buộc bạn phải làm theo. Hầu hết đều cho phép bạn tuỳ chỉnh màu sắc, kích thước theo ý, từ đó bạn có thể xây dựng lên những component cần thiết. ## Hạn chế ### Bùng nổ class [Tachyons](http://tachyons.io/docs/themes/skins/) là một trong những atomic CSS framework phổ biến nhất. Trong phiên bản 4.10.0, Tachyons hỗ trợ 37 màu. Giả sử mỗi màu sẽ có class tương ứng với màu chữ, màu nền, màu viền, hover đổi màu chữ, hover đổi màu nền, và hover đổi màu viền. Tachyons có 3 breakpoints. Như vậy tổng số class được tạo ra là 37 x 8 (thuộc tính) x 3 = 888 classes. Nếu bạn phải sử dụng nhiều màu hơn, ví dụ như color palette của [Material Design](https://material.io/design/color/the-color-system.html#tools-for-picking-colors), hỗ trợ nhiều thuộc tính và pseudo selector hơn, thêm vài breakpoints nữa, bạn cũng có thể đoán được số lượng class phình ra như thế nào. Thực tế là không phải tất cả class màu đều được sử dụng, nên việc tạo ra class để bao gồm tất cả các trường hợp là không cần thiết. Cách giải quyết ở đây là chỉ viết thêm class khi bạn thật sự cần đến nó. ### Tìm và thay đổi class theo yêu cầu mới khó hơn Giả sử một ngày đẹp trời nào đó, đồng chí Nguyễn Văn Xài Nơ quyết định nền màu xanh của tất cả các nút phải đậm hơn chút xíu, nút bự nghĩa là font size phải ở level 2\. Với BEM, bạn chỉ cần thay đổi giá trị của class .btn--green và .btn--big là xong. Trong khi đó bạn không thể đổi mã màu của .bg-green bởi vì thay đổi này chỉ áp dụng trên nút và biết đâu được màu cũ vẫn được dùng ở nơi khác. Bạn cũng không thể tuỳ tiện tăng font size của .f3. Giải pháp an toàn nhất là tìm tất cả các nút, xoá đi class cũ và thêm vào f2 bg-dark-green. Bạn tìm các nút bằng cách nào? Search and Replace… bg-green white br-5 ma-10 f3 -> bg-dark-green white br-5 ma-10 f2? Lỡ như có một class nào đó chen vào giữa bg-green white br-5 ma-10 letter-spacing-1 f3 và thế là tèn tén ten. Nếu dự án của bạn sử dụng React, Vue, hay các thư viện hỗ trợ (web) component khác, việc thay đổi này không thành vấn đề. Còn với thuần HTML thì…coi bộ cực đó. Bạn có thể đặt tên cho UI component bằng data-, nhưng như vậy markup sẽ bị rối và ở phía người dùng, các thuộc tính này hoàn toàn không được dùng đến. ```html ``` ### Nghi ngờ từ cộng đồng Thành thật mà nói, atomic CSS rất không tự nhiên khi tiếp xúc lần đầu tiên. Chúng ta đã quá quen với cách viết CSS truyền thống/ BEM, và khi nhìn thấy một đống class đi chung với những cái tên xa lạ như ma, px, hay ttu, nghi ngờ là phản ứng rất dễ hiểu. > **Vậy có khác gì inline style?** Nhìn sơ qua thì đúng là giống như inline style vậy, và ai cũng biết inline style là bad practice. Nhưng atomic classes khác hoàn toàn và mạnh mẽ hơn inline style nhiều. Atomic classes cho phép bạn viết media queries, @support, pseudo selectors hay sử dụng animation, những điều mà inline style không làm được. Và vì atomic CSS được lưu trong tập tin CSS, trình duyệt có thể lưu vào bộ nhớ đệm, không giống như inline style. > **Tên class thấy gớm** Kiểu viết tắt ma (margin all), px (padding x), ph (padding horizontal) hay bg rất phổ biến trong cộng đồng atomic CSS. Ban đầu bạn có thể thấy khó hiểu và tốn thời gian để học, nhưng sau một thời gian chúng sẽ trở nên tự nhiên. Ngoài ra còn một số ý kiến phản đối atomic CSS nữa mà nếu muốn, bạn có thể đọc bài viết [The Problem with Atomic CSS](https://medium.com/simple-human/the-problem-with-atomic-css-d0c09c7aa38e) rồi tự đưa ra nhận xét. Spoiler alert: không phải tất cả luận điểm trong bài đều hợp lý. ## Tích hợp vào dự án Nếu bạn đọc đến đây và không cảm thấy atomic CSS là một ý tưởng dị hợm thì bài viết này coi như đã thành công. Để dùng atomic CSS trong dự án, bạn có thể chọn cách dùng các thư viện có sẵn, hoặc tự xây dựng thư viện riêng. ### Dùng hàng ăn sẵn Cách này phù hợp với những dự án mới hoặc bạn muốn thử nghiệm với atomic CSS. Hiện tại thì hai thư viện phổ biến nhất là [Tachyons](http://tachyons.io/) và [Tailwind](http://tailwindcss.com/). Tachyons có lượng người dùng đông đảo vì xuất hiện trước, nhưng Tailwind lại mạnh mẽ hơn vì cho phép bạn thay đổi màu sắc, kích thước, v.v… hoàn toàn theo ý muốn. Không thì bạn có thể dùng hệ thống thiết kế của [StackOverflow](https://stackoverflow.design/product/guidelines/using-stacks#goals) hay [Heroku](https://design.herokai.com/purple3) cũng được. Sự thật là các atomic classes quá nhỏ nên chúng gần như giống hệt nhau ở tất cả framework, có khác chăng chỉ là tên gọi mà thôi. ### Tự trồng Trong một dự án đang chạy, nếu muốn áp dụng atomic CSS thì không gì tốt hơn là tự trồng lấy một framework. Các atomic classes rất nhỏ và đơn giản nên hoàn toàn không có gì khó để tự viết cả. Bạn có thể từ từ bóc tách các thuộc tính của các class cũ và chuyển chúng thành atomic classes. Dự án của bạn có thể sắp xếp các tập tin (S)CSS như thế này. ```scss styles/utils/ ├── _animation.scss ├── _background.scss ├── _border.scss ├── _box-shadow.scss ├── _color.scss ├── _cursor.scss ├── _display.scss ├── _flex.scss ├── _font-size.scss ├── _font-weight.scss ├── _height.scss ├── _letter-spacing.scss ├── _line-height.scss ├── _list.scss ├── _margin.scss ├── _max-width.scss ├── _padding.scss ├── _ratio.scss ├── _text-align.scss └── _width.scss ``` Về việc đặt tên, bạn có thể chọn kiểu viết tắt px, ma hay ttu như trong Tachyons, hoặc kiểu đầy đủ padding-x, margin-all, text-transform-uppercase. Cái này tuỳ thuộc vào sở thích của từng team. Ngoài ra, việc viết lặp đi lặp lại nhóm class có thể gây nhàm chán, do đó bạn đừng quên tận dụng các công cụ tiền xử lý CSS như SASS, LESS, hay Stylus để cuộc sống dễ thở hơn. Chẳng hạn như đoạn code dưới đây để tạo ra các class liên quan đến height: ```scss $list: 28 96 128 640; @each $value in $list { .h-#{$value} { height: #{$value}px; } } ``` Khi cần thêm một giá trị mới, bạn chỉ cần bỏ nó vào $list. Bạn cũng có thể dùng mixin để tạo ra các class responsive: ```scss @include media(extra-large) { $list: 28 96 128 640; @each $value in $list { .h-#{$value}-xl { height: #{$value}px; } } } ``` ## Kết Nếu nhóm của bạn đang dùng BEM hay các phương pháp phát triển CSS khác và hài lòng với chúng, bạn có thể không cần atomic CSS. Atomic CSS không phải sinh ra là để triệt tiêu BEM, mà bổ sung và giúp bạn làm việc với CSS một cách hiệu quả hơn. Cuối cùng, hãy xem video này và quyết định có nên xài atomic CSS không nhé ;) ]]> https://hungvn.com/blog/gioi-thieu-ve-atomic-css https://hungvn.com/blog/gioi-thieu-ve-atomic-css Sun, 06 Jan 2019 17:18:00 GMT <![CDATA[Cách Javascript hoạt động P19: Bên trong custom element + thủ thuật xây dựng component tối ưu]]>
…
``` Kiểu kiến trúc như thế này thường được dùng vì nó bảo trình duyệt phải render những gì mà developer muốn. Nhưng nó lại làm cho code HTML khó đọc và rất khó bảo trì. Ví dụ chúng ta có 1 component trông như thế này: ![](https://cdn-images-1.medium.com/max/1000/0*v56OyrPtg_cZzzaZ) Vậy thì theo cách cũ, HTML sẽ như thế này: ```html
 
 
 
 
``` Tuy nhiên, tưởng tượng rằng chúng ta có thể làm như thế này: ```html ``` Rõ ràng ví dụ thứ 2 nhìn sạch sẽ và gọn hơn nhiều. Dễ bảo trì, dễ đọc cho cả trình duyệt và developer. Đơn giản hơn nhiều. Vấn đề tiếp theo là khả năng tái sử dụng. Công việc của developer chúng ta đòi hỏi không chỉ viết code hoạt động được mà còn phải bảo trì được. Và 1 điều làm cho code dễ bảo trì là nó có thể dễ dàng tái sử dụng 1 phần nào đó của code thay vì phải viết đi viết lại nhiều lần. Dưới đây là 1 ví dụ đơn giản nhưng bạn sẽ hiểu ý tưởng của nó. Giả sử ta có element sau: ```html
``` Nếu chúng ta cần sử dụng nó ở nơi nào khác thì ta sẽ phải viết lại đoạn HTML trên nhiều lần. Giả sử như ta cần thay đổi 1 phần nào đó và áp dụng cho mọi element. Ta sẽ phải đi tìm tất cả mọi nơi có đoạn code đó và chỉnh sửa chính xác cùng 1 thay đổi y chang nhau rất nhiều lần, bùm..... Vậy thì không tốt hơn nếu ta chỉ cần như vậy thôi sao: ```html ``` Nhưng webapp hiện đại không chỉ có HTML tĩnh. Bạn cần tương tác với nó nữa. Và đây là lúc ta cần Javascript. Thường thì bạn sẽ tạo ra 1 vài element, ghép chúng vào bất kỳ event listener nào mà bạn muốn để cho nó có thể tương tác phản hồi khi có input từ người dùng. Bất kể là click, kéo-thả, hover, nhấn bàn phím, vân vân ```javascript var myDiv = document.querySelector(".my-custom-element"); myDiv.addEventListener("click", _ => { myDiv.innerHTML = " I have been clicked "; });
I have not been clicked yet.
; ``` Với API custom element, toàn bộ phần logic này có thể được đóng gói vào bên trong chính element đó. Xem ví dụ bên dưới ```javascript class MyCustomElement extends HTMLElement { constructor() { super(); var self = this; self.addEventListener("click", _ => { self.innerHTML = " I have been clicked "; }); } } customElements.define("my-custom-element", MyCustomElement); I have not been clicked yet; ``` Mới đầu nhìn vào thì có vẻ như giải pháp custom element này đòi hỏi nhiều Javascript. Tuy nhiên trong các ứng dụng thực tế thì bạn sẽ hiếm khi gặp phải trường hợp mà bạn tạo ra 1 element mà không phải tái sử dụng nó. Một diều điển hình nữa trong các webapp hiện đại là đa số các element đều được tạo ra bằng code trong quá trình hoạt động (dynamic). Vì thế bạn cần phải xử lý các trường hợp riêng biệt khi element được thêm vào bằng Javascript hoặc nó được định nghĩa trước kia trong kiến trúc HTML. Bạn sẽ có toàn bộ những tính năng ấy nếu dùng custom element. Tóm lại, custom element làm code bạn dễ hiểu, dễ bảo trì hơn, chia nhỏ nó thành các module khép kín nhỏ hơn, có thể tái sử dụng. # Các yêu cầu Trước khi bạn bắt đầu tạo custom element của chính mình, bạn nên biết rằng có 1 số quy tắc đặc biệt mà ta phải tuân theo: - Tên **phải** chứa dấu gạch ngang (-). Bằng cách này bộ parser của HTML mới hiểu được element nào là do người dùng tạo ra và element nào là sẵn có. Nó cũng đảm bảo rằng không có xung đột khi đặt tên với các element sẵn có (bất kể bây giờ hay trong tương lai, khi một element mới được thêm vào). Ví dụ, `` là 1 tên hợp lệ trong khi `` và `` thì không. - Không được đăng ký cùng 1 thẻ tên nhiều hơn 1 lần. Điều này sẽ làm cho trình duyệt bắn ra 1 biệt lệ DOMException. Bạn không thể ghi đè các custom element. - Custom element không thể tự đóng thẻ. Bộ parser HTML chỉ cho phép 1 nhóm các element sẵn có có thể tự đóng thẻ của nó (ví dụ: ``, ``, `
`). # Các khả năng Vậy thì bạn thực sự có thể làm được gì với custom element? Và câu trả lời là: rất nhiều thứ. Một trong số những tính năng tốt nhất là định nghĩa class của element thực sự liên kết đến chính DOM element của nó. Điều này có nghĩa bạn có thể dùng trực tiếp this với event listener, truy cập vào các property của nó, truy cập các node con và vân vân. ```javascript class MyCustomElement extends HTMLElement { // ... constructor() { super(); this.addEventListener("mouseover", _ => { console.log("I have been hovered"); }); } // ... } ``` Dĩ nhiên là nó cho bạn khả năng để ghi đè lại node con của 1 element với nội dung mới. Và cũng dĩ nhiên là điều này không nên làm, bởi vì nó sẽ dẫn đến nhiều vấn đề không mong muốn. Rõ ràng nếu như bạn có 1 custom element đang hoạt động và đột nhiên phát hiện ra phần markup của element của mình bị thay đổi thì sẽ bối rối lắm. Có 1 vài vị trí đặc biệt mà bạn có thể định nghĩa để thực thi code tại các thời điểm cụ thể trong vòng đời của element. - constructor: constructor được gọi 1 lần khi element được tạo ra hoặc nâng cấp (chúng ta sẽ nói về nó sau). Đa số nó được dùng để khởi tạo state (trạng thái), gắn kết các event listener, tạo shadow DOM, vân vân. Lưu ý bạn hầu như cần phải gọi super() trong constructor. - connectedCallback: phương thức connectedCallback được gọi mỗi lần element được thêm vào DOM. Nó có thể được dùng (khuyến nghị nên dùng) để delay (hoãn lại) vài việc cho đến khi element thực sự được gắn vào trang (chẳng hạn như lấy tài nguyên từ server). - disconnectedCallback: tương tự như connectedCallback thì disconnectedCallback được gọi khi 1 element bị lấy ra khỏi DOM. Thường là để giải phóng tài nguyên. Lưu ý rằng disconnectedCallback không bao giờ được gọi nếu như user đóng tab. Hãy cẩn thận với những thứ mà bạn khởi tạo lúc đầu. - attributeChangedCallback: phương thức này được gọi khi 1 attribute của element được thêm vào, gỡ ra, cập nhật hoặc thay thế. Nó cũng được gọi khi element được tạo ra bởi parser. Tuy nhiên, lưu ý rằng nó chỉ áp dụng cho các attribute nằm trong danh sách an toàn (whitelist) của property observedAttributes - addoptedCallback: phương thức này được gọi khi document.adoptNote(...) được gọi để đưa đó sang 1 document khác. Lưu ý rằng tất cả các callbacks ở trên đều là **đồng bộ**. Ví dụ, connectedCallback được gọi ngay lập tức sau khi element được thêm vào DOM và trong lúc đó không có gì xảy ra. # Phản chiếu property Các element HTML sẵn có cung cấp 1 khả năng rất tiện dụng: phản chiếu property. Nghĩa là các giá trị của 1 vài property được phản chiếu trực tiếp về DOM dưới dạng attribute. Một ví dụ điển hình là property id. ```javascript myDiv.id = "new-id"; ``` Cũng sẽ cập nhật DOM thành: ```html
...
``` Và nó cũng áp dụng theo hướng ngược lại nữa. Phần này cực kỳ tiện lợi bởi vì nó cho phép bạn cấu hình các element khai báo. Custom element không có tính năng như thế này nhưng có 1 cách để bạn tự triển khai. Ta có thể có được tính năng tương tự khi định nghĩa các getter & setter cho các property. ```javascript class MyCustomElement extends HTMLElement { // ... get myProperty() { return this.hasAttribute("my-property"); } set myProperty(newValue) { if (newValue) { this.setAttribute("my-property", newValue); } else { this.removeAttribute("my-property"); } } // ... } ``` # Mở rộng element API custom element cho phép bạn không chỉ tạo ra các element HTML mà còn có thể mở rộng element sẵn có. Phương pháp này hoạt động cực tốt cho cả element sẵn có và custom element. Bạn chỉ cần mở rộng định nghĩa class của nó là được. ```javascript class MyAwesomeButton extends MyButton { // ... } customElements.define("my-awesome-button", MyAwesomeButton); ``` Hoặc trong trường hợp của element có sẵn, ta cần thêm 1 param thứ 3 vào hàm customElements.define(...) - một object với property extends và giá trị là thẻ tên của element đang được mở rộng. Bằng cách này trình duyệt biết được chính xác thì element nào đang được mở rộng bởi vì có rất nhiều element sẵn có cùng chia sẻ giao diện DOM. Nếu không chỉ định element nào mà mình muốn mở rộng, trình duyệt sẽ không biết được chức năng nào đang được mở rộng. ```javascript class MyButton extends HTMLButtonElement { // ... } customElements.define("my-button", MyButton, { extends: "button" }); ``` Một element gốc mở rộng (extended native element) còn được gọi là element được tùy biến (customized built-in element). Nguyên tắc vàng cho bạn đó là luôn luôn mở rộng các element đang tồn tại sẵn. Và làm việc này một cách dần dần. Nó cho phép bạn giữ lại tất cả các tính năng trước đó (property, attribute, các hàm). Chú ý rằng element được tùy biến chỉ được hỗ trợ từ Chrome 67 trở lên. Nó sẽ được triển khai cho các trình duyệt khác ngoại trừ Safari. # Nâng cấp element Như đã nói ở trên, chúng ta sử dụng phương thức customElements.define(...) để đăng ký 1 custom element. Nhưng nó không có nghĩa rằng đó là việc đầu tiên bạn phải làm. Đăng ký custom element có thể được hoãn lại sau này. Kể cả sau khi chính element đó được thêm vào DOM. Quá trình này được gọi là nâng cấp element. Để giúp bạn biết được thực sự khi nào thì element được định nghĩa thì trình duyệt có cung cấp phương thức customElements.whenDefine(...). Bạn truyền thẻ tên của element vào, nó trả về 1 promise và sẽ được resolve khi element đăng ký xong. ```javascript customElements.whenDefined("my-custom-element").then(_ => { console.log("My custom element is defined"); }); ``` Ví dụ, khi bạn muốn delay 1 vài thứ cho đến khi tất cả các element con được định nghĩa xong, cực kỳ có ích khi mà bạn có các custom element lồng nhau. Thỉnh thoảng element cha sẽ dựa vào sự triển khai của các element con. Trong trường hợp này bạn cần đảm bảo rằng các element con được định nghĩa trước element cha. # Shadow DOM Như đã nói, custom element và shadow DOM đi đôi với nhau. Custom element được dùng để đóng gói logic Javascript vào bên trong 1 element trong khi shadow DOM được dùng để tạo ra 1 môi trường khép kín cho phần DOM không bị ảnh hưởng bởi các yếu tố bên ngoài. Mình đề nghị bạn nên đọc lại [bài viết trước](https://kipalog.com/posts/Duc-khoet-Javascript--Phan-17---ben-trong-Shadow-DOM---xay-dung-component-khep-kin) để hiểu thêm về shadow DOM và các ý tưởng của nó. Để sử dụng shadow DOM cho custom element, bạn chỉ cần đơn giản gọi this.attachShadow ```javascript class MyCustomElement extends HTMLElement { // ... constructor() { super(); let shadowRoot = this.attachShadow({mode: 'open'}); let elementContent = document.createElement('div'); shadowRoot.appendChild(elementContent); } // ... }); ``` # Template Chúng ta đã tìm hiểu sơ về template trong [bài viết trước về shadow DOM](https://kipalog.com/posts/Duc-khoet-Javascript--Phan-17---ben-trong-Shadow-DOM---xay-dung-component-khep-kin) và chúng xứng đáng có 1 bài viết riêng. Ở đây chúng ta sẽ đưa ra 1 ví dụ đơn giản làm thế nào để bạn có thể kết hợp các template vào quá trình tạo ra custom element. Sử dụng thẻ `