Skip to main content

4 posts tagged with "javascript"

View All Tags

· 8 min read
Lê Sĩ Bích

Overview

Vào ngày 28/5/2021, trên blog của Rails có thông báo về 1 tính năng mới đó là ActiveRecord Encryption.

ActiveRecord Encryption giúp encrypt attribute nào đó của model, và lưu vào DB dưới dạng mã hoá. Tính năng này được extract ra từ dự án HEY của Basecamp.

Hãy thử tìm hiểu xem tính năng này có gì thú vị.

Usage

Theo guide, đầu tiên chúng ta sẽ cần phải chạy câu lệnh sau

rails db:encryption:init

Rails sẽ cho ta 1 gợi ý là copy đống sau vào credentials. Ừ EDITOR=vim rails credentials:edit rồi copy paste thôi.

active_record_encryption:
primary_key: EGY8WhulUOXixybod7ZWwMIL68R9o5kC
deterministic_key: aPA5XyALhf75NNnMzaspW7akTfZp0lPY
key_derivation_salt: xEY0dt6TZcAMg52K7O84wYzkjvbA62Hz

Trong model, ta define attribute cần mã hoá như sau:

class Article < ApplicationRecord
encrypts :title
end

Rồi create/update model như bình thường

article = Article.create(title: "Encrypt it all!")

Và bùm, magic...

INSERT INTO `articles` (`title`) VALUES ('{\"p\":\"n7J0/ol+a7DRMeaE\",\"h\":{\"iv\":\"DXZMDWUKfp3bg/Yu\",\"at\":\"X1/YjMHbHD4talgF9dt61A==\"}}')

Vô hạn bối rối...

AES

Trước tiên ta hãy tìm hiểu về đống key mà Rails đã gen cho ta lúc đầu

active_record_encryption:
primary_key: EGY8WhulUOXixybod7ZWwMIL68R9o5kC
deterministic_key: aPA5XyALhf75NNnMzaspW7akTfZp0lPY
key_derivation_salt: xEY0dt6TZcAMg52K7O84wYzkjvbA62Hz

Rails gen ra đống trên như nào vậy?

puts <<~MSG
Add this entry to the credentials of the target environment:#{' '}

active_record_encryption:
primary_key: #{SecureRandom.alphanumeric(32)}
deterministic_key: #{SecureRandom.alphanumeric(32)}
key_derivation_salt: #{SecureRandom.alphanumeric(32)}
MSG

Nếu ai chưa biết thì đây là standard lib của Ruby, đơn thuần là... random mà thôi =))

Thế đống key này để làm gì? Ở mục Setup của guide, Rails cũng đã gợi ý cho ta, đống này dùng cho AES.

this will be used to derive the AES 32 bytes key

Vậy AES là cái khỉ mốc gì? Theo wiki, AES là viết tắt của Advanced Encryption Standard. Hay còn được biết đến với cái tên Rijndael. AES là 1 chuẩn mã hoá, sử dụng symmetric encryption. AES rất phổ biến ngày nay.

Thế bất nào mà lại đẻ ra thêm nhiều thuật ngữ hại não hơn vậy =)) Cứ từ từ rồi khoai sẽ nhừ, chúng ta sẽ tìm hiểu tiếp.

Trước hết thì, thế nào là mã hoá? Ví dụ như ở 1 diễn đàn nào đó người ta share nhau hoàng thuỳ link bằng đống kí tự này

68747470733A2F2F7777772E676F6F676C652E636F6D2E766E2F

thay vì huỵch toẹt ra là một đường link đồi truỵ nào đó. Nhưng do việc giải mã quá đơn giản, cụ thể là dùng mã HEX, nên đây chỉ là encode/decode sang 1 dạng dữ liệu khác mà thôi, và việc chuyển đổi thường khá nhanh. Các bạn có thể vào đây đây để decode chuỗi huyền bí trên.

Còn encrypt và decrypt dùng trong cryptography nó ở 1 tầm cao khác. Thông thường sẽ có thêm 1 key (hoặc 1 cặp key public/private). Khi đó input sẽ là key + data. Và output sẽ là 1 chuỗi nào đó, chuỗi này cực kì khó để giải mã nếu không nắm trong tay key. Thông thường thì phải cho chạy thuật toán vét cạn - tức là thử từng key một, và việc này cần đến hàng triệu năm đối với cả siêu máy tính.

  • Với thuật toán dùng 1 key cho cả việc encrypt lẫn decrypt thì sẽ được gọi là symmetric encryption

symmetric

  • Thuật toán dùng 1 cặp key, trong đó public key để mã hoá, còn private key để giải mã, được gọi là asymmetric encryption

asymmetric

Image source

Quay lại với AES, nó dùng symmetric, nên sẽ dùng 1 key cho cả việc mã hoá lẫn giải mã. AES key có độ dài là 128, 192, hoặc 256 bit. Tuỳ vào độ dài key nó sẽ có tên khác nhau AES-128, AES-192, AES-256. Key càng dài thì việc xử lý càng lâu, nhưng đổi lại càng bảo mật hơn. Mặc định Rails sử dụng key có độ dài 256 bit (32 bytes)

