Gatsby Js là gì?

Gastby JS là nền tảng dùng để xây dựng website và web app để hoạt động ở hiệu suất rất cao. Gatsby JS sử dụng React và Graphql là thành phần chính, trái tim của nền tảng. GatsbyJS được sử dụng khá rộng rãi và trở thành tên tuổi khá được chú ý hơn sau khi gọi vốn được 15 triệu đô ở vòng gọi vốn Series A.

Tương lai của web chính là mobile dựa trên Progressive Web App (PWA), vì vậy với sự phát triển của Javascript tạo ra xu hướng JAM stack (Javascript + API + Mockup), giúp cho việc phát triển website ngày càng thú vị và đơn giản với Gatsby Js.

Web tĩnh và sự khác biệt của GatsbyJs

Tại sao lại cần web tĩnh?

Trong bài giới thiệu Kỹ thuật lập trình website tĩnh thì mình có nói cũng khá đầy đủ rồi. Web tĩnh thật ra không hề xa lạ., về cơ bản bất kỳ 1 website “động” nào cũng đều có cơ chế cache. Website có lượng truy cập càng lớn thì càng phải có cache. Vậy cache ở đây được xem như là dữ liệu tĩnh tồn tại trên 1 khoảng đơn vị thời gian nhất định.

Cache thì có nhiều cấp độ, từ cơ sở dữ liệu, đến object cache, fragment cache (cache từng phần trên 1 trang), và cấp cuối thường là HTML cache (bỏ qua các lớp cache ở cấp độ hardware). Thì ở cấp cuối “HTML cache” cũng chính là thứ mà sản phẩm cuối cùng của Gatsby JS tạo ra. Và thông thường, thì thư mục cache này được đồng bộ ra các máy chủ khác nhau, giúp tốc độ truy cập nhanh vì bỏ qua hàng ngàn dòng code xử lý và thời gian thao tác I/O.

Một điều khá khôi hài nằm ở chỗ này, chúng ta thường thuê những máy chủ khá khủng để chạy các website mà phần lớn tài nguyên trong đó không phục vụ nhu cầu cuối cùng. Không những lãng phí mà hiệu quả về tốc độ cũng không được cao.

Sự khác biệt của Gatsby JS

Khác biệt so với web động có cache

Web động tạo cache ở thời điểm run-time, điều này đòi hỏi luôn luôn phải duy trì 1 hệ thống máy chủ có đầy đủ cơ sở dữ liệu, các công cụ hỗ trợ đi kèm. Trong khi Gatsby Js build xong ra tập tin tĩnh, thì máy chủ dùng để build có thể tắt đi, có thể giúp tiết kiệm chi phí rất tốt.

Khác biệt so với web tĩnh thuần túy

Web tĩnh thuần túy sẽ tạo ra tập tin HTML hoàn toàn cho mọi liên kết. Vì vậy nếu người dùng truy cập liên kết A, sau đó nhấn vào liên kết B, sẽ tải toàn bộ tập tin HTML của trang B. Gatsby cũng tạo ra HTML cho toàn bộ liên kết, tuy nhiên đồng thời tạo thêm tâp tin JSON nội dung của tất cả các trang. Sự khác biệt là với Gatsby, khi truy cập vào trang A và nhấn vào liên kết B, sẽ tải tập tin JSON nội dung mà trang B hiển thị. Và thông thường tập tin JSON và các tập tin JS liên quan này chỉ chiếm 30% so với 1 trang html hoàn chỉnh.

Ví dụ ở website reactjs.org, từ trang chủ đến trang Docs (Getting Started), thì các tài nguyên cần tải chiếm 12KB, trong khi đó nếu truy cập trực tiếp thì trang HTML này tải cần ~24KB (không tính các request phụ trợ khác), xét tương đối thì tối ưu được 50%.

Ưu và khuyết điểm của Gatsby Js

Hãy cùng Fullstack Station tìm hiểu về ưu và khuyết điểm của Gatsby Js là gì nhé.

Ưu điểm

Triển khai với chi phí thấp và dễ dàng

Việc tách biệt cơ sở dữ liệu và chỉ phục vụ hoàn toàn trên dữ liệu tĩnh giúp việc triển khai rất dễ dàng, có thể dùng bất kỳ máy chủ nào với chi phí rất thấp. Ví dụ với Amazon S3: 0.005$/1000 requests (PUT, COPY, POST, LIST) thì với website có 100k pages, thì mất 100*2 *0.005 = 1$ cho việc quản lý cập nhật mỗi ngày. Với 1 site có 100k pages thì chi phí cập nhật như vậy là quá rẻ. (2 ở đây được xem là mỗi trang có 2 tập tin HTML+JSON). Xem thêm Escalade Sports: From $5000 to $5/month in Hosting With Gatsby.

Tốc độ cao:

Là một framework để tạo web tĩnh (tương tự như Jekyll), tối ưu tốc độ và bảo mật cho website. Việc chuyển qua lại giữa các trang trong website cũng rất nhanh do tất cả các style, html và javascript sẽ được tải trong lần tải đầu tiên, khi người dùng ấn vào một bài viết trong trang web của bạn, nội dung mới sẽ được tải về dưới dạng JSON và hiển thị lên, không cần tải lại toàn bộ trang. Việc cấu hình các plugin cho phép tối ưu việc tải ảnh (progressive) và preload (tải trước nội dung của các liên kết người dùng có thể ghé qua) sẽ cho trang web có tốc độ cực cao.

Tối ưu SEO

Gatsby JS thân thiện với các công cụ tìm kiếm vì các truy cập lần đầu đối với mọi trang đều là HTML. Gatsby kết hợp cả 2 cơ chế Client rendering và Server rendering nên luôn đảm bảo SEO tốt.

Hỗ trợ Progressive Web Apps:

Thêm website của bạn vào màn hình home của di động và người dùng có thể dùng nó như một app di động luôn.

An toàn

Với toàn bộ tập tin là html và json, toàn bộ hệ thống sẽ an toàn trước các kiểu tấn công. Hơn nữa, sẽ không còn phải lo lắng gây ảnh hưởng người dùng khi cập nhật hệ thống (framework, app, database…).

Đơn giản

Thực sự bắt đầu Gatsby rất đơn giản dành cho ai đã quen với React, Graphql, Markdown… Gatsby thừa hưởng các tính năng hay của React và Graphql.

Nhược điểm

• Gatsby.js chuyên dùng để tạo website tĩnh, nên việc triển khai hệ thống bình luận và tìm kiếm thường phải dựa vào các dịch vụ bên thứ 3 như: Disqus, Algolia, Facebook…Mặc dù bạn hoàn toàn có thể tự phát triển dạng hybrid để tạo web động trong Gatsby Js.
• Hơi khó khăn để sử dụng đối với những người chưa quen React, Graphql
• Thời gian build lâu: với cái starter default mà đã build gần 2s, với những site lớn khoảng 100k ~ 1M trang, thì thời gian build tầm 10~30 phút, chưa kể thời gian triển khai và đồng bộ hoàn toàn đến tất cả các edge (các node trong CDN). Tuy nhiên vẫn có những cách khắc phục ở mục Fullstack Station Tips
• Tốn kém để chuyển đổi hệ thống hiện tại: để chuyển hệ thống sang sử dụng Gatsby JS sẽ tốn chi phí không hề nhỏ. Chúng ta cần phải cân nhắc kỹ lưỡng giữa lợi ích mà web tĩnh mang lại trong tương lai với chi phí chuyển đổi.
• Với wordpress, hay 1 nguồn nội dung khác, thì phần “hình ảnh trong bài viết” có thể không tận dụng được khả năng xử lý hình ảnh của Gatsby Js.
• Mất đi một số tính năng hay của các nền tảng khác cung cấp. Ví dụ với WordPress mình kết hợp với OneSignal, khi mỗi bài viết được xuất bản thì sẽ tự động gởi thông báo đến tất cả các người dùng đang theo dõi (subscribers).
• Triển khai cho người dùng bình thường còn phức tạp. Thật khó để sử dụng chức năng hẹn giờ xuất bản, hoặc chỉ là những cập nhật nho nhỏ.

Gatsby JS phù hợp với dự án web nào?

Dựa trên những ưu điểm của Gatsby, FS nhận thấy phù hợp với các dự án web ít thay đổi về nội dung, số lượng trang không quá lớn, tầm 10000 trang đổ lại. Các trang về tin tức có rủi ro khi cần xoá bài khẩn cấp, vì thời gian build, cache, deploy cũng không thể nhanh được. Tuy nhiên nếu có các phương án chặn link khẩn cấp từ lớp Network thì về cơ bản không vấn đề gì.

