Lời khuyên lập trình lâu đời không bao giờ tự viết thư viện phân tích cú pháp ngày tháng đã gây ra cuộc tranh luận gay gắt trong cộng đồng lập trình viên sau khi người tạo ra Eleventy đã phá vỡ quy tắc cơ bản này. Mặc dù bắt đầu bài viết của mình với chính lời cảnh báo này, anh ấy vẫn tiếp tục tạo ra @11ty/parse-date-strings , một thư viện phân tích cú pháp ngày tháng tùy chỉnh tương thích với RFC 9557 đã giảm đáng kể kích thước bundle từ 229 kB xuống chỉ còn 2.3 kB.
So sánh Kích thước Bundle
Package | Loại | Kích thước Disk | Kích thước Bundle |
---|---|---|---|
[email protected] | Dual | 4.59 MB | 81.6 kB (min) |
[email protected] | CJS | 4.35 MB | 204.9 kB (min) |
[email protected] | CJS | 670 kB | 6.9 kB (min) |
[email protected] | Dual | 22.6 MB | 77.2 kB (min) |
@11ty/[email protected] | ESM | 6.68 kB | 2.3 kB (min) |
![]() |
---|
Cuộc tranh luận về việc viết các thư viện phân tích cú pháp ngày tháng tùy chỉnh được làm nổi bật bởi các cuộc thảo luận trong cộng đồng nhà phát triển |
Sự Phân Chia Giữa Học Tập và Sản Xuất
Phản ứng của cộng đồng cho thấy một sự căng thẳng cơ bản trong triết lý phát triển phần mềm. Một số lập trình viên cho rằng việc giải quyết những vấn đề khó như phân tích cú pháp ngày tháng là điều cần thiết cho sự phát triển và học hỏi. Họ chỉ ra rằng tất cả các thư viện trưởng thành mà chúng ta dựa vào ngày nay đều bắt đầu như một implementation tùy chỉnh của ai đó. Tuy nhiên, những người khác nhấn mạnh sự khác biệt quan trọng giữa các bài tập học tập và code sản xuất.
Cứ viết đi. Chỉ là đừng sử dụng nó. Những cảnh báo này hầu như luôn trong bối cảnh code mà bạn sẽ phát hành, chứ không phải các bài tập học tập của riêng bạn.
Quan điểm này làm nổi bật rằng cảnh báo chống lại các thư viện ngày tháng tùy chỉnh không phải là để ngăn cản việc học tập, mà là để nhận ra việc kiểm thử và xử lý các trường hợp ngoại lệ khổng lồ mà các thư viện sẵn sàng sản xuất đã trải qua. Bản chất đã được kiểm nghiệm trong thực chiến của các thư viện đã được thiết lập đến từ hàng triệu lần sử dụng trong thế giới thực đã phơi bày các trường hợp góc cạnh mà các lập trình viên cá nhân có thể không bao giờ gặp phải.
Sự Phức Tạp Đằng Sau Những Ngày Tháng Đơn Giản
Cuộc thảo luận tiết lộ tại sao ngày tháng lại là lãnh thổ đặc biệt nguy hiểm cho các implementation tùy chỉnh. Ngoài những phức tạp rõ ràng về múi giờ, các lập trình viên đã chia sẻ những câu chuyện về những thách thức bất ngờ. Các ứng dụng y tế gặp khó khăn với việc ngày sinh thay đổi khi bệnh nhân di chuyển múi giờ. Các ứng dụng quốc tế phải xử lý nhiều hệ thống lịch, bao gồm lịch Nhật Bản với hệ thống định ngày dựa trên kỷ nguyên.
Cộng đồng cũng nêu bật bản chất chính trị của múi giờ, không phải là các cấu trúc toán học mà là các cấu trúc pháp lý thay đổi dựa trên quyết định của chính phủ. Điều này thêm một lớp phức tạp hoàn toàn khác vượt ra ngoài logic lập trình thuần túy.
So sánh hỗ trợ định dạng ngày tháng
Định dạng | ISO 8601 | Date.parse | Luxon | RFC 9557 |
---|---|---|---|---|
YYYY | ✔ | ✔ | ✖ | ✖ |
YYYY-MM | ✔ | ✔ | ✔ | ✖ |
YYYY-MM-DD | ✔ | ✔ | ✔ | ✔ |
YYYY-MM-DDTHH:II:SS | ✔ | ✖ | ✖ | ✖ |
YYYY-MM-DDTHH:II:SSZ | ✔ | ✖ | ✖ | ✔ |
✔ Được hỗ trợ ✖ Không được hỗ trợ
Các Giải Pháp Thực Tế và Cách Khắc Phục
Một số lập trình viên đã chia sẻ các cách tiếp cận trong thế giới thực của họ đối với các thách thức xử lý ngày tháng. Đối với các ứng dụng xử lý ngày sinh, một số đã chuyển sang coi ngày tháng như các chuỗi đơn giản thay vì các đối tượng thời gian, tránh hoàn toàn các lỗi liên quan đến múi giờ. Những người khác ủng hộ việc sử dụng các loại ngày tháng chuyên biệt như LocalDate hoặc PlainDate sắp tới của Temporal API cho các tình huống mà thông tin múi giờ không liên quan.
Cuộc thảo luận cũng đề cập đến các cân nhắc giao diện người dùng, với các lập trình viên tranh luận về ưu điểm của date picker so với các trường nhập văn bản. Trong khi date picker cung cấp nhiều kiểm soát hơn, chúng có thể cồng kềnh cho người dùng nhập ngày tháng xa trong quá khứ, như năm sinh.
Tác động Bundle của Eleventy
- Sử dụng Luxon trong @11ty/eleventy: 4.7 MB trên tổng 21.3 MB (22%)
- Sử dụng Luxon trong @11ty/client: 229 kB trên tổng 806 kB (28%)
- Tiết kiệm dự kiến: ~230 kB trong client bundle, node_modules giảm từ 21.3 MB xuống 16.6 MB
Thực Tế Kích Thước Bundle
Quyết định của Eleventy cuối cùng xuất phát từ các ràng buộc thực tế hơn là triết lý. Với Luxon tiêu thụ 22% bundle Node.js của họ và 28% bundle client, tác động hiệu suất là đáng kể. Trường hợp sử dụng cực kỳ cụ thể của họ - chỉ cần phân tích cú pháp ISO 8601 mà không cần định dạng hoặc hiển thị - đã làm cho giải pháp tùy chỉnh trở nên khả thi.
Cộng đồng thừa nhận rằng những yêu cầu cụ thể như vậy có thể biện minh cho các implementation tùy chỉnh, đặc biệt khi các thư viện hiện có không hỗ trợ tree-shaking hoặc khi trường hợp sử dụng cực kỳ hẹp. Tuy nhiên, họ nhấn mạnh rằng điều này nên là ngoại lệ hơn là quy tắc, và chỉ sau khi đánh giá kỹ lưỡng các lựa chọn thay thế hiện có.
Tham khảo: NEVER WRITE YOUR OWN DATE PARSING LIBRARY