CIPHER_TYPE = "aes-256-gcm"

Về việc làm thế nào để AES mã hoá/giải mã thì mình sẽ không đề cập tại đây vì mình cũng không có hiểu mấy =)), nếu ai muốn tìm hiểu thêm có thể xem link này, hoặc gúc gồ ~~. Ở dưới là bản preview, trông cái thuật toán nó nôm na như sau

AES sẽ chia nhỏ input thành từng block để xử lý

block-cipher

flow

round

Image Source

Cơ mà chỉ quan tâm là một chuỗi đầu vào + 1 key, đi qua đống black magic rồi trở thành 1 chuỗi bảo mật siêu hạng là quá đủ cho một cuộc tình rồi.

À mà nhìn cái constant Rails define ở trên kia, lại có thêm cái gì ở cuối chuỗi thế nhỉ. gcm???? Bối rối again.

GCM

GCM là viết tắt của Galois/Counter Mode... Nghe xong hiểu chết liền .__. Mò thử xem nào!

Như tên gọi của nó, GCM là một mode trong symmetric encryption, kết hợp của Counter ModeGalois Mode, dùng cho mã hoá dạng khối (block). Vậy thì AES đi với GCM là chuẩn bài rồi nhỉ.

Ngoài GCM ra còn các mode khác như CCM, SIV, ...vân vân mây mây. Các bạn có thể xem thêm tại đây

Trước tiên ta hãy bắt đầu từ mode, từ này nằm trong Mode of Operation. Các mode sẽ được apply trên từng block data (như đã nói ở trên thì AES chia data thành các block nhỏ và mã hoá), giúp cho output của việc mã hoá block bảo mật hơn.

Counter mode sử dụng 1 số integer làm counter, qua từng block counter sẽ tăng lên 1. Ở mỗi block, số này sẽ được mã hoá cùng với data để có được output bảo mật hơn.

counter-mode

Galois Mode là một authentication mode. Galois Mode giúp đảm bảo rằng cipher output của ta không bị chỉnh sửa bởi một bên thứ 3. Hoạt động như nào thì mình chịu à =))

Kết hợp 2 mode trên và ta có GCM, giúp thuật toán mã hoá của ta bảo mật hơn, đồng thời đảm bảo được tính toàn vẹn của dữ liệu.

gcm-mode

Bên trên là giải thích sơ qua về thuật toán mã hoá mà Rails sử dụng, nếu có sai sót thì cũng đừng gạch đá tội mình =))

AES-256-GCM meets Rails

Encryption Key

active_record_encryption:
primary_key: EGY8WhulUOXixybod7ZWwMIL68R9o5kC
deterministic_key: aPA5XyALhf75NNnMzaspW7akTfZp0lPY
key_derivation_salt: xEY0dt6TZcAMg52K7O84wYzkjvbA62Hz

Quay trở lại với đống key, hãy cùng mò code đáy bể xem chúng dẫn ta tới đâu :v

# https://github.com/rails/rails/blob/9c091b4fd378df515c4c31b85bb6a968463a1d82/activerecord/lib/active_record/railtie.rb#L313-L317
ActiveRecord::Encryption.configure \
primary_key: app.credentials.dig(:active_record_encryption, :primary_key),
deterministic_key: app.credentials.dig(:active_record_encryption, :deterministic_key),
key_derivation_salt: app.credentials.dig(:active_record_encryption, :key_derivation_salt),
**config.active_record.encryption

# https://github.com/rails/rails/blob/9c091b4fd378df515c4c31b85bb6a968463a1d82/activerecord/lib/active_record/encryption/configurable.rb#L20-L33
def configure(primary_key:, deterministic_key:, key_derivation_salt:, **properties)
config.primary_key = primary_key
config.deterministic_key = deterministic_key
config.key_derivation_salt = key_derivation_salt

context.key_provider = ActiveRecord::Encryption::DerivedSecretKeyProvider.new(primary_key)
end

# https://github.com/rails/rails/blob/9c091b4fd378df515c4c31b85bb6a968463a1d82/activerecord/lib/active_record/encryption/derived_secret_key_provider.rb#L7-L9
def initialize(passwords)
super(Array(passwords).collect { |password| Key.derive_from(password) })
end

Xem tiếp class Key có gì nào.

# https://github.com/rails/rails/blob/9c091b4fd378df515c4c31b85bb6a968463a1d82/activerecord/lib/active_record/encryption/key.rb#L10-L26
class Key
def initialize(secret)
@secret = secret
@public_tags = Properties.new
end

def self.derive_from(password)
secret = ActiveRecord::Encryption.key_generator.derive_key_from(password)
ActiveRecord::Encryption::Key.new(secret)
end
end

# https://github.com/rails/rails/blob/9c091b4fd378df515c4c31b85bb6a968463a1d82/activerecord/lib/active_record/encryption/key_generator.rb#L32-L34
def derive_key_from(password, length: key_length)
ActiveSupport::KeyGenerator.new(password).generate_key(ActiveRecord::Encryption.config.key_derivation_salt, length)
end

