Nơi để gọi api của React là componentDidMount và componentDidUpdate. tuy nhiên khi sử dụng componentDidUpdate cần check điều kiện khi setState tránh vòng lặp vô hạn
hi lâu quá ko quay lại topic này. Nếu bind cái nào thì gọi cái đó thì thực sự chưa thấy ý nghĩa của việc áp dụng redis, một thực tế rất hay gặp khi dùng redis là cache data, khi tìm trong redis ko thấy mới tìm trong database gốc, như vậy tình huống này mình phải dùng cả redis và db gốc chứ ko thể dùng 1 trong 2. Tình huống như thế thì mình xử lý ra sao bạn?
Em đã test và nó hoàn toàn chính xác luôn anh Em mới test thử deallocate một cây nhị phân bằng đệ quy theo kiểu này và kết quả rất tốt, tạo vòng lặp trong mã nguồn và không đệ quy:
Em nghĩ là nếu mình lợi dùng đặc điểm tối ưu hóa đệ quy này thì mình có thể viết một hàm đơn giản bằng đệ quy, nhưng hiệu năng và bộ nhớ thì tương tự như vòng lặp được.
Cái history đó bỏ ra khỏi callbacks đi, lúc t viết vào để xem sự biến thiên của acc khi thay đổi 1 vài tham số thôi, lên bài thì t bỏ luôn đi không cho vào nữa mà quên chưa xóa khỏi fit_generator )
THẢO LUẬN
cái này chắc chỉ khi nào nhỡ tay reset --hard thôi nhỉ.
Cảm ơn bạn. Mình sẽ cố gắng. Trong bài tới mình sẽ làm 1 base cơ bản. Nếu bạn cần tài liệu kỹ hơn thì vào khoá học free của google nhé https://www.udacity.com/course/build-native-mobile-apps-with-flutter--ud905
Có 2 điểm:
componentDidMountvàcomponentDidUpdate. tuy nhiên khi sử dụngcomponentDidUpdatecần check điều kiện khisetStatetránh vòng lặp vô hạnBác viết đi E đợi đến sáng mai đọc tiếp
Thank bác đã ủng hộ. Theo bác em có nên bổ sung thêm phần đấy không nhỉ?? Bác cho em xin ý kiến với.
Thank bạn đã chia sẻ. Mà API này ko có authenticate gì à bạn
tks bạn nhiều nhé
hi lâu quá ko quay lại topic này. Nếu bind cái nào thì gọi cái đó thì thực sự chưa thấy ý nghĩa của việc áp dụng redis, một thực tế rất hay gặp khi dùng redis là cache data, khi tìm trong redis ko thấy mới tìm trong database gốc, như vậy tình huống này mình phải dùng cả redis và db gốc chứ ko thể dùng 1 trong 2. Tình huống như thế thì mình xử lý ra sao bạn?
bài viết rất công phu. Cám ơn bạn hén
hay ạ, tks tác giả
thích bài viết của bạn quá. Cách viết vừa dễ hiểu vừa hài hước :>>>>
Cảm ơn bác đã đọc bài, vì lần đầu nên văn phong cũng hơi lủng củng xí, hy vọng là bác dễ hiểu
)
Em đã test và nó hoàn toàn chính xác luôn anh
Em mới test thử deallocate một cây nhị phân bằng đệ quy theo kiểu này và kết quả rất tốt, tạo vòng lặp trong mã nguồn và không đệ quy:
Em nghĩ là nếu mình lợi dùng đặc điểm tối ưu hóa đệ quy này thì mình có thể viết một hàm đơn giản bằng đệ quy, nhưng hiệu năng và bộ nhớ thì tương tự như vòng lặp được.
Hay lắm bác, mỗi tôi có vài đoạn đọc hơi loạn óc
)
Cảm ơn tác giả về bài viết. bài viết quá xuất sắc
Cảm ơn bác. Em đọc xong comment của bác mà cảm giác được thông não. Mấy hôm nay em cũng đang thắc mắc vấn đề này.
Mục đích đọc turtorial là Nuxt.js
cuối cùng biết thêm tý GraphQL
! cảm ơn anh !
Hên thôi, developer kiêm tester xem, chị nghỉ sớm à :v
Cái history đó bỏ ra khỏi callbacks đi, lúc t viết vào để xem sự biến thiên của acc khi thay đổi 1 vài tham số thôi, lên bài thì t bỏ luôn đi không cho vào nữa mà quên chưa xóa khỏi fit_generator
)