1. ปรับปรุง engine ใหม่ เร็วกว่า v3 ราว 3.5 เท่า (full build) และเร็วกว่า v3 ราว 100 เท่า (incremental build)
2. ตั้งค่า theme ใน CSS ตรงๆ ได้เลย ไม่ต้องใช้ไฟล์ tailwind.config.js เหมือนใน v3 แล้ว
3. ลาก่อน postcss-import / autoprefixer ใน v4 สามารถใช้ @import ได้เลย ไม่ต้องพึ่ง plugin นี้แล้ว เพราะ build-in มาในตัว
4. ระบบสีแบบใหม่ (P3) รองรับสีที่กว้าง และสดใสขึ้น
5. ตรวจจับ content อัตโนมัติ จาก .gitignore ได้เลย ไม่ต้องกำหนดในไฟล์ tailwind.config.js ก็ได้
คอร์ส “Tailwind CSS v4 Fundamentals” (4 ชั่วโมง) ดูได้แล้วนะครับ!
เหมาะสำหรับคนที่ยังไม่เคยใช้ หรือคนที่เคยใช้ v3 มาบ้างแล้วอยากอัปเดตว่ามีอะไรใหม่บ้าง และแน่นอนก่อนใช้ Tailwind ควรมีพื้นฐานการเขียน CSS แบบปกติมาก่อน นะครับ
ดูได้ที่นี่ https://bit.ly/4lg0z6T
โค้ชเอก
1. ออกแบบจากภายใน (Inside-Out)
ใช้โครงสร้างภายในมาเปิดเผยผ่าน API เช่น
GET /api/database/tables/book_inventory/records?status=1
GET /api/books?available=true
แนวคิดที่ถูกต้องคือ “นักพัฒนาจะเข้าใจสิ่งนี้ไหม ถ้าไม่รู้โครงสร้างระบบเราเลย?”
.
2. นิยาม URI ไม่ดี
หลีกเลี่ยงการใส่ verb ใน URL:
ตัวอย่าง:
GET /api/getUsers → GET /api/users
POST /api/createOrder → POST /api/orders
หลีกเลี่ยงการซ้อนโครงสร้างซับซ้อนเกินไป:
GET /api/companies/456/departments/2/employees/123/projects
GET /api/projects?employeeId=123
.
3. ใช้ HTTP Methods ผิด
ออกแบบ POST ทุกอย่าง = ไม่ดี
ตัวอย่าง:
POST /api/users/search → GET /api/users?name=Smith
DELETE /api/products/123
.
4. จัดการ Error ไม่ดี
ข้อความ error คลุมเครือ:
ตัวอย่างที่ไม่ดี:
{ “error”: “An error occurred” }
ตัวอย่างที่ดี:
{
“status”: 400,
“code”: “INVALID_PARAMETER”,
“message”: “The email address is improperly formatted”,
“details”: [{ “field”: “email”, “message”: “Must be a valid email address” }]
}
อย่าลืมใช้ HTTP Status Codes ให้เหมาะสม:
400: Bad Request
401: Unauthorized
403: Forbidden
404: Not Found
500: Server Error
.
5. ไม่จัดการเรื่อง Versioning
รูปแบบการจัด version ที่ดี:
แบบ URL: /api/v1/users
แบบ Header: Accept: application/vnd.company.api+json;version=1
แบบ Query: /api/users?version=1
อย่าลืมทำ document ความเปลี่ยนแปลง และแนวทางการอัปเกรดที่ชัดเจน
.
6. Response ซับซ้อนเกินไป
อย่าส่งทุกอย่างใน response เดียว ควรส่งเฉพาะข้อมูลที่จำเป็น:
ตัวอย่างที่ไม่ดี:
{
“id”: 123, “username”: “jsmith”, “email”: “jsmith@example.com”
}
ให้ใช้ query param เพื่อเลือก fields ที่ต้องการ:
ตัวอย่างที่ดี:
GET /api/users/123?fields=id,name,email
.
7. ละเลย Security
– ไม่ใช้ HTTPS หรือไม่มี token expiration
– ตรวจแค่การ authentication แต่ไม่ตรวจ authorization
– เผยข้อมูลสำคัญ หรือ sensitive data ผ่าน error หรือ response
– ไม่จำกัดอัตราการเรียก (Rate Limiting)
แนวทางที่ดี:
– ใช้ OAuth 2.0
– บังคับ HTTPS
– ตรวจสิทธิ์ทั้ง endpoint และระดับ object
– ใช้ HTTP 429 เมื่อถูกเรียกเกิน quota
.
8. ไม่มีหรือมีเอกสารที่แย่
– นักพัฒนาใช้ไม่ได้ = API ล้มเหลว
เอกสารที่ดีต้องมี:
– วิธีเริ่มต้น
– ตัวอย่าง request/response
– คำอธิบาย error
– SDK/Client library
– เปลี่ยนอะไรในแต่ละเวอร์ชัน
.
ใครที่เริ่มออกแบบหรือเขียน API ลองเอาไปใช้เป็นแนวทางดูนะครับ
โค้ชเอก
คำสั่ง อัปเกรด “Express.js” จาก v4 เป็น v5.x (LTS) แบบอัตโนมัติไม่ต้อง manual เอง
ถ้าอยากอัปเกรดเป็น Express.js v5.x แบบทั้งหมด ใช้คำสั่ง
npx @expressjs/codemod upgrade
หรือจะอัปเดตทีละตัวของการเปลี่ยนแปลงก็ได้
1. แปลงสตริง “back” ที่ถูกเลิกใช้
npx @expressjs/codemod magic-redirect
2. แปลงเมธอดให้เป็นพหูพจน์
npx @expressjs/codemod pluralized-methods
3. แปลงรูปแบบเมธอดที่ถูกเลิกใช้ใน Express v4
npx @expressjs/codemod v4-deprecated-signatures
4. เปลี่ยน req.param เป็นแบบใหม่
npx @expressjs/codemod req-param
สำหรับมือใหม่ที่เริ่มเขียน TypeScript มาสักพักนึงอยากให้ลองศึกษา Utility Types ของ TypeScript เพิ่มเติมกันด้วยนะครับ :)
.
1. Partial<Type>
ทำให้ทุก property ทั้งหมดใน type เป็น optional
ตัวอย่าง:
interface Customer {
id: string
name: string
}
type PartialCustomer = Partial<Customer>
// ผลลัพธ์: { id?: string; name?: string }
อาจใช้ในกรณี request ตอนอัปเดตข้อมูลก็ได้ เช่น UpdateCustomerRequest เป็นต้น
.
2. Record<Keys, Type>
ช่วยสร้างชนิดข้อมูล object ที่ key ของ property เป็น Keys และ value ของ property เป็น Type ได้
ตัวอย่าง:
type Staff = “John” | “Bob”
const canPlayFootball: Record<Staff, boolean> = {
John: true,
Bob: false,
}
และยังใช้ร่วมกับ Partial<Record<…>> เมื่อไม่ต้องการ map ทุก key แต่ยังอยากได้ type safety
.
3. Omit<Type, Keys>
ลบ property บางตัว ออกจาก type ที่ต้องการ
ตัวอย่าง:
interface Product {
name: string
price: number
}
type ProductWithName = Omit<Product, “price”>
// ผลลัพธ์: { name: string }
.
4. ReturnType<Type>
ดึงชนิดข้อมูล (type) ของฟังก์ชันแบบ return ค่า
ตัวอย่าง:
function multiply(a: number, b: number): number {
return a * b
}
type Multiply(Return = ReturnType<typeof multiply>
// ผลลัพธ์: number
.
5. Readonly<Type>
ทำให้ property ทั้งหมดไม่สามารถถูกแก้ไขได้ (readonly)
ตัวอย่าง:
function resetScore(score: Readonly<Score>) {
score.count = 0 // จะ Error ตรงนี้
}
ใช้สำหรับให้รู้ว่าค่าจะต้องไม่ถูกเปลี่ยน ช่วยให้อ่านง่าย และป้องกันการแก้ไขโดยไม่ได้ตั้งใจ
.
สรุป การใช้ utility types จะช่วยให้โค้ดมีความยืดหยุ่น ปลอดภัย และลดความซับซ้อนได้ดีมาก
และโดยปกติ utility types จะทำงานแค่ระดับเดียว หากทุกคนต้องการรองรับแบบหลายระดับ (deep support) แนะนำ library ชื่อว่า ts-toolbelt https://github.com/millsp/ts-toolbelt นะครับ
KendoReact (จากทีม Telerik) ปล่อย 50+ components ระดับ Enterprise-Grade ฟรี ไม่มีเงื่อนไขรวมถึง Data Grid! ใครสนใจลองดูนะครับ
ดูรายละเอียด และการติดตั้งที่นี่ครับ
อยากศึกษา/ทบทวน JS ล่าสุด แนะนำเล่มนี้ “Exploring JavaScript (ES2024 Edition)” ของ Dr. Axel อ่านแบบออนไลน์ได้ฟรีครับ
อ่าน ebook เล่มนี้ได้ที่นี่ครับ
Tailwind v4.1 ใหม่ มี text-shadow-* มาใน core แล้ว! เพิ่ม mask-* ใช้ภาพและ gradient ทำ mask สวยๆ และ drop-shadow-* มีสีให้ใช้แล้ว
อ่านเพิ่มเติมที่นี่ครับ
เขียน Dockerfile ให้ linting แบบ realtime และบอก best practices ลองอัปเดต หรือแค่ติดตั้ง extension “Docker” ก็จะได้ตัวนี้มาใช้เลยนะครับ