Như vậy, 2 trong số 3 thanh niên của ta đã bị lộ mặt:

  • primary_key đóng vai trò là password param của ActiveSupport::KeyGenerator.new
  • key_derivation_salt đóng vai trò là tham số thứ nhất của ActiveSupport::KeyGenerator#generate_key

Hãy check tiếp ActiveSupport::KeyGenerator

# https://github.com/rails/rails/blob/9c091b4fd378df515c4c31b85bb6a968463a1d82/activesupport/lib/active_support/key_generator.rb#L26-L41
def initialize(secret, options = {})
@secret = secret
@iterations = options[:iterations] || 2**16
@hash_digest_class = options[:hash_digest_class] || self.class.hash_digest_class
end

def generate_key(salt, key_size = 64)
OpenSSL::PKCS5.pbkdf2_hmac(@secret, salt, @iterations, key_size, @hash_digest_class.new)
end

Qua hết wrapper của Rails rồi, giờ ta phải mò vào docs của Ruby thôi. Theo docs, docs lại bảo hàm này giờ đổi tên thành OpenSSL::KDF.pbkdf2_hmac mất rồi... Ờ thì lại mò vào xem. Nôm na hàm này sẽ tạo ra 1 cipher key dùng cho việc mã hoá.

Tại đây, ta có thể kết luận key mã hoá mà Rails dùng có:

  • passphrase: primary_key
  • salt: key_derivation_salt
  • iterations: 2^16
  • key_len: độ dài key 32 bytes
  • digest: hash algorithm SHA-1

Hãy cùng test qua cái key này xem

require 'openssl'

cipher = OpenSSL::Cipher.new('aes-256-gcm')
cipher.encrypt
iv = cipher.random_iv

pwd = 'EGY8WhulUOXixybod7ZWwMIL68R9o5kC'
salt = 'xEY0dt6TZcAMg52K7O84wYzkjvbA62Hz'
iter = 2**16
key_len = OpenSSL::Cipher.new("aes-256-gcm").key_len
digest = OpenSSL::Digest.new('SHA1')

key = OpenSSL::PKCS5.pbkdf2_hmac(pwd, salt, iter, key_len, digest)
cipher.key = key

encrypted = cipher.update "hello"
encrypted << cipher.final # => "\xB2#\x10\xE7n"

cipher.decrypt
cipher.iv = iv
decrypted = cipher.update(encrypted) # => "hello"

Sau bao nhiêu vất vả thì cũng tìm được cái key =)) Vậy quá trình mã hoá như thế nào? Lại mò tiếp .__.

Encryption Process

Hãy cùng bắt đầu từ việc khai báo trong model

class Article < ApplicationRecord
encrypts :title
end

Rồi cùng tìm xem ApplicationRecord.encrypts nó làm trò gì nào

Tham khảo

· 3 min read
Lê Sĩ Bích

WebSocket là gì

Cũng giống như HTTP, WebSocket là 1 protocol, hoạt động trên mô hình client/server, và sử dụng TCP connection. Là một protocol, có nghĩa là bất kể việc implement ra sao, nhưng server cứ lắng nghe 1 TCP port, và giao tiếp giữa client/server tuân theo đúng spec mà WebSocket đề ra là được.

WebSocket cho phép trao đổi dữ liệu 2 chiều giữa client và server. Tuy nhiên chắc sẽ có nhiều người thắc mắc

Sao không dùng HTTP rồi set interval request lên, hay là server push cho đơn giản. Đẻ ra lắm protocol làm gì đau đầu?

Nếu sử dụng HTTP, mỗi lần cập nhật data mới thì client lại phải tạo request HTTP, và sẽ có rất nhiều header dư thừa, gây lãng phí băng thông, và việc khởi tạo request cũng mất thêm 1 chút thời gian. Trong khi đó WebSocket, sau khi client và server say hello với nhau, TCP connection sẽ vẫn alive, và chúng sẽ giao lưu kết hợp với nhau qua connection đó mà không cần thêm những thông tin dư thừa như header. Và có lẽ còn nhiều lợi ích nữa, nhưng mình không biết =))

Khen thế đủ rồi, hãy thử tìm hiểu xem WebSocket ngang dọc ra sao.

Cách hoạt động của WebSocket

Tiền đề

Ví dụ với ứng dụng mạng xã hội, ta có 1 tính năng chat. Mỗi khi bật chat với 1 người, 1 WebSocket tới webserver của ta sẽ được khởi tạo. Như vậy, ta đang có 1 webserver, và đang cần 1 websocket connection tới webserver đó. Mặt khác việc sử dụng raw TCP trên client cũng rất hạn chế. Chính vì vậy, WebSocket đã tận dụng luôn port 80/443 của HTTP(S) để khởi tạo connection.

Handshaking

Khi khởi tạo connection, client sẽ tạo 1 HTTP request để thực hiện handshake với server

