Tạo thư viện JS

Đây không phải là bài đăng về cách tạo thư viện JS mà là quá trình tôi đã thực hiện trong khi tạo. Tôi chắc chắn sẽ đi sâu vào cách thức và điều gì nhưng nó chủ yếu liên quan đến lý do tại sao của mọi thứ. Hãy bắt đầu nào…

Khởi đầu

Vào tháng 8 năm 2021, tôi quyết định tạo một thư viện JS theo ý thích. Tôi không biết thư viện nên nói về cái gì nhưng tôi cần một nơi nào đó để bắt đầu vì vậy tôi quyết định sao chép một gói hiện có. Tôi đã sử dụng node-lru-cache một gói đơn giản để xử lý đối tượng-cache dựa trên cơ sở ít được sử dụng gần đây nhất (đó là viết tắt của LRU). Nó được viết hoàn toàn bằng JavaScript (JS) nên tôi quyết định viết lại nó trong TypeScript (TS). node-lru-cache đã có gói định dạng vì vậy tôi không đóng góp đáng kể cho cộng đồng nhưng đó là một sự khởi đầu.

TS là công việc của tôi kể từ khi tôi nhận ra tầm quan trọng của việc xử lý lỗi sớm. Ôi những ngày đầu tôi thường ngồi để gỡ lỗi mã chỉ để nhận ra 1đó là một chuỗi chứ không phải số và JS nghiêm ngặt bình đẳng ( ===) sẽ thất bại. Chỉ khi tôi biết TS hồi đó.

Thư viện mà tôi đang xây dựng phải có sẵn thông qua thẻ script và không chỉ trên sổ đăng ký npm. Vì vậy, tôi cần một trình gói để rút gọn và gói mã thành một gói nhỏ. Tôi đã sử dụng Webpack vì tôi đã sử dụng nó ở những nơi làm việc trước đây. Câu chuyện - Tôi đã cân nhắc sử dụng Rollup hoặc Parcel và đi xuống lỗ thỏ để thử so sánh 3 gói. Sau vài ngày lãng phí, tôi quyết định chọn lựa chọn quen thuộc nhất - do đó là webpack.

Độ lệch

Webpack không hỗ trợ gói TS ra khỏi hộp nhưng nó có thể đạt được bằng ts-loader . README trong ts-loader đề xuất sử dụng Khai báoBundlerPlugin để đóng gói các khai báo. Bây giờ vấn đề là tôi đã sử dụng webpack 5 và statementBundlerPlugin được xây dựng cho webpack 4 nên nó không hoạt động với tôi và để làm cho vấn đề tồi tệ hơn, gói không còn được tác giả duy trì. Vì vậy, tôi quyết định phân tách kho lưu trữ và cập nhật nó để hỗ trợ webpack 5. Tôi đã đặt ra con đường sao chép một thư viện và chuyển sang tạo một thư viện mới để hỗ trợ tôi. Kết quả - styles-webpack-Bundler - gói đầu tiên của tôi (sau 3 năm - tôi có 2 gói mà tôi đã tạo cách đây 3 năm không thực sự được sử dụng) đã được tạo ra.

Trở lại đường đua

Tôi không muốn từ bỏ việc tạo Bộ đệm ẩn LRU dựa trên TS nên tôi đã tiếp tục với nó. Tôi đã không sao chép mã như hiện tại mà sử dụng nó như một hướng dẫn tham khảo để xác định các API.

Một thư viện cần phải đáng tin cậy và đối với điều này, thư viện cần phải kiểm tra chức năng. Do đó, tôi đã sử dụng Jest để viết bài kiểm tra đơn vị trong khi theo dõi phát triển theo hướng kiểm tra (TDD). Điều này đã giúp tôi bảo hiểm 99%. Không tệ cho người mới bắt đầu, phải không?

Bit cuối cùng là xuất bản gói lên sổ đăng ký npm. Đây là một lệnh xuất bản sợi đơn giản. Nó sẽ yêu cầu bạn đăng nhập bằng thông tin đăng nhập npm của bạn và trong vài giây, gói - lru-cache-ts - đã hoạt động.

Vào cuối bài tập trên, tôi đã có 2 gói mới trực tiếp trên npm.

Ý tưởng 💡

Vài ngày sau, tôi đang làm việc trong một dự án NextJS thì tôi bắt gặp thư viện SWR . SWR là một chiến lược trước tiên trả lại dữ liệu từ bộ nhớ cache (cũ), sau đó gửi yêu cầu tìm nạp (xác thực lại) và cuối cùng là dữ liệu cập nhật. Và điều này chỉ có sẵn cho các nhà phát triển sử dụng ReactJS. Tôi thích khái niệm và nghĩ đến việc triển khai một cái gì đó tương tự cho Vue.js và / hoặc Angular. Một tìm kiếm nhanh trên Google cho thấy rằng các khung công tác này đã có các gói tương tự nhưng không có gì thuộc loại này khả dụng cho các nhà phát triển làm việc với VanillaJS .