Phương thức hoạt động

Khi chạy ở mode “develop” thì bản chất Gatsby Js là một create-react-app (CRA), thừa hưởng toàn bộ tính năng của CRA như HOT RELOAD.

Sau khi build ra, thì bao gồm các file json và html, css, js, image…Chúng ta chỉ cần đưa thư mục chứa các tập tin này lên máy chủ là xong.

Một số CMS tương thích tốt với Gatsby

Đa phần các CMS đều có thể hoạt động với Gatsby thông qua API (Restful hoặc Graphql), do vậy việc sử dụng CMS nào phụ thuộc vào việc bạn sử dụng quen CMS nào nhất. Hoặc CMS nào tiện lợi nhất, hoặc là CMS bất kỳ tự phát triển. Miễn sao có API lấy nội dung là được.

Tuy nhiên, các CMS sau thì khá nổi tiếng và có plugin để lấy nội dung (từ API chuyển về dữ liệu graphql trong Gatsby)

• Netlify CMS 
• Buttercms
• Ghost
• Contentful
• WordPress
• Strapi
• Prismic

Trước khi bạn muốn sử dụng gatsby, hãy kiểm tra xem đã có plugin hỗ trợ chưa, ví dụ tìm kiếm với từ khóa “wordpress” https://www.gatsbyjs.org/plugins/?=wordpress

Fullstack Station Tips

• Gatsby tạo cho website hoạt động tốt và bền vững

The post Gatsby Js là gì appeared first on Fullstack Station.

Angular.js thì sao?

Mình không muốn nhắc tới Angular.js nữa, mình nghĩ Angular.js sẽ bái bai chúng ta trong thời gian không lâu nữa. Cuộc đua đã ngã mũ với Angular.js khi hiện tại chỉ đạt gần 50k sao ở Github và đà tăng trưởng về sao cũng chậm lại khá rõ khi cách đây 2 năm đã ở ngưỡng ~35k.

Thử nhìn đoạn mã sau trong “Getting Started” của Angular 8:

<h2>Products</h2>
 <div *ngfor="let product of products">
  <h3>
    <a [title]="product.name + ' details'">
      {{ product.name }}
    </a>
  </h3>
  <p *ngif="product.description">
    Description: {{ product.description }}
  </p>
   <button (click)="share()">
    Share
  </button>
</div>

Đoạn mã này trình bày 5 ý:

• *ngFor
• *ngIf
• Interpolation {{ }}
• Property binding [ ]
• Event binding ( )