handshake

  • Trước tiên client sẽ gửi request tới endpoint mà websocket server đang lắng nghe. ví dụ như /chat. Request sẽ kèm theo 1 vài header mà WebSocket protocol quy định: Sec-WebSocket-Key, Sec-WebSocket-Version, Upgrade, Connection, ... và những header cơ bản của 1 HTTP request khác nữa.

  • WebSocket server sẽ tiếp nhận request, authen (nếu có), nếu không hợp lệ sẽ trả về 400 Bad Request và terminate connection đó. Ngược lại nếu OK, server sẽ trả về 101 Switching Protocols cùng với header Sec-WebSocket-Accept. Connection đó sẽ được giữ, và sau đó client và server bắt đầu trao đổi thông tin qua lại với nhau.

Giá trị của Sec-WebSocket-Accept được quy định như sau:

Sec-WebSocket-Accept = Base64( SHA1 ( Sec-WebSocket-Key + 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 ) )

258EAFA5-E914-47DA-95CA-C5AB0DC85B11 còn được gọi là magic string

Trao đổi dữ liệu

Việc trao đổi dữ liệu giữa client và server khá là hại não, cụ thể việc decode message, hay format message có thể xem thêm tại đây. Giữ chỗ để sau này nếu không lười bận quay lại tìm hiểu sau =))

Trong quá trình connection được keep alive, sẽ có rất nhiều request ping giữa client/server để kiểm tra xem phía bên kia còn active hay không. Bên gửi ping, bên nhận pong, vẫn còn sống thì ta lại giao lưu kết hợp tiếp. Còn không thì server/client sẽ biết để terminate inactive connection đó đi.

Tham khảo

· 8 min read
Lê Sĩ Bích

Khi mới bắt đầu code, có thể chúng ta rất ngại handle những exception mà ngay cả 1 hàm đơn giản nhất cũng có thể tung ra. Tuy nhiên, thực tế khi xây dựng hệ thống, ta phải đặc biệt chú ý đến những exception, không thì ứng dụng của ta có thể thăng bất cứ lúc nào :v

Vậy thì làm sao để handle chúng 1 cách thật clean. Có khá nhiều hướng tiếp cận, tuy nhiên ta hãy cùng thử trải nghiệm theo hướng Railway Oriented xem nó có gì hay.

Bài giới thiệu gốc được viết sử dụng ngôn ngữ F#, nhưng ta hoàn toàn có thể áp dụng vào các ngôn ngữ khác như Javascript, Ruby, ...

Railway Oriented Programming phù hợp với style lập trình hàm (Functional Programming - FP)

Tên gọi là Railway cũng bởi trông nó khá giống với đường ray tàu hỏa.

Vấn đề

Hãy bắt đầu với 1 usecase rất cơ bản

Người dùng muốn cập nhật profile của họ.

Sau khi người dùng submit thông tin ở web, ta hay cùng phân tích những xử lý ở phía server

Tình huống đẹp nhất xảy ra là từ bước 1-5, ứng dụng ta sẽ chạy trơn tru, không có bất cứ 1 lỗi nào.

Nhưng mà ...

Đời không như mơ, tình không như thơ.

Từ bước 1-4 đều có thể có lỗi xảy ra, và tất nhiên người dùng sẽ không hề muốn nhìn thấy cảnh này

Vậy thì những gì ta cần làm là xử lý những lỗi này, không thì người dùng một đi không trở lại luôn.

Và ta sẽ viết code cho nó:

function updateUser(user) {
const request = receiveRequest();
if (!isValidRequest(request)) {
return "Request is forbidden";
}
if (!isValidUser(request)) {
return "User information is invalid";
}
try {
saveToDatabase(request);
} catch (error) {
return "DB error";
}
try {
sendEmail(request);
} catch (error) {
return "Mailer error";
}
return "OK";
}

Code trên được viết theo style Imperative, vì thế nên ta có thể return bất cứ lúc nào ta muốn. Điều đó làm hàm của ta có thể return theo rất nhiều cách (nhiều kiểu response khác nhau).

Ta sẽ design lại flow theo style FP.

Hàm của ta giờ đây:

  • Chỉ có 2 kiểu trả về: Success hoặc Failure.

    • Success:

      // @flow
      type Success = { data: object };
    • Failure:

      // @flow
      type Failure = { error: string };
  • Use case được xây dựng từ 1 series các hàm con tương ứng với mỗi step.

Ta sẽ áp dụng Railway Oriented Programming để giải quyết vấn đề này.

Railway Oriented Programming

Monad

Trong lập trình hàm, có một cách để handle lỗi là dùng monad.

Monad thường đi kèm với Applicative và Functor nữa, bọn này khá là xoắn não nên mình sẽ không đề cập ở đây.

Ta sẽ chỉ quan tâm tới: Either monad.

// @flow
type Either<A, B> = A | B;
type FunctionReturnMonad<A, B> = () => Either<A, B>;

Hiểu một cách nôm na sẽ là: hàm của ta sẽ luôn trả về A hoặc B, nhưng không bao giờ trả về cả 2.

Switch

Hãy bắt đầu với 1 function có thể gây ra lỗi:

function validateNameNotBlank(user) {
if (user.name === "") {
return { error: "Name is blank" };
}
return { data: user };
}

