"Mới trả hết nợ từ bài 1 xong, mọi bí ẩn xuất hiện trong đoạn kết của bài 1 đã được mình lột trần hết rồi nhé. Bây giờ lại mọc lên một đống nợ mới về Widget Lifecycle (mấy cái thuật ngữ như deactivate, dispose trong bài 6) và Navigation, Bloc Pattern, Provider...."
hehhe cảm ơn anh Khang đã chia sẽ
Chuẩn luôn anh ơi mình cũng phải xem môi trường như anh chia sẽ ^^ chứ không dễ toang
Bởi em làm với môi trường là start-up product anh em trong team như người nhà nên cũng dễ nói KHÔNG.
Mà em thấy mình cứ say yes hoài riết em thấy chính em bị thụ động trong công việc và không có quyết đoán nữa nên em bật mode phản dame ^^(theo cách tích cực ^^ )
Đôi khi cũng tùy môi trường, tùy văn hóa công ty, tính cách của boss mà từ KHÔNG có thể được hoặc không được sử dụng 😅
Bản thân mình cũng được trải nghiệm qua 2 môi trường làm việc là 1 công ty Đài Loan, và 1 công ty Đức (cả 2 đều ở VN), công ty Đài Loan có ông boss người Đài khá gò bó, kiểm soát, ít lắng nghe góp ý của cấp dưới, trong khi công ty Đức mình làm với nhiều ông boss khá nice, dễ chịu, thậm chí nói chuyện như mấy đứa bạn, cái gì không làm được là nói KHÔNG. Và công ty Đài mình thử việc 2 tháng xong bye luôn, còn công ty Đức thì làm tới giờ cũng đã được 1 khoảng thời gian 😄
Hi, cảm ơn bài viết của bạn. Mình xin có chút đóng góp để tổng kết lại và giải thích rõ hơn.
Khi thực thi code, trình biên dịch của JavaScript sẽ trải qua 2 quá trình: compilation và execution
1. Compilation
Ở bước này, trình biên dịch sẽ scan qua các function và các biến được khai báo. Khi bắt gặp các từ khóa: var, let, const, class, function, JavaScript sẽ tạo ra một không gian bộ nhớ cho mỗi thành phần được khai báo. Không gian bộ nhớ này là một cấu trúc dữ liệu của JavaScript, được gọi là Letxical Environment.
A lexical environment is a place where variables and functions live during the program execution.
Hiểu nôm na, lexical environment là nơi chứa các biến và hàm trong quá trình thực thi code, có dạng:
helloWorld();
function helloWorld(){
console.log('Hello World!');
}
Khi chạy qua đoạn code trên, lexical environment sẽ:
lexicalEnvironment = {
helloWorld: < func >
}
Cũng chính vì được đưa vào bộ nhớ trong quá trình compile, nên ta có thể truy cập vào những biến này trước khi chúng được khai báo trong code.
Quá trình đưa lên trên cùng của scope và cung cấp cho nó một không gian trong bộ nhớ được gọi là hoisting.
Ở bước này, những biến khai báo với var và function được hoisted và tự động được gán giá trị là undefined trong lexical environment.
Bởi JavaScript chỉ lưu các biến khai báo trong bộ nhớ, không lưu giá trị của biến đó, mà sẽ tự động gán là undefined. Ở giai đoạn execution, khi lệnh chạy đến nơi biến được gán giá trị, giá trị của biến trong lexical context được cập nhật từ udnefined thành giá trị trong code khai báo.
console.log(a); // undefined
var a = 3;
lexicalEnvironment = {
a: undefined
}
Với biến khai báo với let, const, class được hoisted nhưng vẫn giữ nguyên là uninitialized, không được khởi tạo giá trị.
2. Execution
Đến đây, trình biên dịch sẽ quay trở lại dòng code đầu tiên và chạy từ đầu đến cuối, lúc này sẽ gán giá trị cho biến và thực thi hàm.
@sven_9x Bạn để ý là await chỉ dùng được ở trong những hàm async thôi. Nếu chưa rõ về cái này, bạn nên tìm hiểu về promise, async/await trước. Với cái vue-froala-wysiwyg mình vừa thử xem thì thấy nó chỉ cho cài đặt dưới dạng plugin global (tức qua Vue.use(VueFroala)). Bạn thử dùng package gốc froala-editor rồi tự cài đặt nó vào một component, tức không dùng qua plugin sẵn vue-froala-wysiwyg nữa xem?
@tranxuanthang mình chỉ dùng froala ở trang tạo bài và xem chi tiết bài thôi bạn. Cái await bạn bảo thì mình dùng package vue-frola thì để như bạn nó báo lỗi này?
@sven_9x Như mình thấy thì cái froala-editor hiển nhiên là đang chiếm kích thước lớn ở vendor (gần 1/2 cái vendor). Vendor là phần js mà sẽ bị load khi tải ở mọi trang, nên các thư viện có trong vendor sẽ bị tải ngay cả khi route người dùng đang vào có cần thư viện đó hay không. Vậy nên bạn thử bắt đầu bằng cách xử lý cái froala-editor trước xem?
Thường các hướng giải quyết sẽ là thế này:
Bạn tìm những nơi import cái froala-editor ở trong những file entrypoint (ở project vue-cli bình thường thì là ở main.js còn ở project nuxt thì có thể rải rác ở các file trong /app/plugins) và gỡ bỏ nó ở đấy.
Ở những component mà thực sự cần đến froala-editor thì bạn mới import nó vào
Nâng cao hơn chút, bạn có thể áp dụng thêm webpack code splitting, tức thay vì
Mình không thể chỉ ra rõ 100% vì mình không rõ project của bạn phụ thuộc cái froala-editor đến đâu, có cần thiết ở mọi route không. Nên tự bạn cần thử nghiệm sửa đổi xem, và sau mỗi lần sửa thì thử chạy lại webpack-bundle-analyzer xem những gì bạn vừa làm hiệu quả đến đâu.
THẢO LUẬN
Quá tuyệt, nợ nhiều à nha
)
"Mới trả hết nợ từ bài 1 xong, mọi bí ẩn xuất hiện trong đoạn kết của bài 1 đã được mình lột trần hết rồi nhé. Bây giờ lại mọc lên một đống nợ mới về Widget Lifecycle (mấy cái thuật ngữ như deactivate, dispose trong bài 6) và Navigation, Bloc Pattern, Provider...."
Cám ơn bạn, tiếp tục đi nha, viết tuyệt lắm
(love phong cách riêng)
hehhe cảm ơn anh Khang đã chia sẽ
Chuẩn luôn anh ơi mình cũng phải xem môi trường như anh chia sẽ ^^ chứ không dễ toang
Bởi em làm với môi trường là start-up product anh em trong team như người nhà nên cũng dễ nói KHÔNG. Mà em thấy mình cứ say yes hoài riết em thấy chính em bị thụ động trong công việc và không có quyết đoán nữa nên em bật mode phản dame ^^(theo cách tích cực ^^ )
Đôi khi cũng tùy môi trường, tùy văn hóa công ty, tính cách của boss mà từ KHÔNG có thể được hoặc không được sử dụng 😅
Bản thân mình cũng được trải nghiệm qua 2 môi trường làm việc là 1 công ty Đài Loan, và 1 công ty Đức (cả 2 đều ở VN), công ty Đài Loan có ông boss người Đài khá gò bó, kiểm soát, ít lắng nghe góp ý của cấp dưới, trong khi công ty Đức mình làm với nhiều ông boss khá nice, dễ chịu, thậm chí nói chuyện như mấy đứa bạn, cái gì không làm được là nói KHÔNG. Và công ty Đài mình thử việc 2 tháng xong bye luôn, còn công ty Đức thì làm tới giờ cũng đã được 1 khoảng thời gian 😄
Có lý. cảm ơn bác!
a cho e sđt e muốn nhờ a xây 1 ex ạ
Cảm ơn bạn nhiều nhé! Không biết mình có thể xin contact để trao đổi trực tiếp với bạn không?
em bị lỗi báo thế này mong anh giúp đỡ
@tranxuanthang ý bạn import package trong component nào dùng à
@tranxuanthang ừm. ý mình là đang muốn hỏi bạn là trong trường hợp này thì đặt async ở đâu đó
Hi, cảm ơn bài viết của bạn. Mình xin có chút đóng góp để tổng kết lại và giải thích rõ hơn.
Khi thực thi code, trình biên dịch của JavaScript sẽ trải qua 2 quá trình: compilation và execution
1. Compilation
Ở bước này, trình biên dịch sẽ scan qua các function và các biến được khai báo. Khi bắt gặp các từ khóa: var, let, const, class, function, JavaScript sẽ tạo ra một không gian bộ nhớ cho mỗi thành phần được khai báo. Không gian bộ nhớ này là một cấu trúc dữ liệu của JavaScript, được gọi là Letxical Environment.
Hiểu nôm na, lexical environment là nơi chứa các biến và hàm trong quá trình thực thi code, có dạng:
Ví dụ với đoạn code sau:
Khi chạy qua đoạn code trên, lexical environment sẽ:
Cũng chính vì được đưa vào bộ nhớ trong quá trình compile, nên ta có thể truy cập vào những biến này trước khi chúng được khai báo trong code.
Quá trình đưa lên trên cùng của scope và cung cấp cho nó một không gian trong bộ nhớ được gọi là hoisting.
Ở bước này, những biến khai báo với var và function được hoisted và tự động được gán giá trị là undefined trong lexical environment.
Bởi JavaScript chỉ lưu các biến khai báo trong bộ nhớ, không lưu giá trị của biến đó, mà sẽ tự động gán là undefined. Ở giai đoạn execution, khi lệnh chạy đến nơi biến được gán giá trị, giá trị của biến trong lexical context được cập nhật từ udnefined thành giá trị trong code khai báo.
Với biến khai báo với let, const, class được hoisted nhưng vẫn giữ nguyên là uninitialized, không được khởi tạo giá trị.
2. Execution
Đến đây, trình biên dịch sẽ quay trở lại dòng code đầu tiên và chạy từ đầu đến cuối, lúc này sẽ gán giá trị cho biến và thực thi hàm.
Ở đây mình có đọc 2 bài khá hay:
Hoisting in Modern JavaScript — let, const, and var
How Hoisting Works With ‘let’ and ‘const’ in Javascript
Bài viết hay quá! Tks bạn
Cám ơn bro, mình sẽ fix sớm nè
bác viết cuốn quá
Không cập nhật cho phiên bản 1.47.2 nha chủ thớt
@sven_9x Bạn để ý là
awaitchỉ dùng được ở trong những hàmasyncthôi. Nếu chưa rõ về cái này, bạn nên tìm hiểu về promise, async/await trước. Với cáivue-froala-wysiwygmình vừa thử xem thì thấy nó chỉ cho cài đặt dưới dạng plugin global (tức quaVue.use(VueFroala)). Bạn thử dùng package gốcfroala-editorrồi tự cài đặt nó vào một component, tức không dùng qua plugin sẵnvue-froala-wysiwygnữa xem?@tuanbacyen Vâng bạn. Mong website phát triển hơn để nhiều người học hỏi
@tranxuanthang mình chỉ dùng froala ở trang tạo bài và xem chi tiết bài thôi bạn. Cái await bạn bảo thì mình dùng package vue-frola thì để như bạn nó báo lỗi này?
@sven_9x Như mình thấy thì cái froala-editor hiển nhiên là đang chiếm kích thước lớn ở vendor (gần 1/2 cái vendor). Vendor là phần js mà sẽ bị load khi tải ở mọi trang, nên các thư viện có trong vendor sẽ bị tải ngay cả khi route người dùng đang vào có cần thư viện đó hay không. Vậy nên bạn thử bắt đầu bằng cách xử lý cái froala-editor trước xem?
Thường các hướng giải quyết sẽ là thế này:
Nâng cao hơn chút, bạn có thể áp dụng thêm webpack code splitting, tức thay vì
Thì bạn sửa thành
Khi làm vậy, webpack sẽ thực hiện code-splitting, tức bỏ mã nguồn của package vào file riêng chứ không cho cùng vào file script của component hay ở vendor nữa. Có article hướng dẫn thêm về cái này ở https://vueschool.io/articles/vuejs-tutorials/lazy-loading-and-code-splitting-in-vue-js/
Mình không thể chỉ ra rõ 100% vì mình không rõ project của bạn phụ thuộc cái froala-editor đến đâu, có cần thiết ở mọi route không. Nên tự bạn cần thử nghiệm sửa đổi xem, và sau mỗi lần sửa thì thử chạy lại webpack-bundle-analyzer xem những gì bạn vừa làm hiệu quả đến đâu.