Vừa thay đổi cấu trúc nhận event lại còn thuộc tính của thẻ html, lại còn thêm *. Nói thiệt ai chê mình ngu thì mình chịu, chứ từ lúc làm cái dự án với Angular 1 là mình tởn, tới tận giờ phiên bản 8 vẫn còn thấy ngu :(.

So… when was the last time you used #Angular (any version) to start a NEW project?

— Scotch.io (@scotch_io) April 23, 2019

Với kết quả thăm dò của Scotch.io cho câu hỏi “Lần cuối bạn sử dụng Angular (bất kể phiên bản nào) để tạo 1 dự án mới là khi nào?”, hơn 50% trả lời là hơn 1 năm. Mình nghĩ kết quả này đã quá rõ ràng cho kết cục của Angular.

Vậy nhé, nếu sếp bắt làm dự án với Angular thì thành thật chia buồn.

So sánh Vue.js và React.js qua các con số thống kê

Tần suất phát hành phiên bản mới

Với sự hình thành đã lâu không khó để hiểu React.js vượt trội về số lượng commit và pull request. Tuy nhiên cũng nhìn nhận 1 điều là số lần release của Vue.js lại gấp đôi React.js, có thể kết luận về tính stable của dự án thì React.js hơn hẳn. Vì sao? Vì commit code ít nhưng lại release nhiều, mình nghi ngờ về chất lượng release, không tin à, nhìn hình sau nhé:

Trong 1 ngày mà release xong fix bug muối mặt luôn, còn React.js thì bản nào release mình thấy rất an tâm mà cập nhật ngay, còn với Vue.js thì chắc là không.

Winner: React.js

Mức độ thịnh hành

Mục này mình xét các thông số: được sử dụng, fork, và số người đóng góp.

React.js rõ ràng được sử dụng rộng rãi hơn khi được sử dụng ở 2 triệu dự án, so với khoảng gần 900k với Vue.js. Mặc dù vậy, cũng có thể do React.js được ra đời sớm nên được sử dụng nhiều hơn? Còn Vue.js ra đời sau nhưng đã đạt 900k thì quả thực rất ấn tượng.

Fork về có kết quả tương đương, React.js nhỉnh hơn 1 chút với 24k, so với 20k của Vue.js, nhưng số người đóng góp lại khá chênh lệch 1297/276 ~ gấp 5 lần. Có thể suy ra fork vue.js về cho vui :D. Tính tương quan về số lượng pull requests/forks và người đóng góp/forks thì lần lượt React.js đạt 33% và 5%, còn Vue.js đạt 7.5% và1.4%. Đây là tỉ lệ khá chênh lệch, và có thể nói rằng người dùng React.js giỏi hơn (?), có khả năng đóng góp, chịu khó đóng góp hơn người dùng Vue.js.

Kết quả về tỉ lệ pull requests/forks và contributes/forks này, mình không cho là vì React.js có trước Vue.js có sau, vì rõ ràng số lượng forks của Vue.js rất cao. Ý nghĩa về việc forks của mỗi người thì cũng khó biết, tuy nhiên chỉ gói gọn trong 2 mục đích:

• Lưu giữ làm của riêng (sợ mất, mình cũng có khi có suy nghĩ đó :D)
• Đóng góp cho cộng đồng, kết quả này cho thấy cộng đồng React.js phát triển hơn, có khả năng đóng góp và phát triển nền tảng hơn hẳn Vue.js.

Winner: React.js

So sánh Vue.js và React.js trong lĩnh vực phát triển ứng dụng di động, native

Đối thủ lớn Flutter

Việc được sử dụng rộng rãi hơn cũng do React Native sử dụng React, còn Vue.js thì không có nền tảng di động chính thức mà chỉ có đối tác là Weex hoặc Vue-Native, sự tồn tại và phát triển của Weex sẽ gặp thách thức khá lớn khi Flutter đã chứng tỏ được khả năng và sự thống trị của React Native.

So sánh Vue.js và React.js thì không thể bỏ qua Flutter. Mình thấy Flutter rất tuyệt (xem thêm Flutter là gì), tuy rằng theo mình sẽ rất khó ăn hiếp được Reat Native, nhưng với Weex thì khả năng cạnh tranh được với Flutter là cực khó. Bằng chứng là số sao của Flutter gấp 5 lần Weex, mặc dù Flutter cũng mới ra mắt cách đây không lâu.

Hơn nữa, Flutter là nền tảng được hỗ trợ chính thức bởi Google (Google I/O), và hỗ trợ đa nền tảng. Có thể dùng Flutter để tạo Web, Mobile, Desktop và cả hệ thống nhúng. Thực sự là Flutter rất khủng, điểm khó của Flutter là dùng ngôn ngữ Dart.

Một điều cần lưu tâm là động thái Alibaba chuyển giao Weex cho tổ chức Apache, và đồng thời tạo ra ứng dụng “Xianyu” bằng Flutter, với 50M download (showcase của Flutter ngay trên trang chủ của Flutter). Không chắc là Alibaba chuyển qua sử dụng Flutter hẳn luôn hay không, nhưng rõ ràng họ không mặn mà gì với Weex cả.

Weex hoàn toàn bị lép vế so với Flutter!

React Native Windows

React Native có thể được sử dụng cho việc phát triển ứng dụng trên Windows với React Native Windows được hỗ trợ chính thức bởi Microsoft. Bạn có thể sử dụng React Native Windows để phát triển cho toàn bộ hệ sinh thái của Microsoft: desktop, tablet, xbox. Còn gì tuyệt vời hơn?

Ngoài ra, Microsoft còn có nền tảng Xamarin cũng mạnh mẽ không kém. Việc hỗ trợ React Native cho Windows trong khi đã có Xamarin là bước đi thông minh của Microsoft, vì hiện tại Javascript đang rất nóng và có nhiều lập trình viên theo đuổi hơn bao giờ hết.

Nền tảng di động của Vue.js bị phân tán

Không hỗ trợ chính thức nền tảng phát triển ứng dụng di động mà còn có sự phân mảnh. Bản thân trong chính Weex cũng hỗ trợ cả Vue.js và Rax (React.js), nghĩa rằng Vue.js được hỗ trợ để trong Weex, không có Vue.js thì Weex vẫn sống. Đây thực sự là điều đáng lưu ý, khi một nền tảng bị phân mảnh thì rõ ràng cộng đồng phát triển không mạnh, không tập trung.

Ngoài Weex thì còn có Vue-Native, được tạo ra bởi nhóm GeekyAnts, nhóm đã tạo ra NativeBase cho React Native cũng khá nổi tiếng. Nhưng có lẽ Vue-Native cũng còn khá nhỏ, để có thể tạo nên đột phá, hay làm được gì. Và bản chất Vue-Native là dựa trên React Native và dùng Vue.js để viết codekết nối. Theo mình đây là cách cực kỳ nguy hiểm, không nên đi theo. Vì trong khi phát triển chắc chắn sẽ có vấn đề với React Native mà dựa trên đó là React, như vậy bạn có thể sẽ phải học cả 3 thứ: Vue, React, React Native.

NativeScript cũng là hình thái lai, khi dùng được cả Vue.js và Angular.js, cũng không phải bắt buộc dùng Vue.js nên nhận định cũng như Weex, không có Vue.js thì NativeScript vẫn sống.

Hơn nữa, như đã phân tích ở trên về tính stable của Vue.js, cái gốc đã không thực sự ngon, thì các nền tảng cho di động hay native cũng khó có thể có cuộc cách mạng được. Với lý do phân mảnh thì việc củng cố và phát triển nền tảng di động với Vue.js không khả quan cho lắm.

Rủi ro từ quan hệ Mỹ – Trung

Không thể không nói điều này, vì các đóng góp cho Vue.js cũng có phần lớn đến từ Alibaba với Weex do Alibaba tạo ra. Và các sản phẩm dùng Weex đa phần là của Trung Quốc, xem Ai đang sử dụng Weex.

Mặc dù Weex đã chuyển giao sang cho tổ chức Apache, tuy nhiên chắc chắn sự đóng góp vào Weex sẽ đến phần lớn từ Trung Quốc, và tất nhiên cũng sẽ được sử dụng phần lớn từ Trung Quốc. Với quan hệ của Mỹ Trung xấu đi, các vấn đề liên quan đến công nghệ, học thuật của Trung Quốc đều bị hạn chế. Nó có thể là việc sử dụng Weex trên thế giới, cũng như sự đóng góp của cộng đồng trên toàn thế giới vào Weex có khả năng bị ảnh hưởng. Flutter cũng được lập trình viên Trung Quốc quan tâm và đóng góp, ví dụ là https://github.com/alibaba/flutter-go. Tuy nhiên, vị thế của Flutter khác hoàn toàn do Google chống lưng.

So sánh Vue.js và React.js trong mảng phát triển ứng dụng di động và native có kết quả quá khập khiễng khi kết quả nghiên hoàn toàn về React.js.

Winner: React.js

Khi nào nên sử dụng Vue.js

Nếu theo phân tích ở trên thì phần thắng nghiên hẳn về React.js với tỉ số 3-0. Tất nhiên, đây là góc nhìn có thể khác với nhiều người khác, nhưng mình nghĩ các con số thống kê không hề nói dối. Tuy nhiên, Vue.js có những điểm mạnh riêng mà mình cũng rất thích. Hãy cùng phân tích xem Vue.js phù hợp như thế nào nhé.

Như mình đã phân tích khá kỹ ở phần di động, native ở trên bạn không nên sử dụng Vue.js cho mục đích phát triển ứng dụng di động. Do vậy nhiệm vụ còn lại khả dĩ cho Vue.js là mảng web mà thôi.

Khi so sánh Vue.js và React.js, dễ dàng nhận ra điểm mạnh của Vue.js hơn React.js là có thể sử dụng template và cả JSX. JSX có một điểm yếu khá lớn là phải biết javascript, rồi cách build khá phức tạp. Như vậy đã hạn chế 1 lượng lớn frontend developer, nhất là các bạn chỉ chuyên cắt html từ photoshop và làm template. Team mình từng thất bại 1 dự án sử dụng React.js vì vấn đề này. Từ design, cắt ra html, rồi import vào react là một quá trình phức tạp, tình huống là bạn code react.js không giỏi trong việc cắt html, hoặc trong dự án tách biệt giữa bạn mockup html và bạn code javascript:

• Có 1 khoảng cách khá lớn về việc kỹ năng cắt html và kỹ năng code javascript, nó có vẻ là có điểm chung nhưng thực tế không như kỳ vọng. Bạn cắt html không biết nhiều về javascript, cũng như ngược lại.
• Mất tài nguyên con người với việc thay đổi html/css trong JSX, phải sử dụng 2 người. Vì với Styled-component thì mỗi component nắm giữ style riêng. Nên khi thay đổi html, css thì cũng phải sửa lại component.

Việc sử dụng Vue.js khá dễ dàng vì có thể tách biệt được phần template và phần logic, sử dụng Vue.js ở cách này không khác gì cách dùng jQuery cả. Với vue.js thì template mockup và code javascript sẽ nằm chung trên 1 repo chứ không cần phải tách ra, và có thể 2 phía html mockup và javascript developer có thể làm chung trên cùng tập tin.

Bỏ qua sự so sánh về tốc độ, mình thực sự không quan tâm lắm, trừ khi quá chênh lệch. Và các vấn đề về kỹ thuật chi tiết giữa 2 nền tảng, thì có thể sử dụng Vue.js tốt nếu:

• Bạn không hề có ý định làm ứng dụng di động, ứng dụng native với Vue.js
• Team bạn thiên về graphics design và phụ thuộc khá nhiều vào html mockup.
• Làm phần dashboard, web application

Fullstack Station Tips

React từ 16.8 có Reack Hooks rất lợi hại, có thể thay đổi về cách viết React nhiều trong tương lai gần. React Hooks sẽ giúp cho dự án không phụ thuộc vào Component Class mà vẫn có các tính năng hay, tiện lợi của component class. Dù Vue.js cũng rất tuyệt để làm sản phẩm, nhưng với những ưu điểm của React, độ phổ biến của hệ sinh thái kết hợp với React Hooks sẽ tạo ra sức mạnh đáng kể cho React.js

Sự so sánh Vue.js và React.js, hay chọn lựa chỉ có giá trị trong dự án nhất định, còn về con đường lập trình thì mình nghiêng hẳn hoàn toàn về React.js.

Hi vọng bài viết có ích cho những bạn đang còn lăn tăn giữa việc chọn React.js hay Vue.js, và mong có ý kiến phản biện từ các bạn đã sử dụng Vue.js.

The post So sánh Vue.js và React.js: một cái nhìn toàn diện appeared first on Fullstack Station.

Câu trả lời ngắn gọn: tùy thuộc vào bạn, làm sao viết code thoải mái để Application State tối giản nhất có thể mà không làm mất tính tin tưởng vào ứng dụng.

(Bài viết này sử dụng cho cả React Js và React Native)

Một số khái niệm

Application State: hay còn gọi là Redux Store chứa trạng thái của ứng dụng bao gồm dữ liệu từ máy chủ, kết quả tương tác/hành động của người dùng, dữ liệu từ thiết bị (GPS, Clock, Accelerometer…)
Local State: là trạng thái nội tại của  component, sự thay đổi bất kỳ trong Local State không làm ảnh hưởng đến Application State

Presentation Component: là component chỉ có nhiệm vụ hiển thị, nhận tương tác từ người dùng.
Container Component: là component bao bọc Stateless/Presentation component và truyền dữ liệu cho các component này bằng props.

Stateless Component: đây là một phiên bản của Presentation Component nhưng không chứa state, thông thường được viết bằng hàm đơn thuần, mọi thứ đều được truyền thông qua function’s arguments (props).

Khi nào nên sử dụng Redux

Trước tiên, xin trích dẫn những câu trả lời từ những người tạo ra React và Redux:

Pete Hunt (Cựu thành viên tạo ra React):

You’ll know when you need Flux. If you aren’t sure if you need it, you don’t need it.

Dan Abramov (Tác giả Redux):

I would like to amend this: don’t use Redux until you have problems with vanilla React.

Như vậy, chỉ sử dụng Redux/Flux khi và chỉ khi bạn gặp vấn đề với React. Lý thuyết là vậy, nhưng để biết được tình huống nào gọi là “vấn đề” quả thật không hề dễ dàng, và khi đã gặp vấn đề thì lượng code đã viết cũng đã trở nên kha khá, và việc tích hợp Redux sẽ trở nên khó khăn hơn – tất nhiên không phải là quá khó, nhưng thay vì business logic  bạn đặt ở 1 chỗ (có thể chia nhiệm vụ cho từng thành viên trong nhóm khác nhau, có thể test dễ dàng hơn) thì business logic được đặt ngay trong chính React’s component => việc tái cấu trúc luồng hoạt động của dự án ước chừng sẽ khó khăn là vì vậy.

Như hình mô tả dưới đây, mỗi node là 1 component, việc tách ra trạng thái tổng, giúp chúng ta dễ bảo trì phần Model (business logic) và phần View (component) trong mô hình MVC, cũng như dễ dàng sử dụng SSR (Server Side Rendering):

Theo điều kiện nguồn lực, dần dà việc tái cấu trúc dự án để sử dụng Redux dần trở nên bất khả thi, nhất là đối với những dự án không biết tách “Container Component” và “Presentation Component” ra riêng biệt:

Do vậy, yếu tố quyết định là phải phân biệt được “Container Component” và “Presentation Component”, khi đó Container Component sẽ làm việc với Application State, còn Presentation Componnent sẽ có Local State.

Một điều dễ nhận ra là khi áp dụng Redux, mặc dù nó tốt thiệt – giúp cho ứng dụng dễ hiểu, dễ bảo trì, nhưng lượng code phải viết sẽ nhiều lên kha khá. Cứ mỗi chức năng, ta cần phải viết Actions/Events -> Reducers -> Container Component -> Presentation Component, tương ứng bạn cũng sẽ viết Test cho chừng đó bước, vì vậy việc sử dụng Application State một cách hợp lý là điều cực kỳ quan trọng, giúp cho ứng dụng gọn nhẹ về mặt cấu trúc, code, và tài nguyên (bộ nhớ để lưu trữ Store)
Muốn tìm cách cải thiện ứng dụng sao cho dễ hiểu, dễ bảo trì thì đọc tiếp :). Mình cũng từng như bạn, cũng như rất nhiều lập trình viên khác sử dụng Redux bị rối khi thắc mắc không biết là khi nào nên dùng Application State (trạng thái của ứng dụng) khi nào nên dùng Local State (trạng thái của component) để làm sao đạt được mục đích là:

• Application State tối giản nhất có thể
• Sử dụng Local State để viết code ngắn gọn nhất có thể

Nếu bạn đọc xong mà vẫn không thích Redux, thì khi có vấn đề về việc trao đổi dữ liệu giữa component cha-con thì đọc ở bài: “Sử dụng context để giao tiếp giữa các component cha-con trong React”

Sử dụng Redux với React sao cho hiệu quả

Nếu bạn có sử dụng React Native thì cũng có biết là từ phiên bản 0.25 trở đi, thì cách viết import, creatClass có khác đôi chút:
0.24 trở về trước

import React, { Component, View } from 'react-native';

0.25+

import React, { Component } from 'react';
import { View } from 'react-native';

Qua đó để thấy rằng, React Native quay trở về đúng bản chất của nó khi hệ sinh thái React ra đời, đó là React Native chỉ đóng vai trò phần View, còn React sẽ đóng vai trò xương sống khởi tạo hệ sinh thái React. Mình đưa ra ý này là để nhấn mạnh tầm quan trọng của sự tách biệt giữa các thành phần, càng nhỏ thì càng dễ bảo trì, do vậy nếu vẫn chưa thông ở phần “Khi nào nên sử dụng Redux” thì bạn hãy nghiên cứu thêm rồi đọc tiếp nhé.

Làm sao để sử dụng Redux hiệu quả, thì câu trả lời đơn giản là một Câu hỏi: Có các “thành phần” bất kỳ nào của ứng dụng sử dụng “kết quả” của hành động thay đổi trạng thái hay không?
“Thành phần” ở đây có thể là UI components, hoặc lưu trữ vào local store, hoặc lưu trữ ở server. Chỉ cần mỗi khi bạn bắt đầu viết 1 chức năng, component hãy đặt câu hỏi trên cho những tương tác vào ứng dụng (có thể sự kiện từ nhiều phía khác nhau), thông thường Local State sẽ được sử dụng để quản lý sự tương tác của người dùng, ví dụ những sự kiện sau thì không cần thiết phải sử dụng Application State:

• Toggle một menu, hoặc accordion
• Input text, radio, select..: bình thường sẽ sử dụng Local State
  • Nếu các loại input là dạng search realtime, hoặc freeze search, filter cho mỗi ký tự nhập vào thì dùng Application State, bởi vì nó có tác động đến component khác
• Những tương tác của người dùng đối với ứng dụng chỉ là tạm thời mà có thể khi refresh ứng dụng, bạn không còn quan tâm. Vì nếu quan tâm, nghĩa là cần lưu trữ ở đâu đó, có nghĩa là nó đã tác động đến “thành phần” khác thì nên sử dụng Application State.

Fullstack Station’s Tips

Có nhiều lập trình viên khuyên nên viết Stateless Component bằng hàm thông thường, ví dụ:

import React, { PropTypes } from 'react'

const Todo = ({ onClick, completed, text }) => (
  <li
    onClick={onClick}
    style={{
      textDecoration: completed ? 'line-through' : 'none'
    }}
  >
    {text}
  </li>
)

Bạn thường cũng sẽ viết theo, nhưng do lười biếng nên thiếu đoạn code sau:

Todo.propTypes = {
  onClick: PropTypes.func.isRequired,
  completed: PropTypes.bool.isRequired,
  text: PropTypes.string.isRequired
}

Và nếu tốt hơn nữa thì có thêm defaultProps cho những props không bắt buộc truyền vào. Việc thêm propTypes vào các component là cần thiết, để React sẽ kiểm tra cho bạn tính đúng đắn của component khi thực thi, sẽ báo cho bạn biết nếu props bị thiếu, từ đó giúp cho chất lượng sản phẩm được nâng lên, ít lỗi hơn. Rõ ràng với đoạn mã trên, nếu không ràng buộc bắt  buộc thì sự kiện onClick sẽ bị lỗi nếu truyền props bị thiếu!

Lời kết

Khi bạn áp dụng Redux vào React, những vấn đề về việc khi nào nên sử dụng Application State hay Local State đã được giải đáp phần nào trong bài viết này. Tùy trường hợp vào mỗi dự án có tính chất khác nhau mà việc áp dụng cũng sẽ linh động khác nhau, chứ không nhất thiết phải theo một mô hình nào, bởi vì ngay cả người tạo ra cũng không thể dự tính được hết các tình huống sử dụng thực tế của sản phẩm được. Nếu bạn có ý kiến để hỗ trợ bài viết tốt hơn, vui lòng comment nhé!

Bài viết tới, mình sẽ bàn luận tới 1 vấn đề cũng không có cách giải quyết hoàn hảo, đó là: nên đặt business logic vào actions hay reducers trong Redux?

The post Hướng dẫn sử dụng Redux hiệu quả trong ứng dụng React appeared first on Fullstack Station.

Không gì dễ hơn việc học bằng các ví dụ thực tế, nhất là đối với việc lập trình React Native. Giới thiệu với các bạn một nơi để học React Native qua ví dụ trong 30 ngày, sau khi hoàn thành xong các ví dụ này đảm bảo bạn sẽ trở nên chuyên nghiệp với React Native. Tuy nhiên, nếu bạn không có thời gian, chỉ cần nhìn lướt qua các ví dụ của từng ngày, sẽ gợi cho bạn những chức năng của ứng dụng mà bạn phát triển.

Bắt đầu 30 ngày

Ngày 1

Đồng hồ bấm giờ iOS, chức năng đầy đủ như ứng dụng gốc

Ngày 2

Ứng dụng thời tiết

Ngày 3

The Twitter app entrance animation.

Ngày 4

Using CocoaPods with React Native.

An example with JTSImageViewController.

Reference: https://shift.infinite.red/beginner-s-guide-to-using-cocoapods-with-react-native-46cb4d372995#.z6ooi3o0t

Ngày 5

MapView and find Geo location.

Ngày 6

Spotify welcome screen/

Ngày 7

Pan gesture basic. Move a baseball around.

Ngày 8

Google map style swipe menu

Ngày 9

Layout of Twitter user page

Ngày 10

Tumblr menu animation

Ngày 11

Using OpenGL with React native

Reference: https://github.com/ProjectSeptemberInc/gl-react-native

Ngày 12

Charts with React native

Reference: https://github.com/tomauty/react-native-chart

Ngày 13

A tweet UI

Ngày 14