Đây chính là 1 switch, nó rẽ nhánh luồng xử lý của ta thành SuccessFailure.

Kết nối nhiều switch

Đây là đường ray hoàn chỉnh mà ta cần xây dựng từ những switch riêng lẻ trên.

Có thể nhận thấy một vài điểm quan trọng ở railway này:

  • Khi một step bị lỗi, nó sẽ không return function ngay lập tức, mà sẽ tiếp tục chạy vào các function tiếp theo cho tới khi kết thúc flow.

    Tuy nhiên kết quả cuối cùng nhận được chỉ là lỗi đầu tiên phát sinh.

  • Những hàm của từng step đều phải xử lý cả trường hợp có dữ liệu và trường hợp hàm trước trả về lỗi

Bây giờ vấn đề là làm thế nào để nối những switch lại với nhau?

Câu trả lời là compose. Tuy nhiên ta không thể compose theo cách thông thường được.

Ví dụ như:

Nếu đầu vào và đầu ra của ta cùng interface

const mul2 = (num) => num * 2;
const add1 = (num) => num + 1;
mul2(add1(1)); // 4

Trở lại hàm validateBlank ở trên, nếu ta có nhiều hàm validate khác tương tự

Ta có thể thấy đầu vào chỉ có 1, mà lại có những 2 đầu ra.

Để có thể compose, ta sẽ phải biến chúng thành những function có thể handle cả trường hợp Success lẫn Failure.

Có thể sử dụng HOC

const transformToTwoTrackInput =
(func) =>
({ data, error }) => {
return data ? func(data) : { error };
};

const twoTrackValidateNameNotBlank =
transformToTwoTrackInput(validateNameNotBlank);
const twoTrackValidateName50 = transformToTwoTrackInput(validateName50);
const twoTrackValidateEmailNotBlank = transformToTwoTrackInput(
validateEmailNotBlank
);

const user = { email: "", name: "" };
twoTrackValidateEmailNotBlank(
twoTrackValidateName50(twoTrackValidateNameNotBlank({ data: user }))
); // { error: 'name is blank' }

Như vậy là ta đã kết nối được những mảnh ghép trên với nhau.

Một vài kiểu function thường gặp

Single track function

Nếu một function không gây ra lỗi (chỉ có 1 đầu vào và 1 đầu ra) thì nó sẽ không thể nào compose được vào railway của chúng ta.

Khi đó ta phải wrap nó bởi 2-track function, giống với HOC ở trên.

const trimEmail(user) {
return {
...user,
email: user.email.trim()
}
}

const transformSingleTrackToTwoTrackInput = func => ({ data, error }) => {
return data ? func(data) : { error }
}

const user = { email: ' sample@email.com' }
transformSingleTrackToTwoTrackInput(trimEmail)({ data: user })
Dead-end function

Dead-end function là những hàm void, không có giá trị trả về

Màu tím chính là nơi ta sẽ đặt dead-end function vào

const transformDeadEndFunction =
(func) =>
({ data, error }) => {
if (data) {
func();
return { data };
} else {
return { error };
}
};
Function throw Exception

Ta có thể đặt try-catch để trả về Failure

const transformExceptionFunction =
(func) =>
({ data, error }) => {
if (data) {
try {
func();
} catch (error) {
return { error: error.message || error };
}
return { data };
} else {
return { error };
}
};

Note: Convert tất cả Exception thành Failure

Kết quả

Ta không thể trả về dữ liệu kiểu two-track cho client được, vì vậy ta sẽ có thêm 1 bước cuối để trả về thông tin cho client.

function returnMessage({ data, error }) {
return data ? JSON.stringify(data) : error.toString();
}

ROP trong một số ngôn ngữ khác

Ruby (framework Rails)

Nếu các bạn sử dụng Rails, hãy thử trải nghiệm qua gem trailblazer. Logic của ứng dụng giờ sẽ tập trung chủ yếu trong các Operation thay vì controller như xưa nữa, mà những operation này được viết theo style ROP.

class Song::Create < Trailblazer::Operation
step Model(Song, :new) # init model
step :assign_current_user!
step Contract::Build(constant: SongForm) # create form object
step Contract::Validate() # validate form object
failure :log_error!
step Contract::Persist() # save song to db

def log_error!(options)
logger.debug "Errors occurred while creating song."
end

def assign_current_user!(options)
options["model"].created_by = options["current_user"]
end
end

Flow của Operation không hoàn toàn giống với ROP như ta đã thấy ở trên, một khi bạn đã vào nhánh Failure, nó sẽ trigger toàn bộ những step handle error phía sau.

Không liên quan lắm nhưng trong trailblazer ecosystem có khá nhiều gem thú vị như: reform (form object pattern), và cells (view components).

Javascript

Nếu ta để ý, Promise của Javascript cũng khá giống với ROP.

const user = { username: "sample", email: "sample" };

const validatePresenceOfUsername = (data) => {
if (!!data.username) {
return user;
}
throw "Username is blank";
};

