Ra là bạn muốn đi step by step =))

Bài viết rất hay. Cảm ơn bạn nhiều!

@HuyDQ amazing!! it worked, bạn giải thích lại cơ chế giùm mình với, có phải như bạn đã nói ở trên ko? Mình mới vào nghề nên còn hổng nhiều thứ quá

Trong phần render bạn thử thêm như mình ở trên xem

{this.props.fetched && this.cityLine()}

Cám ơn bạn Huy, Mình có khai 1 biến tương tự trong reducer như đoạn code bên dưới. Khi mình console.log('city', this.props) thì có trả về kết quả, giá trị fetched từ false thành true, chứng tỏ đã có giá trị trên store. Nhưng khi mình map() để lấy giá trị từ store xuống thì báo lỗi ko nhận ra cityList. Nếu mình làm thuần trong reactjs thì chạy tốt... nên làm mình bối rối, bạn có ví dụ nào giống mình thì share với, cám ơn bạn nha

P/s: sorry mọi người vì đoạn code dưới mình ctr-alt-c ko được

import {CREATE_CITIES, FETCH_CITIES, UPDATE_CITIES, DELETE_CITIES, } from '../actions/actionTypes'

const initialState = { fetched: false, create: false, delete: false, cities: [], city: { name: '', image:'' }, error: null };

const cityReducer = (state=initialState, action) =>{ switch (action.type){ case 'FETCH_CITIES':{ return {...state, cities: action.payload, fetched: true, create: false, delete: false, error: null }
}
case 'CREATE_CITIES': { return {...state, fetched: false, create: true, delete: false, error: null, city: { name: '', image:'' } }
} case 'UPDATE_CITIES':{ return {...state, cities: [...state.cities, action.payload], fetched: true, create: false, delete: false, error: null }
} case 'DELETE_CITIES': { const _id = action.payload.data._id; return {...state, fetched: false, create: true, delete: false, error: null, cities: state.cities.filter(item => item._id !== _id) }
}case 'FETCH_CITIES_ERR':{ return {...state, fetched: false, create: false, delete: false, error: action.payload, }
} default: return state; } } export default cityReducer;

Cảm ơn bạn, mình cũng học được nhiều điều từ bài lab này

nên tập trung vào golang, go func, variable types, goroutine hơn, bài này dính cả docker nên tách thành bài khác thì hợp lý hơn.

Cái này là đối với app req-res tức thời Hóng phần tiếp theo với các app đòi hỏi xử lý ở server :v Mạo muội đoán già đoán non là sẽ timing thời gian ready và terminate của app :-?

Con số ở trên thực chất là mình chỉ lấy mẫu trong 1 test. Còn với quá trình này thì mình có thử khá nhiều lần để check xem nó có lỗi không, vì có nhiều yếu tố ảnh hưởng tới quá trình test như network các thứ nữa

Max ghê

Cảm ơn bạn đã đọc bài viết của mình =)), đúng là mình đang viết ko đúng đấy, chủ yếu đọạn code đấy là để tránh lặp lại code của mình thôi , mình viết như thế xem có ai đọc bài của mình và hiểu đúng vấn đề để comment lên như bạn thôi , mà chờ mãi mới có người đọc bài có tâm

phần event handle, bạn viết "Khi code kiểu này nếu như 1 thẻ li được bọc ở bên ngoài thẻ ul (thẻ này cũng add 1 event) thẻ ul lại được bọc bằng 1 thẻ div (thẻ này cũng có event) như thế khi click vào thẻ li thì mình cũng gọi luôn cả 3 sự kiện kia nữa đúng ko, quả là không đáng tý nào". Nhưng sau khi thay đổi code thì click li nó vẫn gọi 3 sự kiện nếu theo giả thuyết kia thôi mà.

đang băn khoăn cách test của bạn. Theo như logic thì m nghĩ sau khi đưa Readiness check và Prestop hook vào thì chắc chắn thời gian nó sẽ lâu hơn. nhưng mà ngược lại theo kết quả test nó lại nhanh hơn. Không biết bạn test đã đúng hay chưa?

Trước khi cải thiện All done 3966 calls (plus 4 warmup) 60.572 ms avg, 66.0 qps

Sai khi cải thiện: All done 4833 calls (plus 4 warmup) 49.618 ms avg, 80.5 qps

(ok) bạn, mình sẽ cố gắng bớt chữ trong bài viết tới

(ok) bạn, mình sẽ cố gắng bớt chữ trong bài viết tới

Bài lab rất hay. Rất phù hợp cho các bạn chuyên ngành an toàn thông tin.

có thể e chưa khai báo '$lang' rồi

Bắt đầu với Golang mà giới thiệu nhiều thứ quá )) lan man vc

Bạn thử tham khảo cái lib này xem có được ko https://kutlugsahin.github.io/smooth-dnd-demo/

đúng tiêu điểm e cần đọc đây rồi, thank đại ca :v