A tinder swipe

Reference:https://github.com/meteor-factory/react-native-tinder-swipe-cards

Ngày 15

A time picker

Ngày 16

Unlock with gesture

Reference:https://github.com/spikef/react-native-gesture-password

Ngày 17

Native search bar and Fuzzy search

Reference:https://github.com/umhan35/react-native-search-bar

Ngày 18

Sortable. drag and reorder the blocks.

Ngày 19

Unlock app with touchID

Reference:https://github.com/naoufal/react-native-touch-id

Ngày 20

Sigle page Reminder

Ngày 21

Multi page Reminder

Ngày 22

Google Now

Ngày 23

Local WebView An example using D3.js

Ngày 24

Youtube scrollable tab

Reference: https://github.com/brentvatne/react-native-scrollable-tab-view

Ngày 25

Custome in-app browser

Reference: https://github.com/d-a-n/react-native-webbrowser

Ngày 26

Swipe and Switch

Ngày 27

iMessage Gradient. The chat bubble changes its gradient color with its pageY.

Reference: https://github.com/brentvatne/react-native-linear-gradient

Ngày 28

iMessage Image Picker.

Ngày 29

Quick action with 3D Touch. Quick action on launching days.

Ngày 30

Push Notification.

Thực hiện

Bước 1

Repo: https://github.com/fangwei716/30-days-of-react-native
Fork repo

Bước 2

Pull về và chạy cài đặt các gói cần thiết “npm install”

Bước 3

Android

Chạy lệnh
react-native run-android

iOS

Dùng XCode mở ios/ThirtyDaysOfReactNative.xcworkspace

Các công đoạn này khá đơn giản nên không cần nói nhiều. Điều quan trọng qua bài viết này mình nghĩ chỉ cần nhìn hình demo, và mở mã nguồn ra tham khảo, việc build cái ứng dụng này cũng không cần thiết lắm

The post Học React Native trong 30 ngày qua ví dụ thực tế appeared first on Fullstack Station.

Nhận thấy các cấu hình, cài đặt môi trường mới cho dự án sử dụng React quá phức tạp, đội ngũ Facebook cùng cộng đồng mã nguồn mở đã cùng nhau tạo ra dự án hạt giống “Create React App” đã bao gồm:

• Webpack
• ESLint
• Babel

Những công cụ trên giúp cho bạn tập trung vào việc lập trình, phát triển dự án thay vì phải mất công sức nghiên cứu. Giờ đây bạn có được những tính năng như: Hot Module Replacement, Code checking, Transform ES6 -> ES5… mà không cần phải làm bất cứ thao tác gì. Không những vậy, dự án hạt giống này đã thu gọn tinh giản các thông báo từ các công cụ đi kèm, làm sao đơn giản nhất có thể, chỉ hiển thị những thứ gì cần thiết.

Có thể nói, đây là dự án mầm tốt, mặc dù cũng sẽ khó để phù hợp với tất cả mọi người, nhưng đa phần sẽ giúp cho bạn tập trung vào việc học react, cũng như lập trình hoàn thành dự án đơn giản và nhanh chóng hơn. Sau đó, nếu có thời gian hãy nghiên cứu thêm webpack và babel.

Nếu quay lại thời gian bắt đầu học react, mình ước có được cái này ngay lúc đó, khỏi cần suy nghĩ đến Webpack là khỉ khô gì. Mặc dù nghiên cứu webpack cũng mang lại nhiều thú vị, nhưng nó không phải là yếu tố quan trọng để sử dụng Reactjs.

The post Hướng dẫn bắt đầu với React cách đơn giản nhất appeared first on Fullstack Station.

Các bài viết khác liên quan nền tảng nên đọc:

• ES6 là gì?
• ReactJs là gì?
• Vòng đời của 1 component ReactJs trong ES6
• Hướng dẫn cấu trúc thư mục và cách viết ReactJs chuẩn

Cũng có bài viết hướng dẫn cài đặt Webpack cho React + Meteor, nhưng do phụ thuộc nhiều Meteor nên cũng hạn chế người dùng.

Những điểm lợi của ES6

Có thể nói sau 1 thời gian sử dụng ES6, viết code nhanh hơn và cấu trúc tập tin nhìn cũng gọn gàng hơn, sau đây là điểm qua một số điểm lợi mà mình trải nghiệm thực sự:

• Hàm Arrow (=>): đây có lẽ là cách viết được sử dụng nhiều của ES6. Gọi là cách viết tắt hàm, nhưng bản chất giữa hàm Arrow và hàm bình thường có sự khác nhau về ngữ cảnh hàm this. Có thể nói đơn giản thì hàm bình thường có this còn hàm Arrow thì không có this, this bên trong hàm Arrow là this của nơi khai báo hàm Arrow.
• Xử lý chuỗi dễ dàng hơn:

  `Bạn không thể
  xuống hàng 
  như vậy với "ES5" được.`
  

• Giá trị mặc định cho tham số: function(a = 12, b =”chuỗi”)
• Truyền tham số không xác định số lượng: cái này dùng nhiều khi gọi component <ChildComponent {…this.props} /> hoặc function(x, …y)
• let và const: được sử dụng thay thế hoàn toàn cho var, vì nó kiểm tra biến đã được khai báo chưa.
• class: cái này quan trọng nhé, trong ES6 bạn có thể kế thừa từ class khác: ví dụ “MyComponent extends React.Component”
• module: sử dụng từ khoá import và export để khai báo và sử dụng module

Việc sử dụng ES6 đặc biệt là cho React là rất thích hợp, về phía AngularJs đã chọn TypeScript để viết chính cho dự án dùng AngularJs, TypeScript có nhiều điểm tương đồng với ES6, và đều là cách để nâng hiệu quả của dự án, tốc độ lập trình lên cả nên bạn nên sử dụng cho dù tốn chút thời gian để làm quen.

Webpack là gì

Hiện tại cũng có một số bài viết giới thiệu webpack rồi nên mình không đi vào chi tiết, đơn giản là nó đóng gói, biến code viết bằng A (js, jade, coffee, less, sass, png) thành B(js, css,png) , và cộng thêm nhiều tính năng hữu ích khác. Trong bài này thì là sử dụng Babel Compiler để biến ES6 => ES5, cụ thể hơn là React ES6 => React ES5 !!!

Tự nhiên phải mất công viết bằng ES6 rồi chuyển thành ES5 chi vậy? Chắc có bạn cũng sẽ thắc mắc chỗ này: đó là bởi vì ES6 sẽ xu thế tất yếu nhưng các trình duyệt lại không hỗ trợ hết các tính năng của ES6, sẽ cần một khoảng thời gian nữa để các trình duyệt web hỗ trợ hết các tính năng ES6, khi đó thì không cần phải chuyển nữa. Nói như vậy không có nghĩa là không dùng Webpack đâu nha, Webpack cũng là công nghệ hay giúp cho việc lập trình nhanh hơn, sử dụng trong bài viết này đây cũng chưa tới 1/10 tính năng của webpack nữa.

Phần 1: cài đặt webpack

Đơn giản là bạn cần cài đặt Nodejs và NPM trước khi tiến hành, tuy nhiên nếu bạn đã đọc đến đây chắc không cần nhắc tới nó nữa

Bước 1

mkdir react-hello-world
cd react-hello-world
npm init

Rất đơn giản, tạo thư mục mới và khởi tạo dự án, điền vài thông tin liên quan là xong.

Bước 2

npm i webpack -S

Cài đặt webpack với tham số -S để lưu vào trong package.json

Bước 3

Tạo file webpack.config.js như bên dưới

var webpack = require('webpack');
var path = require('path');
//Thư mục sẽ chứa tập tin được biên dịch
var BUILD_DIR = path.resolve(__dirname, 'src/client/public');
//Thư mục chứa dự án - các component React
var APP_DIR = path.resolve(__dirname, 'src/client/app');

var config = {
  entry: APP_DIR + '/index.jsx',
  output: {
    path: BUILD_DIR,
    filename: 'bundle.js'
  }
};

module.exports = config;

Qua mấy dòng code trên, bạn cũng dễ dàng nhận thấy cấu trúc thư mục sẽ là:

src/
src/client
src/client/public
src/client/app

Nếu cấu trúc thư mục của bạn muốn thì vẫn thay đổi bình thường, chỉ cần sửa lại cho phù hợp trên webpack.config.js là được.

Bước 4

// ./src/client/app/index.jsx
console.log("Hello world")

Sau đó, tại thư mục react-hello-world, chạy lệnh sau:

./node_modules/.bin/webpack -d