const validateFormatOfEmail = (data) => {
if (data.email && data.email.match(/@/g)) {
return user;
}
throw "Email is in invalid format";
};

const logError = (error) => console.error(error);

Promise.resolve(user)
.then(validatePresenceOfUsername)
.then(validateFormatOfEmail)
.catch(logError); // => 'Email is in invalid format

Tham khảo

https://fsharpforfunandprofit.com/rop/

https://fsharpforfunandprofit.com/posts/function-composition/

https://dorp.io/posts/railway-oriented-programming/

https://github.com/trailblazer/trailblazer

http://trailblazer.to/gems/operation/2.0/api.html

· 11 min read
Lê Sĩ Bích

Ngày nay, công nghệ ngày càng phát triển, và thế giới Web cũng vậy. Đa số web hiện đại đều đã nói lời tạm biệt với những dòng Ruby, PHP, hay Java được nhúng trong HTML/JS. Phần giao diện người dùng được chính browser phía client xử lý, thay vì server ôm hết như xưa. Các thư viện/framework như React, Angular, Vue, ... đều đã trở nên quá quen thuộc.

Nếu bạn có ý định học hay đã chuyển sang React thì mong bài viết có thể giúp các bạn có những mindset tốt hơn khi làm việc với nó.

Đây đều là những thứ mình cho rằng cần quan tâm sau 1 thời gian làm việc với React.

Bài viết này không nói về việc hướng dẫn code React.

Component

React is all about components

React được design theo hướng Component, mỗi phần tử nhỏ nhất như thẻ <span>, hay <button> đều có thể wrap thành một component để tái sử dụng 1 cách tối đa.

// path/to/button.jsx
export function Button({ children, type, onClick }) {
return (
<button type="button" className={`btn btn-${type}`} onClick={onClick}>
{children}
</button>
);
}

Và ở đâu cần component này, ta sẽ import nó vào để sử dụng.

import { Button } from "./path/to/button";

function Screen() {
return (
<Button type="primary" onClick={() => console.log("Clicked")}>
Click me
</Button>
);
}

Với những ngôn ngữ server side truyền thống, ta sẽ viết như sau (slim ruby):

/ path/to/a.slim
button.btn.btn-primary
| Button A
/ path/to/b.slim
button.btn.btn-primary
| Button B

Có thể thấy là code của ta trông sáng sủa hơn rất nhiều.

Trên thực tế, ta cũng nên viết những component nhỏ nhất có thể như vậy, nó sẽ giúp giao diện app ta đồng bộ, và debug cũng trở nên dễ hơn.

Hay thử với một component phức tạp hơn hơn xíu:

function List({ items, renderItem, emptyText }) {
if (items.length === 0) {
return (
<div>
<span>{emptyText}</span>
</div>
);
}

return <div>{items.map((item) => renderItem(item))}</div>;
}

Cấu trúc thư mục

Đối với những dự án lớn, có một cấu trúc thư mục rõ ràng sẽ khiến việc code trở nên dễ chịu hơn nhiều.

Lại quay lại các ngôn ngữ server side MVC cũ - Rails. Đây là một cấu trúc khó mà có thể thay đổi trong tất cả các dự án:

Dù với sự hỗ trợ của các Editor/IDE hiện đại trong việc tìm kiếm, mở file, thì cũng khá mất thời gian để có thể tìm được những file liên quan.

Với React thì flexible hơn, bạn có thể tổ chức theo kiểu trên (VD cho 1 project dùng Redux)

Nhưng với mình thì mình thích cách tổ chức theo component/màn hình hơn.

Mình học được cấu trúc trên từ một dự án trong list awesome react native - Gitpoint, dù nó được viết bằng React Native nhưng bản chất vẫn là React nên không có vấn đề gì hết.

Tuy nhiên cấu trúc này gặp 1 nhược điểm ở chỗ nếu 2 màn hình mà share nhau chung 1 state (redux) thì sẽ gây bối rối, hoặc là lặp code. Với mình, mình chọn giải pháp tạo 1 thư mục shared, rồi cũng tổ chức file giống cấu trúc của thư mục screens. Còn không thì chấp nhận việc code bị lặp 1 chút.

Functional Programming (FP)

Nếu như Ruby, Java là các ngôn ngữ lập trình hướng đối tượng (OOP) thì Javascript lại mang phong cách lập trình hàm, mặc dù vẫn có class, object nếu bạn muốn dùng (Prototype)

Với OOP, ta thường xuyên thay đổi trạng thái (các biến instance) của object, nhưng FP lại không thích điều này, mà thường hướng tới tính bất biến (Immutability) và pure function. Ta hãy cũng tìm hiểu thêm về chúng

Pure Functions

Lấy ví dụ với việc cộng 2 số tự nhiên

const z = 10;
const add = (x, y) => x + y;
add(1, 2); // 3
add(1, 3); // 4

Hàm add nhận 2 tham số xy, nó chỉ sử dụng 2 tham số đầu vào này để thực hiện phép tính, mà không sử dụng/làm thay đổi các biến ngoài phạm vi hàm.

Hơn nữa nó luôn trả về cùng 1 giá trị nếu như tham số đầu vào không thay đổi.

