thảo luận Web Component - chia sẻ về kinh nghiệm làm việc

teeeeeeeee

Senior Member
Hế lô mấy thím!
Dạo gần đây e có cơ hội làm việc với web components. Nguyên nhân sâu xa là một team khác chuyên về platform đã build một library để sử dụng cho toàn bộ những dự án của công ty và họ chọn Web Component với lý do duy nhất là vì Framework Agnostic và vì mỗi element đều đc đóng gói styles của riêng nó. (Riêng em nghĩ điều này có thể dễ dàng đạt được bằng element bình thường)
Vì lần đầu nên e cũng khá hào hứng cho tới khi bắt tay vô làm thật thì cảm thấy thứ này khá là tệ hại
g8XXj8u.gif

Project e đang làm sử dụng React và để có thể sử dụng được với những library đang được sử dụng thì team e phải build một layer React wrapped lại những components của team kia để sử dụng (double công việc lên trong khi nếu sử dụng HTML element bình thường thì sẽ không có trường hợp này).
Lấy một ví dụ đơn giản thì component input của Web Component bên phía team họ làm không có khả năng hoạt động với HTML form element bình thường (điều này cũng có vẻ là do limitation của shadow DOM) => Team họ đang muốn viết thêm một Form element bằng WebComponent và e cũng không chắc là nó sẽ hoạt động tốt với một số lib bây giờ.

Lib e đang nói tới để sử dụng trong công việc form validation và error handling.

Điều thứ hai, là vì shadow DOM họ đang là mode open nên cây DOM cho browser cực kì khổng lồ
BdgiW7R.png
nhưng để mode close lại không thể được vì những framework E2E test không thể đọc được data của web component. (Và điều này cũng được raise một lần về vấn đề perf của webcomponent khi sử dụng với mode là open).

Em muốn nghe chia sẻ cũng như kinh nghiệm khi làm việc của các thím về web component.

Theo ý kiến cá nhân em thì cho tới thời điểm bây giờ, web component vẫn ko có điểm gì nổi trội để có thể chọn nó thay vì là HTML element bình thường
 
Thấy YouTube dùng webcomponent, chắc performance không phải vấn đề.

Còn lại chưa có dịp thử trên production :LOL:
 
Web components khá độc lập nên muốn custom cũng hơi khoai, và reuse lại các thành phần khác từ bên ngoài, việc query DOM trên WC cũng chuối cực kì.

Còn lại thì mình thấy tiện cho việc phát triển độc lập 1 tính năng nào đó mà nó nhất quán giữa các platform, có thể dễ dàng sử dụng và không ảnh hưởng tới trang chính (ví dụ tính năng login form, chỉ cần nhúng script của WC script src="domain.login-form.js" thì bạn sẽ có 1 form login độc lập trên trang web, một số trang làm microfrontend cũng implement cách này).
AE nào cao thủ thì xin chỉ giáo thêm.
 
Web components khá độc lập nên muốn custom cũng hơi khoai, và reuse lại các thành phần khác từ bên ngoài, việc query DOM trên WC cũng chuối cực kì.

Còn lại thì mình thấy tiện cho việc phát triển độc lập 1 tính năng nào đó mà nó nhất quán giữa các platform, có thể dễ dàng sử dụng và không ảnh hưởng tới trang chính (ví dụ tính năng login form, chỉ cần nhúng script của WC script src="domain.login-form.js" thì bạn sẽ có 1 form login độc lập trên trang web, một số trang làm microfrontend cũng implement cách này).
AE nào cao thủ thì xin chỉ giáo thêm.
Phải có người xây cái khung trước á bạn, rồi dùng cái component đó cho từng project con luôn, hồi xưa mình có chiến 1 con micrổnt bên nextjs, mà custom lắp ráp rất mệt, tut lại ít vl :shame:
 
Xét về tuổi đời thì nó có lẽ còn đâu đó sớm hơn AngularJS, lúc mà jQuery còn đang lộng hành trên web ý, mình nhớ k lầm thì đây là ý tưởng của mấy dev browser chrome của google thì phải, về 1 HTML mà có thể custom element, encapsulate, rồi state, binding data gì gì đó.

Ưu điểm của nó đến thời điểm hiện tại chắc là ko phụ thuộc và thư viện/framework nào của frontend, có thể hoạt động độc lập và hỗ trợ native bởi browser, có thể dùng custom element của bên thứ 3 làm sẵn, có thể kết hợp với các thư viện frontend hiện tại (?).