Sau khi chạy xong, trong thư mục ./src/client/public sẽ xuất hiện file bundle.js, nghĩa là phần cài đặt đã hoạt động bình thường. Chỉ với dòng code đơn giản, bạn sẽ chưa thấy hứng thú gì đúng không? Hãy kiên nhẫn xem tiếp nhé!

Bước 5

Tạo file ./src/client/index.html với nội dung như bên dưới:

<!-- ./src/client/index.html -->
<html>
  <head>
    <meta charset="utf-8">
    <title>React.js using NPM, Babel6 and Webpack</title>
  </head>
  <body>
    <div id="app" />
    <script src="public/bundle.js" type="text/javascript"></script>
  </body>
</html>

Trong file index.html này không hề sử dụng các file trong thư mục app là index.jsx, đây chính là điểm quan trọng của webpack.

Bạn mở file index.html bằng trình duyệt, và mở Developer Tools -> Console, sẽ thấy “Hello world”.

Phần 2: cài đặt Babel Loader

Như phần đã nói ở trên, ES6 không được hỗ trợ đầy đủ từ các trình duyệt hiện nay, nên mã phải được biên dịch ra ES5 thì mới chạy được. Do vậy cần chuyển đổi từ ES6 => ES5, tương ứng React ES6 => React ES5, và Babel Loader là công cụ để chúng ta thực hiện điều đó.

Webpack sử dụng Babel Loader để thực hiện việc chuyển đổi, sau đó đóng gói lại như bình thường. Babel Loader sẽ chuyển đổi code sử dụng ES6 như class, let, const, arrow, … thành React.CreateClass(…), hay React.CreateElenement(‘a’, …), được diễn tả như mô hình sau:

Cài đặt Babel Loader và các preset: react và es6

npm i babel-loader babel-preset-es2015 babel-preset-react babel-core -S

Tạo file ./.babelrc với nội dung như bên dưới

{
  "presets" : ["es2015", "react"]
}

Và sửa lại file webpack.config.js như sau:

var webpack = require('webpack');
var path = require('path');
//Thư mục sẽ chứa tập tin được biên dịch
var BUILD_DIR = path.resolve(__dirname, 'src/client/public');
//Thư mục chứa dự án - các component React
var APP_DIR = path.resolve(__dirname, 'src/client/app');

var config = {
  entry: APP_DIR + '/index.jsx',
  output: {
    path: BUILD_DIR,
    filename: 'bundle.js'
  },
//Thêm 
  module : {
    loaders : [
      {
        test : /\.jsx?/,
        include : APP_DIR,
        loader : 'babel-loader'
      }
    ]
  }
//Kết thúc Thêm
};

module.exports = config;

Cài đặt React

npm i react react-dom -S

Mở tập tin, index.jsx, xóa hết và viết 1 component đơn giản như sau:

import React from 'react';
import {render} from 'react-dom';

class App extends React.Component {
  render () {
    return <p> Hello React!</p>;
  }
}

render(<App/>, document.getElementById('app'));

Chạy lại lệnh để build

./node_modules/.bin/webpack -d

Phần 3: tối ưu

Ở phần trên, cứ mỗi lần có thay đổi, chúng ta phải gõ lệnh để cho webpack build lại, như vậy không chuyên nghiệp chút nào, mà cũng không có được tính năng HMR tuyệt vời nữa. Vậy nên phần này sẽ là phần tối ưu các thiết lập cho webpack, chỉ cần gõ lệnh thêm tham số như sau là xong:

./node_modules/.bin/webpack -d --watch

Chỉ đơn giản vậy thôi, nhưng chúng ta cần làm thêm 1 chút nữa để hoàn thiện, bạn mở file package.json, và thêm đoạn mã sau:

{
  // ...phần đã có, nhớ thêm dấu ,
  "scripts": {
    "dev": "webpack -d --watch",
    "build" : "webpack -p"
  },
  // ...phần đã tồn tại khác
}

Như vậy, kể từ giờ, mỗi lần bắt đầu mỗi ngày làm việc, bạn chỉ cần gõ `npm run dev` để thực hiện lập trình, và `npm run build` để build thành file bundle.js.

Kết

Mình biết các bạn đa phần tiếp cận React bằng ES5 vì theo tài liệu chính thức trên trang chủ là sử dụng ES5, nhưng đó là bởi vì ReactJs ra đời trước khi ES6/ES2015 được chính thức ra mắt, nên họ vẫn còn sử dụng ES5 trong tài liệu vì cộng đồng. Còn trên thực tế, đa phần các dự án đều sử dụng ES6 sau đó biên dịch lại thành ES5, cách làm này vừa giúp lập trình nhanh (ES6), vừa giúp cho dự án có tính thành phẩm có chất lượng cao (webpack).

Chú ý là một số function stateless thì nên sử dụng function bình thường sẽ tốt hơn là class với component lifecycle. Nếu component có lifecycle thì nên sử dụng ES6 và đa số trường hợp khác.

The post Hướng dẫn cài đặt Webpack để viết Reactjs/ES6 appeared first on Fullstack Station.

Time traveling là gì

Time traveling là “du hành thời gian” ngay trong nghĩa đen của nó, như cái cỗ máy vượt thời gian của Đôrêmon vậy đó. Khái niệm này thường được hiểu theo khái niệm về vật lý không gian, thời gian, ánh sáng nhiều hơn là liên quan đến lập trình. Trong lập trình ứng dụng phần mềm, Time traveling là kỹ thuật giúp cho ứng dụng có tính Undo/Redo, hay Replay (tưởng tượng như bàn cờ có ghi lại các nước đi nên dễ dàng replay), kỹ thuật này chính là mục tiêu hướng tới của Redux (Xem Redux js là gì) do Dan Abramov giới thiệu tại React Conf Euro 2015 và nhanh chóng lan toả trong giới lập trình.

Kỹ thuật này chỉ có được, khi ta áp dụng thư viện Redux, hoặc các thư viện khác mà đi theo hướng của Flux (các thư viện khác thì mình không chắc là có Time traveling hay không). Trong lập trình ứng dụng giao tiếp với người sử dụng hay cả với server thì trạng thái của phần mềm là rất quan trọng, nhất là các ứng dụng có giao tiếp với người dùng, và đặc biệt là ứng dụng web với các điều kiện có thể xảy ra làm thay đổi trạng thái như sau:

• Dữ liệu trực tuyến được cập nhật từ máy chủ một cách tự động
• Dữ liệu sự kiện từ thao tác của người dùng: nhấn chuột, di chuyển con trỏ, nhập dữ liệu..
• Dữ liệu từ bộ định tuyến URL (Router) nếu người dùng nhấn vào 1 liên kết
• Dữ liệu từ thời gian
• Dữ liệu có được từ lời gọi API bất đồng bộ

Như vậy, trong một ứng dụng SPA (Single Page Application) có tính chất trực tuyến, thì tất cả các loại dữ liệu có thể đều có thể xảy ra bất kỳ lúc nào. Vấn đề đặt ra là: tại mỗi thời điểm đó (giả sử như thời gian ngưng lại), làm sao biết được trạng thái của ứng dụng đang như thế nào, và làm sao để quay lại 1 số sự kiện trước đó – tức là áp dụng khái niệm rollback, undo.

Với các kỹ thuật lập trình hiện tại, hầu như không thể có giải pháp, nên việc ra đời thư viện Redux được xem như một bước đột phá của ngành lập trình ứng dụng. Với ứng dụng web không phải là SPA, thường đơn giản hơn 1 bước do URL được lược giản đi rồi, bản chất URL cũng là 1 trạng thái (state) của ứng dụng.

Bạn có thể xem ví dụ trên, toàn bộ thao tác của người dùng, đều được lưu vào cây bên phải (Redux Dev Tool – xem phần tiếp theo bên dưới), khi ta click vào cột bên phải, ở 1 dòng nào đó và bị gạch đi, có nghĩa là bỏ sự kiện đó ra khỏi trạng thái của ứng dụng.

Nhờ có tính năng này, giả sử code bị lỗi – đây là điều đau khổ nhất khi debug – thì vì cây sự kiện vẫn còn, nên khi bạn thay đổi code thành code đúng, thì Redux sẽ apply toàn bộ sự kiện đó với code mới và giúp chúng ta không cần phải thực hiện lại hàng loạt thao tác phức tạp để reprodure lại các dữ liệu cũ để xem code đúng chưa. Hoặc là thay đổi một giá trị tính toán nào đó, ví dụ như ở trên, thay vì click là +-1, thì sửa giá trị thành +-2 chẳng hạn, thì trạng thái mới sẽ được cập nhật dựa trên “sự kiện đã thao tác”.

