@tuannt81 vâng ạ ^^

anh ơi, anh cho em xin data test sentiment của vlsp2016 được không ạ

bai viết hữu ích, cám ơn bạn nhiều

@hao3004 nếu em muốn kiểm tra click thì cũng kiểm tra trong đó nhé, this.props.onClick và nextProps.onClick cũng tương tự

Cá nhân từng làm ở cả 2 môi trường mình thấy có vẻ như bạn quy chụp mọi thứ, và mình muốn hỏi bạn đã từng làm việc ở bao nhiêu môi trường product =))

Làm Outsourcing là làm cho thằng khác, không phải của mình

Thế theo bạn làm cho product là làm của mình à, sorry bạn là bạn thực chất vẫn là thằng làm thuê, bạn có cổ phần trong công ty không? sản phẩm kinh doanh không có lãi có ảnh hưởng tới kinh tế của bạn không ? Công ty làm ăn thua lỗ không trả lương cho bạn thì bạn có kiên nhẫn ở lại "xây dựng" sản phẩm được coi là "của mình". Cho nên ý thức sản phẩm thuộc về ai phụ thuộc nhiều vào con người hơn môi trường.

Làm Outsourcing bị thiếu tư duy làm sản phẩm. Vì sản phẩm là của người khác, nghiệp vụ là của người khác nên anh em cứ Code như một cái máy, chỉ đâu code đấy.

Thế bạn sang làm product thì được làm theo ý của dev à? Mình biết bên product có 1 đội BA và trong mỗi sprint BA là người đưa ra các feature cho đội dev làm. Vậy ở đây có phải làm theo nghiệp vụ của người khác. Hay giờ CEO của công ty bắt làm cách A, bạn có làm theo cách B được không

Làm Outsoucing thích lương cao và làm quản lý.

Lương cao ai chẳng thích. Còn về định hướng thì mình thấy team size bên product thường nhỏ 10-20 người, biến động nhân sự ít nên chuyện định hướng làm quản lí dường như không có. Do lúc nào cũng có những người lão làng k chịu rời đi thì bạn đừng mong có cơ hội leo cao. Còn outsourcing thì thường công ty có đông nhân sự, nhu cầu về người quản lí cũng có nên mình thấy định hướng làm quản lí chẳng có gì là sai.

Làm Outsourcing khả năng sáng tạo kém, tư duy bảo thủ.

Cái tư duy mình nghĩ về mindset nhiều hơi môi trường, mình đã từng gặp leader product sẵn sàng cãi nhau tay đôi với BA vì không muốn sửa 1 màn hình giao diện đẹp vì lí do ... tốn thời gian.

Làm Outsourcing lười học.

Sao mình lại thấy ngược lại nhỉ, product giờ đa số phát triển theo mô hình Agile. Tức là công việc xoay vòng liên tục từng tuần, mình cảm giác 8 tiếng đến chỉ ngồi làm task. Không thấy thời gian đâu ra mà học. Còn outsoucing thì thời gian chờ dự án, anh em có thể tự học những cái mình thích. Hoặc sếp đưa ra vài keyword cho học cũng chẳng sao, vì họ là người đi trước, họ nghĩ nó là cần thiết.

Làm Outsourcing ảo tưởng sức mạnh.

Mình thấy người viết bài cũng đang ảo tưởng sức mạnh về mấy bạn dev product đấy =))

Chốt lại thì mình thấy yếu tố môi trường nó cũng là chất xúc tác chứ nó không quyết định năng lực của một kĩ sư. Còn giờ ra ngoài mà công ty nào chê nhân sự outsourcing mà chưa phỏng vấn thì mình cũng không đánh giá quá cao về năng lực tuyển dụng của họ.

@tuannt81 dạ vâng, cần kiểm tra color props nhưng em nhầm là kiểm tra click ạ 🤣
Em cảm ơn anh (bow)

@hao3004 nếu bạn dùng class component thì có thể dùng shouldComponentUpdate() nhé

Trường hợp dùng thì cũng tương tự như trên thoai

class A extends Component {

  shouldComponentUpdate(nextProps, nextState, nextContext) {
    return this.props.color !== nextProps.color
  }

  render() {
    console.log("render A")
    return <div>
      <p style={{color: this.props.color}}>A</p>
      <B />
    </div>
  }
}

@hao3004 bạn chú ý chỗ kiểm tra bên trong shouldComponentUpdate này nó ngược với hàm areEqual nhé

Cảm ơn bạn đã đọc bài viết

ủa sao mới tới đó mà đã hết bài r bạn?

Cho mình hỏi sao không có phần 3 ạ =))

Vấn đề bạn đang hỏi là gì ạ? Như thế này hơi chung chung mn không thể giúp bạn được!!!

ok bae

Giờ m k còn nhớ github đó m để ơ đâu nữa Trong source mình luôn cố để full source rồi bạn nhé

giả sử query có 1 mảng 1 phần tử

@huukimit Thử case này chưa? MẢNG 1 PHẦN TỬ

(ahihi) cảm ơn em nhá (dangyeu)

Những kiến thức khá thú vị

ôi anh mình giỏi quá=))

tips thì nhiều lắm bạn ơi, hãy lai, sắp cờ rai những bài viết sau của mình nhé.

Trong nhiều trường hợp thì không nên sử dụng Emoji trong email hay những nội dung quan trọng nhé !! Trích lời của UM

về phần cấu trúc frontend nằm cùng với backend thì ko có khái niệm "được cho phép" hay ko đc e à . Đây là tuỳ vào framework hoặc project do ta tự chọn.

Ở đây a dùng Laravel (framework PHP) thì họ (người tạo ra framework) cấu trúc chạy frontend chung với backend luôn. Chạy backend và frontend chung có khá nhiều điểm lợi, nhưng bù lại thì code của project sẽ to ra.

Về cách làm việc thì nói chung là cũng không khác khi e tách frontend và backend. Bài này a muốn hướng dẫn nhiều về Docker hơn, nên nếu e muốn đào sâu hơn về project (frontend + backend) thì check thêm docs của Laravel nhé

Dạ anh cho em hỏi là trong phần này thì front end là vuejs và back end là laravel nằm trong cùng 1 thư mục. Điều này được cho phép hay là mình phải tùy chỉnh nó vậy anh? Vì em chưa từng học laravel + vuejs nên em không biết cách làm việc của 2 thành phần này thế nào ạ?