Thằng framework phổ biến cho cái web component này theo mình biết thì là thằng này Lit (https://lit.dev/), thấy bọn google hay xài, với mình thì nó chả ra làm sao cả.
 
Xét về tuổi đời thì nó có lẽ còn đâu đó sớm hơn AngularJS, lúc mà jQuery còn đang lộng hành trên web ý, mình nhớ k lầm thì đây là ý tưởng của mấy dev browser chrome của google thì phải, về 1 HTML mà có thể custom element, encapsulate, rồi state, binding data gì gì đó.

Ưu điểm của nó đến thời điểm hiện tại chắc là ko phụ thuộc và thư viện/framework nào của frontend, có thể hoạt động độc lập và hỗ trợ native bởi browser, có thể dùng custom element của bên thứ 3 làm sẵn, có thể kết hợp với các thư viện frontend hiện tại (?).

Thằng framework phổ biến cho cái web component này theo mình biết thì là thằng này Lit (https://lit.dev/), thấy bọn google hay xài, với mình thì nó chả ra làm sao cả.
cảm ơn thím, mình cũng đọc nhiều blog nói về Webcomponent này thì có lẽ công nghệ này có vấn đề thật
 
xjIzSG9.png
chắc chắn là phải raise r thím
Chủ đề thread này là kinh nghiệm làm việc với nó, chứ không phải là câu chuyện raise hay không raise
làm gì có kn, bởi vì chẳng cty đàng hoàng nào xài cả.
angular/react/vue chưa đủ hay gì, cty a ép xài cái bánh vẽ này mà a k raise sớm, còn cố chịu thì k hiểu cả 1 team từ leader tới culi làm cái gì, miệng đâu k nói
 
làm gì có kn, bởi vì chẳng cty đàng hoàng nào xài cả.
angular/react/vue chưa đủ hay gì, cty a ép xài cái bánh vẽ này mà a k raise sớm, còn cố chịu thì k hiểu cả 1 team từ leader tới culi làm cái gì, miệng đâu k nói
bạn ơi thế giới rộng lớn lắm, cty đàng hoàng là cty nào? google là cty đàng hoàng ko? vài team của google nó đang xài đấy.
bánh vẽ như nào là browser phải implement native nhỉ? trong khi bọn frontend framework thì ko đc pick để làm native như là 1 tiêu chuẩn của web?
tui chê vì cá nhân tui chê, chứ nó ko phải là phế thải đâu, giờ có dự án cần phải làm vì khách hàng yêu cầu vậy hoặc là rỗi quá học cho biết thêm cái gì đó thì cũng ko tệ lắm đâu.
 
bạn ơi thế giới rộng lớn lắm, cty đàng hoàng là cty nào? google là cty đàng hoàng ko? vài team của google nó đang xài đấy.
bánh vẽ như nào là browser phải implement native nhỉ? trong khi bọn frontend framework thì ko đc pick để làm native như là 1 tiêu chuẩn của web?
tui chê vì cá nhân tui chê, chứ nó ko phải là phế thải đâu, giờ có dự án cần phải làm vì khách hàng yêu cầu vậy hoặc là rỗi quá học cho biết thêm cái gì đó thì cũng ko tệ lắm đâu.
6gCweAP.png
Đồng ý với fence, đã không muốn gây nhau r mà còn khơi chuyện
Mong muốn @perepermin tiết lộ công ty đang hoàng của fence ấy
 
Phải có người xây cái khung trước á bạn, rồi dùng cái component đó cho từng project con luôn, hồi xưa mình có chiến 1 con micrổnt bên nextjs, mà custom lắp ráp rất mệt, tut lại ít vl :shame:

Bác làm modern framework còn đỡ, em làm cái prj dính ngay cái WC viết = JS thuần. Đù làm đúng gọi là khổ dâm :LOL:)) nhất là khoảng share/re-use. Đúng kiểu pain-in-my-a**, cơ mà cũng học đc nhiều thứ.
 
Trước em cũng tìm hiểu về thằng này nhưng không cách nào sử dụng trên nextjs đc:LOL:. Và rất khoai luôn
 
bạn ơi thế giới rộng lớn lắm, cty đàng hoàng là cty nào? google là cty đàng hoàng ko? vài team của google nó đang xài đấy.
bánh vẽ như nào là browser phải implement native nhỉ? trong khi bọn frontend framework thì ko đc pick để làm native như là 1 tiêu chuẩn của web?
tui chê vì cá nhân tui chê, chứ nó ko phải là phế thải đâu, giờ có dự án cần phải làm vì khách hàng yêu cầu vậy hoặc là rỗi quá học cho biết thêm cái gì đó thì cũng ko tệ lắm đâu.
vài team thì sao, native cái mẹ gì trong khi đéo có ai xài
ăn bánh vẽ lú cả người còn chưa chịu tỉnh
 
vài team thì sao, native cái mẹ gì trong khi đéo có ai xài
ăn bánh vẽ lú cả người còn chưa chịu tỉnh
Mọi thứ nó được sinh ra đều có lý do của nó, không phải chỉ vì nhìn nó ngầu th mà được chọn :go:
mà fence có vẻ cay cú nhỉ


via theNEXTvoz for iPhone
 
Mấy bác cho e xin ý tưởng vs ạ, em cần code 1 leadform sao cho flexible nhất có thể, các bên khác cx có thể nhúng vào, trong leadform thì các field cx có thể động đc tùy mình cần hiển thị field nào,...
 
Back
Top