Time traveling – Redux có lợi gì

Đoạn trên giải thích hơi dài một chút, nói tóm lại với Time traveling của Redux thì có các điểm:

• Dễ dàng debug
• Dễ dàng phát triển nhanh ứng dụng vì không phải mất thời gian nhập sự kiện lại
• Dòng chảy của chương trình dễ hiểu – giúp cho việc cộng tác nhóm dễ dàng
• Dòng sự kiện giúp cho chương trình tuân theo một logic chặt chẽ, chỉ cần nhìn vào cây sự kiện là bạn có thể đoán được hoạt động của chương trình, vì vậy còn được gọi là Predict container

Bạn chỉ cần áp dụng Redux là có thể đạt được những lợi ích này rồi. Redux được xem là dành cho ReactJs nhưng bạn hoàn toàn có thể kết hợp với những framework,thư viện bất kỳ như React Native, AngularJs, BackboneJs…

Mặc dù bạn có thể học ReactJs mà không cần quan tâm đến Redux, nhưng mình khuyên là nên xem chung Redux vì nó giúp cho việc lập trình dễ hiểu hơn. Có thể nói React hay ở vòng đời component thì có thể xem Redux hay ở vòng đời “sự kiện” của ứng dụng.

Redux Dev Tool

Công cụ này do chính tác giả của Redux viết, giúp bạn hiểu hơn về dòng sự kiện của ứng dụng, cũng như debug dễ dàng hơn, bao gồm cả tính năng Time traveling nữa.

Kết

Redux rất là tuyệt, bản chất hoạt động một cách độc lập nên bạn có thể áp dụng cho bất kỳ dự án nào, sử dụng bất kỳ nền tảng, thư viện javascript nào. Nếu bạn vẫn chưa áp dụng Redux, lời khuyên thật tình là phải áp dụng sớm nhất có thể, có 2 nguồn để học tốt:

• http://learnredux.com
• https://egghead.io/courses/building-react-applications-with-idiomatic-redux

The post Kỹ thuật lập trình Time traveling là gì appeared first on Fullstack Station.

GraphQL3R là gì?

GraphQL3R là cách mình đặt tên cho thể thống nhất các công nghệ của Facebook: GraphQL, React Native, Redux và Relay để lập trình ứng dụng di động đa nền tảng bao gồm iOS và Android, từ client đến server.

Tất cả những công nghệ này mình đã có các bài viết giới thiệu nên sẽ không nói lại nữa:

• GraphQL là gì?
• React Native là tương lai của ứng dụng di động?
• Redux là gì?
• FlowType là gì?

FlowType tuy không được coi là nền tảng chính, nhưng đây là nền tảng hỗ trợ xuyên suốt quá trình lập trình rất quan trọng, và chắc chắn là rất hiệu quả khi phát triển với React Native.

Ngoài ra còn có Parse Server (BaaS) mình chưa có cơ hội để viết bài giới thiệu, đây là nền tảng đã được mã nguồn mở tuơng tự Firebase (không hướng đến tính Realtime bằng Firebase) nhưng bao gồm rất nhiều tính năng mạnh mẽ Push Notification, REST API, Social servive…

Do Relay đi chung với GraphQL, React, không được hoặc ít sử dụng độc lập với các nền tảng khác, nên có thể xem như là 1 phần phụ của bộ GraphQL3R này.

Những công nghệ này được dùng để viết ứng dụng F8 (Facebook Conference 2016) vừa qua, Facebook cũng cố gắng đưa bộ công nghệ này đến với mọi người với trang web MakeItOpen. Bao gồm các bước, tài liệu:

• Kế hoạch viết ứng dụng
• Phân tích thiết kế ứng dụng đa nền tảng
• Luồng dữ liệu
• Kiểm thử

Tại sao nên sử dụng GraphQL3R

Thứ nhất, đây là bộ nền tảng mã nguồn mở từ A->Z duy nhất tính đến thời điểm hiện nay dành cho ứng dụng di động Native (sức mạnh của React Native thì bạn xem thêm ở bài React Native là tương lai của lập trình ứng dụng di động). Tổng lượng stars của tổ hợp công nghệ này khoảng hơn 100k, đây là con số cực kỳ ấn tượng mà không có một tổ hợp nào có thể đạt được!

Thứ hai, những công nghệ này đều được sử dụng trong môi trường sản phẩm (Production) bởi các công ty, sản phẩm công nghệ hàng đầu như: Facebook, Instagram, Airbnb, Uber

Thứ ba, mang những tinh tuý của lập trình hiện đại như Time travel (từ redux), Hot Module Replacement (Webpack) giúp cho thời gian lập trình ứng dụng di động giảm đi rất nhiều, bạn không còn phải build khi lập trình ứng dụng di động native cho iOS và Android nữa. Cũng như việc debug, test ứng dụng sẽ đơn giản hơn, tiết kiệm thời gian. Ứng dụng cũng trở nên đáng tin cậy hơn với Redux: Single source of true!

Thứ tư, tổ hợp này khá linh hoạt, bạn có thể tách phần client từ React Native ra, dùng phần còn lại với Angular 2 (hoặc Ionic Framework), hoặc tất nhiên với ReactJs. Phần GraphQL có thể dùng với nhiều nguồn dữ liệu khác nhau, nên có thể thay thế Parse.

Thứ năm, ….n, thật sự 4 điểm trên có thể bao quát gần hết các đặc điểm để chọn nền tảng rồi, nên nói thêm nữa cũng thừa

GraphQL3R không dành cho tất cả

Đúng là tổ hợp GraphQL3R rất rất mạnh, nhưng chính vì vậy chính là điểm yếu của nó khi bạn phải có quá nhiều thứ để học. Để hoàn thành lập trình ứng dụng di động mà học hết mấy thứ này bao gồm lập trình cho tới quản lý server, phân tích thiết kế … thì quả là không thể!

Vì vậy, để áp dụng tổ hợp này, bạn cần có một nhóm khoảng 3 người trở lên, rất thích hợp cho start-up, mình chưa thấy điểm yếu của tổ hợp này dành cho viết bất cứ loại ứng dụng nào – ngoại trừ game do phải dùng đồ hoạ nhiều, nên nếu thay phần client thì các phần sau cũng không còn giá trị mấy.

Nếu bạn là cá nhân lập trình ứng dụng di động, theo mình thì nên sử dụng React Native thôi, còn phần backend thì nên sử dụng Firebase, hoặc Meteor (Xem thêm bài Điều gì khiến Meteor 1.3 trở nên đặc biệt), hoặc nếu bạn thích Meteor và GraphQL thì có thể nghiên cứu Apollo Stack.

Bí kíp lập trình ứng dụng di động trong tay bạn!

Nhiều lúc nghiên cứu cái hệ sinh thái của Facebook làm cho mình hứng thú một cách điên cuồng, mình yêu cái cách mà React/React Native hoạt động, cách mà Redux hoạt động, kết hợp với cái cách mà Webpack (không liên quan FB) giúp cho công việc lập trình nhanh chóng, module hoá mọi thứ. Tuy nhiên, cái gì cũng có giá của nó, những công nghệ đó được áp dụng bởi những ông lớn vì họ có nguồn lực để thực hiện, trong khi start-up thì không 1 xu dính túi, nhưng cũng đừng vì vậy mà nản chí, ngày xưa chưa ai cũng tranh giành bí kíp “Tịch tà kiếm phổ”, còn ngày nay tổ hợp GraphQL3R chính là bí kíp ngay trong tay bạn, mã nguồn mở, luyện tổ hợp này không có lo mất bản năng đàn ông đâu!

The post Lập trình ứng dụng di dộng từ công nghệ của Facebook appeared first on Fullstack Station.

Trạng thái (state) của ứng dụng là gì

Cùng lướt qua các ví dụ cho dễ:

Ví dụ 1: Để hình dung đơn giản nhất, trạng thái của ứng dụng tương tự như cái nút Lui (Back)/Tới (Forward) lịch sử của trình duyệt của trình duyệt web. Bạn mở web nhấn vào vòng vòng một hồi, rồi nhấn quay lại các trang trước, mỗi trang như vậy còn được gọi là trạng thái. Nhưng, với các ứng dụng SPA (Single Page Application) thì chuyện Lui/Tới cũng là cả vấn đề rồi.

