Để giải thích hoàn toàn trả lời của mình, dùng mỗi lexical scope thôi là chưa đủ. Mà bạn còn phải dùng cả kiến thức của global scope - local scope nữa. Cái đoạn code tương đương mà bạn đưa ra, chính xác hay không, phải phụ thuộc vào scope. Việc giá trị của a là gì, sẽ được quyết định bởi scope của nó, và các outer scope (parent scope) bao quanh nó. Giờ ta sẽ bắt đầu với từng dòng code một, theo đúng luồng chạy (execute code) của nó, cho bạn dễ hiểu. (Lưu ý là để cho bạn dễ hiểu thôi, mục đích là để giải thích cho bạn câu này, còn nếu giải thích chi tiết và chính xác nhất, thì mình e là làm bạn loạn mất)

1. Ta bắt đầu với var a = 'Ahihi'; Ta có một GLOBAL SCOPE, và khai báo một global variable a. Nó mang giá trị là 'Ahihi'
2. bar(); Ở đây ta bắt đầu gọi hàm bar, 2 hàm bar và foo đều đã được khai báo ở trên.
3. Ta sẽ bắt đầu chạy hàm bar, bắt đầu với dòng code đầu tiên là var a = 3;. Như mình vừa nói ở comment trên, parent scope của bar là global scope, nó ĐÃ KHAI BÁO MỘT global variable rồi, là a có giá trị 'Ahihi'. Vào trong đây, là một LOCAL SCOPE, và ta KHAI BÁO một giá trị a MỚI, đó là một local variable, trùng tên với a đã khai báo trước đó, nhưng mang giá trị là a = 3. Lưu ý là do khác scope, nên từ dòng code này trở đi, ta dùng giá trị của a, tức là ta sẽ động tới local scope, local variable a có gía trị là 3.
4. foo(); call hàm foo.
5. Bắt đầu chạy hàm foo, dòng lệnh đầu tiên là var a = 2; Lại giống như trên, foo tạo ra một LOCAL SCOPE mới, khác với local scope của bar, và parent scope của nó là ... GLOBAL SCOPE, ngoài ra, nó cũng khai báo một local variable MỚI, một biến a mới có giá trị là 2. Kể từ sau dòng lệnh này, BÊN TRONG function foo, bạn dùng giá trị a thì nó sẽ là a mới này (với giá trị là 2)
6. console.log(a); Nó sẽ in ra 2. Đương nhiên rồi, mình vừa giải thích ở bước chạy trên xong.

Giờ ta bỏ cái var a = 2 đi. Chuyện gì xảy ra? Javascript engine sẽ tìm outer scope, để xem có gía trị a đã khai báo nào không mà ta lại dùng ở đây. Và nó sẽ tìm đến parent scope, chính là GLOBAL SCOPE, và tìm được var a = 'Ahihi'.

Ở trên mình có nói, code tương đương mà bạn đưa ra chính xác hay không, phụ thuộc vào scope. Đấy là bởi, nó sẽ là đoạn code tương đương thật sự, nếu như function foo được khai báo bên trong bar, mục tiêu, là để scope của chúng theo đúng thứ tự phân cấp global scope -> bar scope -> foo scope. Code tương đương mà bạn đưa ra, chỉ là luồng chạy của code. Còn javascript hiểu, và đọc giá trị như nào, là việc khác, và việc khác này, phụ thuộc vào Scope.

mình login xong, gọi req.user thì nó không tìm thấy! ko biết lúc login xong user được lưu vào đâu?

@thangtd90 @vinhnguyen Hai anh phân tích đầy đủ và chi tiết quá. Em không thể accept hai câu trả lời được sao?

@quynh001 Cảm ơn anh đã phân tích rất hay và chi tiết. Em không coi đây là điểm yếu vì Laravel vẫn quá "pro" và vì em không giám chắc rằng mình viết được concrete nào "hay ho" hơn concrete mặc định của nó.

Giống như anh nói "trade-offs giữa sự đơn giản và tính đầy đủ ấy" và phân tích.

PHP là một duck typed language thay vì strong typed như trong một số ngôn ngữ khác như Java, .NET. Với các ngôn ngữ dạng strong typed, method signature trong interface thường phải định nghĩa cả kiểu cho parameters và kiểu trả về --> đảm bảo type safety. Trong PHP thì không như vậy thường sẽ ko có kiểu xác định. Do đó với PHP, các phương thức của một object sẽ xác định cách object đó có thể sử dụng thay vì phải phụ thuộc vào sự kế thừa từ một class khác hoặc một thể hiện cụ thể của interface. Tất nhiên PHP vẫn có thể là một strong typed nếu muốn

Em chỉ không thích phong cách code như vậy. Với em, khi đã viết interface và type-hint interface, chỉ nên gọi những phương thức đã được định nghĩa trên interface đó.

rất hay

dạ vâng eloquent xây dựng sẵn sử dụng PDO nên nó theo 1 cấu trúc rồi ạ!, ý em là sử dụng code sql thuần mh có thể check được những cái mà mình nghĩ eloquent chưa đáp ứng được ạ!

Mình nghĩ là bạn nên đưa thêm 1 số thông tin như là bạn sẽ quản lí, lưu trữ những gì, mục đích ra sao thì sẽ dễ hỗ trợ hơn.

Hay

Nếu đã biết có "sơ sót", và "sơ sót" đó là gì, b nên nêu ra trong câu hỏi, để mọi người không mất thời gian để xem tất cả các bảng đó.

good

Eloquent ORM có tính bảo mật cao hơn QueryBuilder trong việc phòng chống SQL Injection.

Đoạn trên em viết ntn cơ mà

mình có thắc mắc là trên trang jwt.io mình dễ dàng decode được chuỗi JWT mà ko cần khóa, nếu có ai đó lấy được chuỗi JWT mà user gửi lên thì hoàn toàn có thể lấy được quyền truy cập. V liêu JWT có an toàn ko nhỉ?

Mình dựa vào bài của bạn để làm đối với model User, sử dụng form request để validate trong controller. Trường hợp mình gửi ảnh đây là để trường name trống thì vẫn hiện thông báo lỗi. Ngay sau khi nhập name và để email trống thì console hiện báo như thế. Mình kiểm tra có báo yêu cầu không để trống email trong trình duyệt. Mong bạn có thể xem hộ mình.

dạ vâng a? em nghĩ dùng db raw thì code bảo mật sẽ chặt chẽ hơn chứ anh?

Tuy nhiên, ở hệ thống cần tính bảo mật cao và cần xử lý data lớn thì nên dùng Query builder.

Câu này mâu thuẫn quá @longnk1301

hay a ei

@longtth Bạn có thể tham khảo bài viết này để tìm hiểu về npm https://viblo.asia/p/manage-packages-dependencies-with-npm-YWOZrDLR5Q0

Hiểu một cách đơn giản thì npm đối với nodejs nó sẽ tương tự composer đối với php ý

Cảm ơn bạn. Mình có chút thiếu sót

chào bạn, vì SPA sử dụng các component, mỗi conponent lại có 1 chức năng vs nhiệm vụ riêng, để thực hiện dc thì chúng có thể cần đến các api để có thể thao tác dữ liệu

Dạ vâng, em cám ơn anh đã chỉ ra lỗi sai ạ!