Vì sao chọn laravel kết hợp với angular
Show {{ variableName }}
Vậy trong một ứng dụng Hybrid (ứng dụng lai) mà chúng ta sử dụng kết hợp cả Laravel và AngularJS thì phải làm thế nào để giải quyết vấn đề đó? Bài viết này sẽ giới thiệu cho bạn vài thủ thuật nho nhỏ để có thể vừa sử dụng Blade Template của Laravel, vừa sử dụng AngularJS cho front-end mà không gặp bất cứ trở ngại nào cả! Để Laravel Blade và AngularJS chịu thỏa thuận với nhauCách 1: Thay đổi cú pháp AngularJSKhi mà cả Laravel Blade và Angular đều tranh giành nhau một syntax thì cách đơn giản nhất để giải quyết mâu thuẫn như 2 bên đó là một bên phải nhường không sử dụng syntax đó nữa và thay thế bằng một cái khác. Như vậy trong giải pháp đầu tiên này thì AngularJS sẽ phải nhường nhịn Laravel Blade một chút :v Và thay đổi cú pháp cho AngularJS thì rất dễ. Bạn có thể đổi cú pháp sử dụng biến trong Angular khi định nghĩa module cho ứng dụng sử dụng Angular $interpolateProvider. var sampleApp = angular.module('sampleApp', [], function($interpolateProvider) { $interpolateProvider.startSymbol('<%'); $interpolateProvider.endSymbol('%>'); });Bây giờ thì Laravel sẽ tiếp tục sử dụng {{ variableName }} còn anh bạn Angular tội nghiệp sẽ phải chuyển sang xài tạm <% variableName %>. Chỉ đơn giản vậy thôi là bạn đã cùng lúc sử dụng cả 2 mà không sợ conflict cú pháp rồi. Bạn cũng không nhất thiết phải dùng <% %> mà có thể thay thế bằng bất cứ ký hiệu nào khác. Cách 2: Thay đổi cú pháp Laravel BladeĐương nhiên thì cách còn lại sẽ là Laravel Blade phải chịu nhượng bộ rồi :D Cách làm như sau: Blade::setContentTags('<%', '%>'); // for variables and all things Blade Blade::setEscapedContentTags('<%%', '%%>'); // for escaped dataCó nhiều nơi để bạn đặt code này vào. Đơn giản nhất thì đặt vào file Routes.php. Chẳng hạn ví dụ như: Route::get('/', function() { Blade::setContentTags('<%', '%>'); Blade::setEscapedContentTags('<%%', '%%>'); return view('home'); });Còn chuyên nghiệp hơn thì bạn có thể vứt đó trong một Service Provider hoặc app/start/global.php. Trở lại với cú pháp bị thay đổi: Lúc này sử dụng biến trong Blade Laravel sẽ trở thành <% $variable %>. Comments code sẽ dạng như này:<%-- $variable --%>. Còn Escaped data sẽ là: <%% $variable %%>. (Giải thích 1 chút luôn đó là Blade Laravel sử dụng cú pháp {{!! variableName !!}} để tránh escape dữ liệu nhằm ngăn chặn XSS attacks -> tác dụng như hàm htmlentities trong PHP). Bonus cách khác: Không sử dụng Laravel Blade nữaThực sự thì vứt bỏ Blade template để thay vào đó sử dụng file một view thông thường như là index.php rất là củ chuối @@ Làm cho Laravel mất đi một phần sức mạnh khủng khiếp của nó :v Nói thì vậy thôi chứ thực ra cách này cũng khá là hay ở chỗ: nó cung cấp một cách tách biệt giữa back-end và front-end. Bởi vì nếu không sử dụng Blade thì bạn để cho Angular điều hành mọi thứ bên front-end như là include và phần định tuyến routing. Lúc này mọi thông tin của view đều do AngularJS quản lý. AngularJS front-end sẽ gửi request về phía Laravel back-end. Laravel trả về các chuỗi JSON response. Và chúng ta hiển thị nó ra cho người dùng. Chẳng hạn chúng ta có file route sau: // app/routes.php Route::get('/', function() { return View::make('index'); // app/views/index.php });Lúc này trong file index.php, bạn có toàn quyền xây dựng một app Angular hoàn chỉnh với controllers, services, và routing. Kết luậnĐó là vài cách mà mình thu lượm được để xử lý confict về cú pháp khi sử dụng chung Laravel Blade Templates với AngularJS. Không biết còn cách nào nữa không :D Nếu bạn mà biết thì chia sẻ cho mình và mọi người xem với! Bài viết được publish bởi Laravel-PHP.comLink bài viết gốc: http://laravel-php.com/laravel-framework/thu-thuat-laravel/su-dung-laravel-blade-voi-angularjs/
{{userFollowed ? 'Following' : 'Follow'}}
Cùng một tác giả
13 0
Trong bài viết này, mình sẽ chia sẻ một vài thủ thuật hay mà bạn có thể làm với Eloquent của Laravel. Như chúng ta đã biết thì Laravel hỗ trợ cho c... Bài viết liên quan
69 8
Tăng sức mạnh cho javascript với lodash Lần này mình sẽ giới thiệu 1 thư viện javascript vô cùng bá đạo có tên là "lodash]1]", có thể nói nó là LI...
13 11
Khi các bạn viết sử dụng AngularJS có thấy thắc mắc về phần làm thế nào để mình viết 1 function mà có thể sử dụng cho toàn bộ app của mình không? V...
Bài viết được sự cho phép của tác giả Lưu Bình An
Thời điểm hiện tại nếu bạn đang làm Frontend thì chắc hẳn đang sử dụng một framework nào đó trong 3 thằng này, Vue, React, và Angular. Nếu trước đây trên cả tá framework, và cả tá ví dụ về làm một ứng dụng web ToDoMVC trên github, thì cuộc chơi giờ đây đã đỡ hơn rất nhiều, khi chúng ta chỉ còn 3 lựa chọn sáng giá. Để viết một ứng dụng phức tạp, chúng ta bắt buộc phải sử dụng framework, vì nếu không có những framework như vậy, chúng ta sẽ tốn không biết bao nhiêu thời gian để đạt được kết quả cuối cùng. Việc làm front end nhiều ngành nghề cho bạn
Chắc các bạn cũng như mình đã quá mệt mỏi với những bài viết so sánh 3 framework trên, ai ngon hơn ai, các bạn cũng nên dừng tìm kiếm câu trả lời cho câu hỏi “Top 10 framework nên xài trong năm 2019”. Tại sao? Vì những bài viết này đa phần sẽ tập trung vào đếm số lượng sao trên Github, số lượng tải về từ NPM, số câu hỏi liên quan trên Stack Overflow. Những con số thống kê vô hồn này chỉ có tác dụng trong những trường hợp cụ thể, như đi quảng bá về mức độ phủ rộng của những framework này. Nếu bạn là dân kỹ thuật và nhìn nhận ở góc độ kỹ thuật, phán xét những framework này ở góc độ kỹ thuật chứ không thể căn cứ trên số lượt view và download
Mục tiêu cuối cùng của các framework đều là để giúp chúng ta viết ứng dụng web hiệu quả nhất có thể, việc cạnh tranh giữa các framework với nhau là ý tưởng tốt hay không? Mỗi framework sẽ có một số lượng người sử dụng nhất định, như React-Angular-Vue hiện tại có khoản hơn nửa triệu developer đang ăn nằm với nó hằng ngày. Không có khái niệm “điểm tốt” và “điểm chưa tốt” cho các framework. Người ta thường hay hỏi mấy câu, framework nào xài ngon nhất. Một dạng câu hỏi bạn nên ngừng làm khó nhau vì không thể nào so sánh như toán học 3 > 2 > 1 Việc thiết kế phần mềm luôn đòi hỏi một sự đánh đổi, đặc biệt là với web, chắc có lẽ vì có quá nhiều thứ người ta muốn làm thông qua web, từ một trang web đơn giản chỉ là HTML tĩnh đến cả một hệ thống phức tạp nhất bạn có thể nghĩ ra, để đáp ứng toàn bộ những nhu cầu khác nhau đó, các framework phải chấp nhận đánh đổi một số thứ, chứ ko thể đáp ứng toàn bộ với một giải pháp toàn diện được
Một trong những ví dụ kinh điển giữa thư viện và framework là React và Angular. React được xem là thư viện trong khi Angular sẽ là framework Là một thư viện, React chỉ muốn tập trung cung cấp mô hình để phát triển UI. Để hình dung dễ hơn, liên tưởng tới các nhà máy sản xuất bún, scope rất cụ thể, tôi sẽ tập trung vào việc sản xuất ra bún, việc các bạn đem bún này về nấu thành món gì là do bạn, lý do tại sao ecosystem của React luôn luôn sôi động, rất nhiều dev đã chế biến thành các món khác nhau, như với món bún chúng ta có bún riêu, canh bún, bún đậu mắm tôm, bún cá châu đốc, bún mắm, vâng vâng. Trong khi đó, Angular với tư cách là một framework thực thụ, nó sẽ tiếp cận vấn đề theo hướng từ trên xuống. Hình dung như mì gói nuôi nhân tài ở Việt Nam, với mọi thứ đóng gói đầy đủ để bạn có một món cứu đói tạm thời, bột nêm, dầu, hành. Angular cung cấp hệ thống form validation, animation,… rất nhiều tính năng khác mà chúng ta rất cần thiết để dựng nên một ứng dụng hoàn chỉnh. Với scope lớn như vậy, mọi tính năng khi thiết kế đã được nghĩ đến làm thế nào để chúng sống chung với nhau một cách mượt mà
Để đơn giản chúng ta so sánh JSX và Templates
function render() { const children = [] for (let i = 0; i < 5; i++) { children.push(h('p', { class: 'text' }, i === 2 ? this.message: "vuilaptrinh.com" )) } return h('div', { id: 'content'}, children) } Chúng ta có thể tạo parent node trước, rồi sau đó nhét thêm các node con, hoặc bất cứ thứ gì bạn có thể nghĩ ra được, javascript rất linh động, có nhiều tình huống đặc biệt chúng ta khó có thể đảm bảo optimize được cho tất cả.
Lorem ipsum Lorem ipsum {{ message }} Lorem ipsum Việc đoán trước được những gì có thể thay đổi, giúp việc cải thiện hiệu năng cũng sẽ dễ tiếp cận hơn
Rất tiếc, Evan You không có thời gian trình bài phần này trong bài thuyết trình của mình. Nếu bạn đang muốn chọn một framework một cách hợp lý, bạn phải hiểu được những gì mà framework đó đang đánh đổi, biết hướng đi của framework đó có khớp với những gì bạn ưu tiên hàng đầu cho dự án mình làm. Bài viết gốc được đăng tải tại Vuilaptrinh Có thể bạn quan tâm: Xem thêm các việc làm Developer hấp dẫn tại TopDev
|