Người ta sẽ nói rằng không ai sử dụng VanillaJS nhưng tôi nghĩ nếu nó hoạt động với VanillaJS thì nó sẽ hoạt động với bất kỳ khuôn khổ JS nào khác.

Các khuôn khổ đến và đi, nhưng VanillaJS là mãi mãi.

Tôi đã bắt đầu sử dụng cách tiếp cận từ quá trình phát triển thư viện trước đây của mình. Đọc mã SWR và cố gắng tái tạo các chức năng với cách tiếp cận TDD. Vấn đề chính mà tôi phải đối mặt là các khung công tác như Vue.js và ReactJS có khả năng phản ứng không ổn định. JS khác xa với khái niệm này khi nói đến khả năng phản ứng. Tôi đã nghĩ đến việc thêm RxJS vào sự phát triển của mình để đạt được điều này nhưng sau đó nó đã ập đến với tôi - người ta không dùng đại bác để giết muỗi. Tôi chỉ cần phần khả năng quan sát của RxJS và vì vậy tôi quyết định triển khai phiên bản của riêng mình Observable. Nó có thể không phức tạp như RxJS nhưng nó hoàn thành công việc. Sau một tháng làm việc trên đó trong thời gian rảnh, cuối cùng tôi đã phát hành phiên bản SWR của mình cho VanillaJS - vanilla-swr .

Lỗi đầu tiên

Đây là điều mà tôi đặc biệt tự hào, do đó tôi đã thông báo nó với các đồng nghiệp của mình tại CleverTap. Một đồng nghiệp tốt của tôi ( harshit pandey ) đã sử dụng nó trong một dự án của anh ấy và nói với tôi rằng nó không hoạt động. Tôi quay lại mã của mình chỉ để nhận ra rằng trong sự phấn khích của tôi khi xuất bản gói, tôi đã quên để lộ thư viện khỏi cấu hình webpack. Chắc chắn là một khoảnh khắc đáng xấu hổ nhưng tôi đã học được một điều có giá trị.

Luôn kiểm tra trước khi xuất bản.

Tôi hầu như không có bất kỳ tài liệu nào tại chỗ. Nó rất khó sử dụng. Tôi đã khắc phục sự cố, nhanh chóng trích xuất (giống như sao chép một cách vô liêm sỉ) các phần liên quan của tài liệu SWR gốc sang tệp README của tôi và xuất bản phiên bản vá lỗi.

Ứng dụng demo

Kiểm tra tích hợp sẽ là một cách tốt để kiểm tra thư viện để tránh thêm bất kỳ sự bối rối nào nhưng sau đó tôi tự nghĩ tại sao không tạo các ứng dụng demo với vanilla-js và một vài khung công tác phổ biến để giới thiệu cách API được sử dụng. Vì vậy, tôi đã dành một chút thời gian để tạo các ví dụ để sử dụng với VanillaJS, ReactJS và Vue.js.

Vẻ ngoài chuyên nghiệp

Tất cả các tài liệu đều được viết bằng README mặc dù cá nhân tôi nghĩ rằng tài liệu README rất khó đọc. Tôi cần một cái gì đó đẹp mắt về mặt thẩm mỹ nên tôi đã tìm kiếm các gói có thể giải quyết vấn đề này cho tôi. Docsify.js để giải cứu cho tôi. Đó là một gói dễ sử dụng và với một chút nỗ lực, tôi đã có một tài liệu có thể đọc được. Những người tốt tại js.org hãy để tôi lưu trữ tài liệu miễn phí và 🎉 🎉 tài liệu chuyên nghiệp - vanilla-swr.js.org .

Làm cho nó dễ dàng

Trong khi tạo các ứng dụng demo, tôi nhận ra rằng thư viện không thuận tiện để sử dụng. Nó buộc phải truyền hàm tìm nạp mỗi khi một hàm cần quan sát trở lại. Tôi biết mình phải cải thiện điều này nhưng vì những ưu tiên khác nên tôi chưa bao giờ đạt được nó, cho đến gần đây. Bây giờ tôi đã cập nhật gói để dễ sử dụng hơn. Mọi đề xuất khác từ các nhà phát triển đồng nghiệp để cải thiện trải nghiệm đều được hoan nghênh. Vui lòng tạo sự cố trên GitHub .

Sự kết luận

Trong hành trình này, tôi nhận ra rằng việc chuyển một khái niệm sẽ không hữu ích nếu nó không dễ sử dụng như ý tưởng ban đầu. Ngay cả các dự án phụ cũng có thể làm cho nó lớn. Tính đến ngày hôm nay, vanilla-swr có 60 lượt tải xuống hàng tuần trong khi type-webpack-Bundler có hơn 500 lượt tải xuống hàng tuần.

Hy vọng điều này sẽ truyền cảm hứng cho một số người bắt đầu đóng góp cho mã nguồn mở dù nhỏ đến đâu. Nguyên nhân…