Còn xem hàm dưới đây

const bonus = 5;
const add = (x, y) => x + y + bonus;
add(1, 2); // 3
add(1, 2); // 3

Dù luôn trả về một giá trị với cùng tham số, tuy nhiên hàm lại phụ thuộc vào biến bonus (external variable) nên đây được xem là 1 impure function.

Ngoài ra impure function cũng gây ra các side effects như các hàm sau:

  • Gọi HTTP request
  • Ghi dữ liệu
  • Math.random(), new Date()
  • ....

Giá trị trả về của chúng không phải lúc nào cũng giống nhau, điều đó khiến kết quả của hàm khó mà lường trước được, khi test ta thường phải mock 1 giá trị cố định.

Pure function sẽ giúp app chúng ta ít lỗi hơn, ngoài ra cũng dễ dàng test hơn.

Trong React, nói đến pure function ta thường nghĩ đến stateless component - Functional Component, nó sẽ chỉ sử dụng props để tính toán và render dựa trên những props đó. Tuy nhiên những update gần đây đã thêm Hook, nó làm cho Functional Component cũng có thể có state. Cá nhân mình không thích cái Hook này lắm.

Nhưng app của ta không chỉ toàn pure function được, sẽ phải có những hàm gọi API, thay đổi state, lấy state để tính toán, lưu dữ liệu vào localStorage, ... nhưng hãy cố gắng giảm thiểu số lượng side effects xuống thấp nhất có thể.

Immutability

Một điều quan trọng nữa là tính bất biến.

Functional programming nói chung và React nói riêng, ta thường tránh việc sửa trực tiếp 1 biến nào đó, hay state. Thay vào đó, ta sẽ tạo 1 biến mới.

const person = {
age: 12,
};
person.name = "Name";

let array = [1, 2, 3];
array.push(4);

Nếu trong dự án của bạn có những dòng code như trên, thì code bạn đã mất tính bất biến. Thay vì trực tiếp chỉnh sửa 1 biến như vậy. Ta nên tạo 1 biến mới với những giá trị cũ, sau đó thêm giá trị mới vào.

const updatedPerson = {
age: person.age,
name: "Name",
};
// hay
const updatedPerson = {
...person,
name: "Name",
};

Dễ dàng nhận thấy updatedPerson.age vẫn tham chiếu đến giá trị cũ của person.name, tuy nhiên ta sử dụng biến updatedPerson này thế nào đi nữa, thì cũng sẽ không ảnh hưởng đến giá trị của person

Nhưng tại sao lại phải làm vậy? Thử xét 1 vòng lặp đơn giản như:

let s = 0;
let index = 0;
for (index = 0; index < data.length; index++) {
s += data[index];
}

Giả sử đang trong quá trình lặp, thi data[n] bị thay đổi, chẳng phải s += data[index] sẽ sai luôn hay sao.

Còn trong React, ta có React.PureComponent nó sẽ shallow compare props và state để quyết định xem có update component hay không.

export class SampleComponent extends React.PureComponent {
state = {
filter: {
name: "A name",
age: 21,
},
};

// shouldComponentUpdate(nextProps, nextState) {
// return shallowCompare(this, nextProps, nextState)
// }

handleClick = () => (this.state.filter.name = "New name");

render() {
return (
<div>
<h3>{this.state.filter.name}</h3>
<button onClick={this.handleClick}>Click me</button>
</div>
);
}
}

React.PureComponent đã định nghĩa sẵn cho ta phương thức shouldComponentUpdate như phần mình comment.

Hàm shallowCompare chỉ đơn thuần lặp tất cả các key có trong props và state, so sánh với state/props cũ.

Nó sẽ thực hiện việc so sánh currentState.filter === nextState.filter (so sánh bằng tham chiếu).

Việc này có lợi hơn rất nhiều so với việc deep compare tất cả các giá trị trong filter (cả về thời gian lẫn độ phức tạp).

Tuy nhiên, khi chúng ta trực tiếp chỉnh sửa this.state.filter.name = 'New name', sẽ khiến filter không hề thay đổi về tham chiếu. Khi đó:

currentState.filter === nextState.filter; // true
currentState.filter.name === nextState.filter.name; // false

SampleComponent của ta cũng sẽ không re-render, cho dù bạn có click đến sang năm.

Thay vào đó ta sẽ làm như sau

handleClick = () => {
this.setState({ filter: { ...this.state.filter, name: "New name" } });
};

Ta copy toàn bộ tham chiếu các attribute của state.filter cũ sang 1 object mới, và sau đó thay đổi biến name của object mới này, ta không hề làm thay đổi state.filter cũ.

Khi đó currentState.filter === nextState.filter sẽ trả về false. SampleComponent của ta được re-render lại. Và nếu có action nào không làm thay đổi state, component của ta cũng sẽ không re-render. Vậy là cả React và ta đều happy - một người khỏe, 2 người vui :v

Higher-Order Functions (HOF)

HOF nhận tham số là hàm, hoặc trả về một hàm khác, hoặc là cả 2.

