@wiliamfeng đúng rồi e. Form của e nếu có chức năng sửa ( hoặc form của e có cần sử dụng state để làm việc gì đó ). khi ở ngoài bài viết chẳng hạn e bấm vào edit nó mở lại cái form cũ nhưng đồng thời nhập vào những trường cũ để mình edit lại. lúc này đòi hỏi e phải sử dụng state để render lại form đó. Để làm điều này tốt thì những Component View e xài PureComponent để tránh tình trạng render k cần thiết cũng giống như shouldComponentUpdate thôi và props lúc đó e truyền vào nếu k thay đổi thì nó sẽ k bị re-render. A cũng đang bận nên chỉ làm qua 1 chút cho e hiểu vấn đề thôi. E làm dần rồi sẽ hiểu.
E k nên viết hàm kiểu này như bạn ở dưới cmt nhé <input onChange={value => this.handleChange(value)} /> bởi vì khi e change nó luôn create 1 function mới hoàn toàn performance k tốt và sẽ gây ra re-render kể cả khi input kia là 1 PureComponent. e nên viết ví dụ thế này <input onChange={this.handleChange} /> khi đó sẽ là tham chiếu hàm handleChange = value => {}
PS: Trước a cũng xem khá nhiều tut rồi tổng hợp những cách viết hay và đúng đắn nhất thôi. Cách viết code thì nhiều chỗ xử lý theo a thì nên tách ra thành function programming Pure Function dạng function có đầu vào và đầu ra rõ ràng nhưng ở kia thì a cũng viết luôn kiểu bt cho e dễ hiểu, 2 là nên tách rõ Component UI riêng ra, và có thể chia component theo atomic design
Do qui ước của Apple nhé. Apple cũng có thể để mặc định là không capture, trong trường hợp đó thì mình phải check là nil hay không để app không bị crash. Còn nếu để mặc định là capture thì có thể gây ra retain cycle (leak) nếu developer không làm đúng cách. So sánh giữa việc leak và crash thì chắc leak vẫn tốt hơn nên Apple mới để mặc định là capture. Còn function không capture thì function đó phải thuộc class mà nó đang dùng self, và trong trường hợp đó thì truy xuất đến function đó thì phải truy xuất đến object của class đó trước, nếu object nil thì crash, còn nếu không nil thì capture không có ý nghĩa. Capture là để đảm bảo object tồn tại đến thời điểm code đươc thực thi mà. Còn closure thì nó không thuộc một class nào hết.
Cho e hỏi ngu phát:
"No No. Về bản chất Closure không khác gì Function. Closure chỉ là một bản viết tắt của Function":
vậy tại sao trong closure khi có sử dụng self or các biến bên ngoài phải capture lại . Nếu không thì sảy ra retain cycle. Còn func thì không cần phải capture j hết ạ .
vì e không hiểu nên hỏi ngu... ad nhẹ tay thôi nhé:V
con số 20k records và 100k+ bạn lấy ở đâu vậy? Hơn nữa Subquery và JOIN là khác nhau nên việc so sánh còn tùy thuộc vào bài toán cụ thể, với mỗi bài toán sẽ có cách chọn khác nhau. Theo mình việc so sánh như này chỉ đúng với không gian dữ liệu và yêu cầu bài toán nhằm demo của bạn. Chứ nó không hoàn toàn đúng.
e cám ơn anh nhiều ạ. Anh cho e hỏi , câu này : THEO A TRONG TRƯỜNG HỢP FORM KHÔNG THAY ĐỔI THÌ K NÊN DÙNG STATE
ý anh có phải là với Form chỉ có chức năng cho người dùng nhập để gửi thông tin đi ( form 1 chiều ) => thì loại này gọi là FORM KHÔNG THAY ĐỔI .
Còn một loại Form mà ta có thể chỉnh sửa thông tin của một user nào đó (thường thấy trong mấy trang quản trị) => thì gọi là FORM CÓ THAY ĐỔI phải không anh ?
Anh có thể cho e một vài suggest về những trường hợp như nào thì dùng state và khi nào thì không nên dùng không ạ .
PS: Cách viết code của anh đọc rõ ràng và dễ hiểu lắm.
:: [ Ước gì mấy anh trong Công ty e cũng có phong cách viết như vậy thì tốt quá : ))
THẢO LUẬN
bác ơi bác xem part 1 của cháu làm sao cho trọn vẹn thì giúp cháu với
Bao giờ hết lóng ngóng thì hãy viết bài tiếp nhé
@Vo_Tu nếu oke rồi bạn bấm accept câu trả lời giúp mình với. hehe =))
preg_split('/\r\n|[\r\n]/', $data); m dùng hàm này dc rồi nha . thank các bạn
Cảm ơn đã chia sẻ
cảm ơn bạn đã cảm ơn mình! phần 69 sẽ có vào ngày 25/2/2024 ạ (bow), bạn đón chờ nhé
I think 'answers' - not 'aswers'
@wiliamfeng đúng rồi e. Form của e nếu có chức năng sửa ( hoặc form của e có cần sử dụng state để làm việc gì đó ). khi ở ngoài bài viết chẳng hạn e bấm vào edit nó mở lại cái form cũ nhưng đồng thời nhập vào những trường cũ để mình edit lại. lúc này đòi hỏi e phải sử dụng state để render lại form đó. Để làm điều này tốt thì những Component View e xài PureComponent để tránh tình trạng render k cần thiết cũng giống như shouldComponentUpdate thôi và props lúc đó e truyền vào nếu k thay đổi thì nó sẽ k bị re-render. A cũng đang bận nên chỉ làm qua 1 chút cho e hiểu vấn đề thôi. E làm dần rồi sẽ hiểu.
E k nên viết hàm kiểu này như bạn ở dưới cmt nhé <input onChange={value => this.handleChange(value)} /> bởi vì khi e change nó luôn create 1 function mới hoàn toàn performance k tốt và sẽ gây ra re-render kể cả khi input kia là 1 PureComponent. e nên viết ví dụ thế này <input onChange={this.handleChange} /> khi đó sẽ là tham chiếu hàm handleChange = value => {}
PS: Trước a cũng xem khá nhiều tut rồi tổng hợp những cách viết hay và đúng đắn nhất thôi. Cách viết code thì nhiều chỗ xử lý theo a thì nên tách ra thành function programming Pure Function dạng function có đầu vào và đầu ra rõ ràng nhưng ở kia thì a cũng viết luôn kiểu bt cho e dễ hiểu, 2 là nên tách rõ Component UI riêng ra, và có thể chia component theo atomic design
Is this chat API support live chat integration?
cho em hỏi lỗi này sửa sao vậy ạ, em cám ơn
Do qui ước của Apple nhé. Apple cũng có thể để mặc định là không capture, trong trường hợp đó thì mình phải check là nil hay không để app không bị crash. Còn nếu để mặc định là capture thì có thể gây ra retain cycle (leak) nếu developer không làm đúng cách. So sánh giữa việc leak và crash thì chắc leak vẫn tốt hơn nên Apple mới để mặc định là capture. Còn function không capture thì function đó phải thuộc class mà nó đang dùng self, và trong trường hợp đó thì truy xuất đến function đó thì phải truy xuất đến object của class đó trước, nếu object nil thì crash, còn nếu không nil thì capture không có ý nghĩa. Capture là để đảm bảo object tồn tại đến thời điểm code đươc thực thi mà. Còn closure thì nó không thuộc một class nào hết.
Cho e hỏi ngu phát: "No No. Về bản chất Closure không khác gì Function. Closure chỉ là một bản viết tắt của Function": vậy tại sao trong closure khi có sử dụng self or các biến bên ngoài phải capture lại . Nếu không thì sảy ra retain cycle. Còn func thì không cần phải capture j hết ạ . vì e không hiểu nên hỏi ngu... ad nhẹ tay thôi nhé:V
tks @vankhoadesign
)
bài viết hữu ích, tks bạn nhiều
Mình có save bài viết phần 3 vào Drafts vài ngày để cập nhật thêm một số mục, bây giờ thì bài viết đã public rồi bạn nhé !
Mình có save bài viết phần 3 vào Drafts vài ngày để cập nhật thêm một số mục, bây giờ thì bài viết đã public rồi bạn nhé !
con số 20k records và 100k+ bạn lấy ở đâu vậy? Hơn nữa Subquery và JOIN là khác nhau nên việc so sánh còn tùy thuộc vào bài toán cụ thể, với mỗi bài toán sẽ có cách chọn khác nhau. Theo mình việc so sánh như này chỉ đúng với không gian dữ liệu và yêu cầu bài toán nhằm demo của bạn. Chứ nó không hoàn toàn đúng.
nội dung hay và dễ hiểu, like!
Thanks Dao.
e cám ơn anh nhiều ạ. Anh cho e hỏi , câu này :
THEO A TRONG TRƯỜNG HỢP FORM KHÔNG THAY ĐỔI THÌ K NÊN DÙNG STATEý anh có phải là với
Formchỉ có chức năng cho người dùng nhập để gửi thông tin đi ( form 1 chiều ) => thì loại này gọi làFORM KHÔNG THAY ĐỔI. Còn một loạiFormmà ta có thể chỉnh sửa thông tin của một user nào đó (thường thấy trong mấy trang quản trị) => thì gọi làFORM CÓ THAY ĐỔIphải không anh ?Anh có thể cho e một vài
suggestvề những trường hợp như nào thì dùngstatevà khi nào thì không nên dùng không ạ .PS: Cách viết code của anh đọc rõ ràng và dễ hiểu lắm. :: [ Ước gì mấy anh trong Công ty e cũng có phong cách viết như vậy thì tốt quá : ))