Ví dụ 2: Không liên quan đến web nhưng rất điển hình đó là trạng thái của bàn cờ tướng hay cờ vua chẳng hạn. Mỗi khi người chơi đi một nước – trong thi đấu – họ phải ghi lại từng nước đi, bằng cách này sau khi chơi xong người ta có thể tái hiện lại bàn cờ một cách dễ dàng. Ứng với mỗi nước đi, đó chính là trạng thái của bàn cờ.

Vậy thì nó liên quan gì đến trạng thái của ứng dụng?

Một ứng dụng web hoạt động cần dữ liệu từ phía máy chủ, thao tác của người dùng,…tổng hợp các thứ này lại ta được trạng thái của ứng dụng. Nếu biết trạng thái này, có nghĩa là tại thời điểm X ta biết được máy chủ đã trả về dữ liệu gì, người dùng đã thao tác những gì, nhập vào dữ liệu gì.

Việc biết trạng thái này có quan trọng không?

Các ứng dụng web hiện nay ngày càng phức tạp, việc biết được trạng thái này giúp cho công việc kiểm soát lỗi dễ dàng hơn, nhất là nó làm cho cách chúng ta lập trình cũng đơn giản hơn. Ví dụ, nếu bạn có một biểu mẫu mua hàng, giả sử có 5 bước: xác nhận đơn hàng, áp dụng mã khuyến mãi, điền thông tin giao hàng, thanh toán, hoàn tất. Với một ứng dụng web thông thường, nếu xảy ra lỗi ở bước 4, lập trình viên sẽ kiểm tra lại và nhập dữ liệu từ 1->4, tìm lỗi sau đó sửa lỗi, công đoạn này lặp đi lặp lại n lần!!! Nếu sử dụng Redux, mỗi công đoạn xem như một trạng thái và bạn không cần phải lặp lại bước 1->4 nữa.

Các nguyên tắc cơ bản của Redux

Nguồn dữ liệu tin cậy duy nhất

Như mình đã giới thiệu cơ bản ở trên, trong quá trình hoạt động của ứng dụng, bị phụ thuộc khá nhiều yếu tố: dữ liệu từ máy chủ ban đầu, thao tác của người dùng (nhập dữ liệu, click menu, button…), dữ liệu cập nhật từ máy chủ, dữ liệu được tính toán trong ứng dụng (Ví dụ: tính toán số dư tài khoản dựa trên biến động của tỉ giá)…những yếu tố này còn gọi là nguồn dữ liệu. Những nguồn dữ liệu này đến từ những nơi khác nhau, bất kỳ khi nào, khiến cho ứng dụng của chúng ta rất khó kiểm soát, chúng tác động đến những thành phần đơn lẻ, hoặc nhiều thành phần trên ứng dụng, hoặc hiệu ứng dây chuyền. Chính vì sự phức tạp đó, là vấn đề mà Redux muốn giải quyết, tất cả các nguồn dữ liệu cần phải được quản lý và tạo thành một nguồn duy nhất, tin cậy.

Trạng thái là chỉ được phép đọc (read-only)

Trạng thái của ứng dụng không được phép thay đổi “trực tiếp”, trạng thái cũng chỉ là một đối tượng thôi mà, nên việc thay đổi là được. Tuy nhiên, với Redux hay Flux thì trạng thái chỉ thay đổi khi và chỉ khi có một sự kiện xảy ra, giống như ra trận thì chỉ được phép nghe lời từ chỉ huy, mọi tin tức tình báo đều được gởi tới chỉ huy, nếu không có lệnh từ chỉ huy thì tất cả không được phép manh động.

Thay đổi chỉ bằng hàm thuần tuý

Điều may mắn là việc sử dụng Redux js là không quá khó, việc thay đổi trạng thái của ứng dụng, được thực hiện thông qua các hàm thuần tuý. Đưa vào giá trị sự kiện, trạng thái hiện tại và hàm trả về trạng thái tiếp theo. Dù tương lai ứng dụng của bạn có thể rất lớn, nhưng các hàm reducer này thì chỉ cần nhỏ gọn thay đổi trên từng lá của cây trạng thái, và chúng hoàn toàn có thể kết hợp với nhau tạo thành chuỗi sự kiện. Ví dụ: người click vào menu (một sự kiện => thay đổi trạng thái), sau đó router cũng cần thay đổi để phù hợp với ngữ cảnh.

Tính ứng dụng của Redux js là gì

Theo mình thấy Redux có 3 ứng dụng quan trọng nhất:

• Quản lý trạng thái: như một bản replay có thể undo/redo trạng thái của ứng dụng, phải nói là “Không thể tin được”, cá nhân mình rất thích tính tin cậy của ứng dụng mà Redux mang lại.
• Tăng tốc phát triển: với webpack đã có Hot Module Replacement, khi kết hợp với Redux, tạo thành sự kết hợp ăn ý, bạn có thể viết code và debug rất dễ dàng, hãy quay lại ví dụ về biểu mẫu mua hàng 5 bước ở trên, nếu bạn không áp dụng Redux, đồng nghĩa bạn phải debug lặp đi lặp lại việc nhập dữ liệu, mà chưa chắc lỗi do code gây ra mà do dữ liệu nhập vào.
• Ứng dụng offline: tất cả các thao tác của người dùng được lưu vào một cây trạng thái, khi có kết nối Internet, cây này sẽ được đồng bộ lên server bởi một loạt các sự kiện.

Sự khác biệt giữa Redux và Flux

Redux phát triển dựa trên Flux, nhưng đã lượt bỏ phần Dispatcher, và chỉ có duy nhất 1 store, …blah …blah, thôi nói nghe này: “Quên Flux đi“.
Nếu bạn chưa bao giờ nghe đến Flux hay Redux, thì đừng mất thời gian để tìm hiểu: Flux là gì, Flux khác Redux như thế nào, điểm yếu của Redux js là gì? Mình cũng đã từng mất thời gian như vậy, nhưng bây giờ mình tin chỉ cần nghiên cứu Redux là đủ. Đây là các lý do để chỉ nghiên cứu “Redux js là gì“:

• Hiện tại Redux đã đạt ~20k stars Github khi chưa đầy 1 năm
• Ứng dụng F8 của Facebook không sử dụng Flux mà sử dụng Redux:
• Dan Abramov, người tạo ra Redux đã gia nhập Facebook từ tháng 11/2015

Kết

Mình hi vọng qua bài “Redux js là gì” này, mình đã truyền tình yêu của mình dành cho Redux đến bạn. Cái hay của Redux là nó không phụ thuộc vào việc bạn sử dụng framework nào, nó là kiến trúc giúp cho ứng dụng phát triển nhanh, đáng tin cậy, và dễ hiểu khi làm việc nhóm. Cách người ta ghi lại nước cờ, làm cho tất cả mọi người đều dễ dàng hiểu và trình bày lại bàn cờ ra sao, thì Redux cũng như vậy!

The post Redux js là gì appeared first on Fullstack Station.

Danh sách phần mở rộng – Phần 1

App Intro

Đây là phần quan trọng cho ứng dụng của bạn lấy cảm tình của người dùng khi bắt đầu ứng dụng, giới thiệu các chức năng đặc biệt của ứng dụng:

Trang chủ: https://github.com/FuYaoDe/react-native-app-intro

Hỗ trợ: iOS & Android

Swipe 2

Swipe 2 thích hợp làm gallery ảnh, hoặc cũng làm dạng slideshow, hoặc cũng có thể dùng như App Intro, nhưng theo mình thì App Intro ở trên vẫn đẹp hơn.

Trang chủ: https://github.com/sunnylqm/react-native-swiper2

Hỗ trợ: iOS & Android

Grid View

Grid view giúp cho bạn dễ dàng tạo lưới, tuy nhiên phần mở rộng này cũng khá đơn giản, nên nếu bạn muốn làm ứng dụng có nhiều cấp, trong mỗi lưới sử dụng giao diện phức tạp, thì theo mình nên sử dụng cấu trúc Flex CSS, vì bạn phải sử dụng rất nhiều để tinh chỉnh layout.

Custom Navigation

Custom Navigation dùng để thay thế Navigator với tùy chỉnh background

Trang chủ: https://github.com/superdami/react-native-custom-navigation

Hỗ trợ: iOS & Android

Gifted Listview

Với phần mở rộng này, bạn có các tính năng như: Pull To Refresh, Load more với tính năng gom nhóm

Trang chủ: https://github.com/FaridSafi/react-native-gifted-listview

Hỗ trợ: iOS & Android

Với các phần mở rộng này hi vọng sẽ giúp bạn tiết kiệm được thời gian khi phát triển ứng dụng di động.

The post Danh sách các phần mở rộng hay cho React Native – Phần 1 appeared first on Fullstack Station.