VD 1 hàm nhận tham số hàm:

const name = "React";
const phoneNumber = "0969696969";
const numberValidator = (str) => str.match(/\d+/g);
const validate = (value, validator) => !!validator(value);

validate(name, numberValidator); // false
validate(phoneNumber, numberValidator); // false

Hay 1 hàm trả về 1 hàm:

function makeAdder(constantValue) {
return function adder(value) {
return constantValue + value;
};
}

ta gọi hàm này như sau: makeAdder(10)(20)

Thoạt nhìn có vẻ sợ, nhưng nếu viết minh bạch ra

const add10 = makeAdder(10);
add10(20); // 30

Mọi thứ trở nên rõ ràng hơn nhiều, makerAdder(10) trả về một hàm, sau đó ta gọi hàm này với tham số là 20

const add10 = makeAdder(10);
// add10 = function adder(value) {
// return 10 + value
// }
add10(20);

Trong React, ta cũng thường xuyên áp dụng kỹ thuật này, tuy nhiên ngoài HOF, thì ta còn có Higher-Order Component (HOC), nhằm chỉ những hàm nhận vào tham số là 1 Component và trả về 1 Component khác.

VD:

function protectRoute(Component, requiredRole) {
return function ProtectedRoute(props) {
const currentRole = localStorage.getItem("role");
if (currentRole < requiredRole) {
return <Redirect to="/sign_in" />;
}
return <Component {...props} />;
};
}

Declarative Programming

Ta có 2 thiên hướng lập trình đối lập nhau, đó là:

  • Imperative Programming: mô tả control flow của việc cần làm
  • Declarative Programming: chỉ viết ra những gì cần làm mà không mô tả rõ control flow của từng bước.

VD tiêu biểu đó là 1 vòng lặp cơ bản:

Style Imperative:

const arr = [1, 2];
const newArr = [];
for (let i = 0; i < arr.length; i += 1) {
newArr.push(arr[i] + 1);
}
console.log(newArr); // [2, 3]

Với style này, bạn nêu lần lượt từng bước code bạn thực hiện như thế nào, ta phải đi sâu vào implementation hơn.

Trong khi đó với Declarative:

const arr = [1, 2];
const newArr = arr.map((element) => element + 1); // [2, 3]

Ta sẽ chỉ nói rằng ta cần 1 mảng mới từ arr, mà mỗi phần tử của nó tăng lên 1. Code của ta vừa dễ hiểu và vừa đẹp hơn.

Một số ngôn ngữ tiêu biểu:

  • Imperative: C/C++, Java, ...
  • Declarative: SQL, HTML, ...
  • Tạp phế lù: Javascript =)), ...

Ở trên là những gì mình search được trên google khi bắt đầu tìm hiểu về Declarative Programming. Tuy nhiên, vẫn khá là khó hiểu, và khó phân biệt giữa 2 thằng Imperative và Declarative

Tuy nhiên khi đọc được comment này, mọi thứ đã trở nên sáng sủa hơn nhiều. Mình coi nó là 1 lớp abstract, mà khi gọi hàm đó, ta chỉ cần quan tâm đến what to do mà không phải nghĩ xem how to do.

Hãy sử dụng các hàm có sẵn của javascript như: .map, .reduce, .filter, ... và bạn sẽ nhận thấy được vẻ đẹp của Declarative Programming.

Quay trở lại với React, vậy thì tính Declarative của nó ở đâu?

Chính bản thân các component React đã rất 'declarative' rồi.

Hãy đọc phần description của React trên Github

A declarative, efficient, and flexible JavaScript library for building user interfaces.

Thử so sánh 2 đoạn mã sau:

// jQuery
$(".like").click(function () {
const $btn = $(this);
if ($btn.hasClass("liked")) {
$btn.removeClass("liked");
} else {
$btn.addClass("liked");
}
});
// React
class LikeButton extends React.Component {
// ...codes
render() {
if (this.state.liked) {
return <HighlightButton>Like</HighlightButton>;
}
return <Button>Like</Button>;
}
}

Với jQuery, ta phải mô tả chính xác code ta cần làm gì.

Trong khi đó với React: Tiểu nhị, like rồi thì cho cái HightlightButton ra đây, không thì Button thường thôi.

Ta sẽ quan tâm đến việc component cần hiển thị cái gì tương ứng với mỗi (props/state) của nó.

Link tham khảo

https://github.com/facebook/react

https://github.com/jondot/awesome-react-native

https://github.com/gitpoint/git-point

https://medium.freecodecamp.org/all-the-fundamental-react-js-concepts-jammed-into-this-single-medium-article-c83f9b53eac2?gi=7fb0830efbd4

https://medium.com/@cscalfani/so-you-want-to-be-a-functional-programmer-part-1-1f15e387e536

https://www.miles.no/blogg/tema/teknisk/why-care-about-functional-programming-part-1-immutability

https://blog.logrocket.com/immutability-in-react-ebe55253a1cc

https://stackoverflow.com/questions/1784664/what-is-the-difference-between-declarative-and-imperative-programming#comment29365241_1784702