Câu hỏi Tại sao sử dụng Redux trên Facebook Flux?


tôi đã đọc câu trả lời này, giảm boilerplate, đã xem xét một vài ví dụ về GitHub và thậm chí đã thử redux một chút (các ứng dụng cần làm).

Như tôi hiểu, động cơ doc redux chính thức cung cấp ưu điểm so với kiến ​​trúc MVC truyền thống. NHƯNG nó không cung cấp câu trả lời cho câu hỏi:

Tại sao bạn nên sử dụng Redux trên Facebook Flux? 

Đó có phải chỉ là một câu hỏi về phong cách lập trình: chức năng vs phi chức năng? Hoặc câu hỏi là trong khả năng / dev-công cụ theo sau cách tiếp cận redux? Có thể mở rộng quy mô? Hoặc thử nghiệm?

Tôi có đúng không nếu tôi nói rằng redux là một thông lượng cho những người đến từ các ngôn ngữ chức năng? 

Để trả lời câu hỏi này bạn có thể so sánh sự phức tạp của việc thực hiện các điểm động lực của redux trên thông lượng so với redux.

Dưới đây là các điểm động lực từ động cơ doc redux chính thức:

  1. Xử lý cập nhật lạc quan (như tôi hiểu, nó hầu như không phụ thuộc vào điểm thứ 5. Có khó để thực hiện nó trong thông lượng facebook?)
  2. Hiển thị trên máy chủ (facebook flux cũng có thể làm điều này. Bất kỳ lợi ích nào so với redux?)
  3. Tìm nạp dữ liệu trước khi thực hiện chuyển đổi tuyến đường (Tại sao nó không thể đạt được trong thông lượng facebook? Lợi ích là gì?)
  4. Tải lại nóng (Có thể với React Hot Reload. Tại sao chúng ta cần redux?)
  5. Hoàn tác / Làm lại chức năng
  6. Bất kỳ điểm nào khác? Giống như trạng thái bền bỉ ...

1006
2017-09-08 15:05


gốc


Redux là một triển khai "Facebook Flux". Thông lượng không phải là thư viện hoặc khung. Nó chỉ đơn giản là một kiến ​​trúc được đề xuất cho các ứng dụng web. Tôi không thấy làm thế nào bạn có thể so sánh việc thực hiện cụ thể với khái niệm trừu tượng đã thúc đẩy nó. Triển khai thực tế của một kiến ​​trúc Flux là Relay và phiên bản nguồn mở vẫn còn trong giai đoạn đầu. facebook.github.io/relay - Charlie Martin
@CharlieMartin Bởi FB Flux Tôi đề applicaiton như thế này github.com/facebook/flux/tree/master/examples. Dự án hiện tại của tôi được viết trên FB Flux (do FB Flux). Nếu bạn muốn bạn có thể nghĩ là kiến ​​trúc Redux trên kiến ​​trúc FB Flux. - Volodymyr Bakhmatiuk
Giờ thì tôi đã hiểu. Bạn muốn so sánh ví dụ Flux của Facebook với việc thực hiện Flux của Redux - Charlie Martin
Relay không phải là việc thực hiện Flux - Relay / GraphQL quan tâm hơn đến việc quản lý dữ liệu tìm nạp / queryng với máy chủ trong khi Flux chủ yếu quan tâm đến việc cấu trúc luồng dữ liệu giữa Client Side Data Models & View Components. Tuy nhiên có một số chồng lên nhau: Tại Facebook, chúng tôi có các ứng dụng được xây dựng hoàn toàn bằng cách sử dụng Flux, hoàn toàn sử dụng Relay hoặc cả hai. Một mô hình mà chúng ta thấy đang nổi lên là cho phép Relay quản lý phần lớn luồng dữ liệu cho một ứng dụng, nhưng sử dụng các cửa hàng Flux ở bên cạnh để xử lý một tập con của trạng thái ứng dụng - Hal


Các câu trả lời:


Redux tác giả ở đây!

Redux không cái đó khác với Flux. Nhìn chung nó có cùng kiến ​​trúc, nhưng Redux có thể cắt một số góc phức tạp bằng cách sử dụng thành phần chức năng mà Flux sử dụng đăng ký gọi lại.

Không có sự khác biệt cơ bản trong Redux, nhưng tôi thấy nó làm cho một số trừu tượng hóa dễ dàng hơn, hoặc ít nhất có thể thực hiện, điều đó sẽ khó hoặc không thể thực hiện trong Flux.

Giảm thành phần

Lấy ví dụ, phân trang. Của tôi Ví dụ về Flux + React Router xử lý phân trang, nhưng mã cho điều đó thật khủng khiếp. Một trong những lý do nó khủng khiếp là Thông lượng làm cho nó không tự nhiên để tái sử dụng chức năng trên các cửa hàng. Nếu hai cửa hàng cần xử lý phân trang để đáp ứng với các hành động khác nhau, họ cần phải kế thừa từ một kho lưu trữ cơ sở chung (xấu! Bạn đang khóa mình vào một thiết kế cụ thể khi bạn sử dụng kế thừa) hoặc gọi hàm từ trình xử lý sẽ cần phải bằng cách nào đó hoạt động trên trạng thái riêng của cửa hàng Flux. Toàn bộ điều là lộn xộn (mặc dù chắc chắn trong lĩnh vực có thể).

Mặt khác, với việc phân trang Redux là nhờ vào thành phần giảm tốc. Nó giảm tất cả các con đường xuống, vì vậy bạn có thể viết một nhà máy giảm tốc tạo bộ giảm phân trang và sau đó sử dụng nó trong cây giảm tốc của bạn. Chìa khóa cho lý do tại sao nó dễ dàng như vậy là bởi vì trong Flux, các cửa hàng đều bằng phẳng, nhưng trong Redux, các bộ giảm có thể được lồng nhau thông qua thành phần chức năng, giống như các thành phần React có thể được lồng vào nhau.

Mẫu này cũng cho phép các tính năng tuyệt vời như không có mã người dùng hoàn tác / làm lại. Bạn có thể tưởng tượng việc cắm Undo / Redo vào một ứng dụng Flux là hai dòng mã không? Khó khăn. Với Redux, nó là—Nhận được, nhờ vào mô hình thành phần giảm tốc. Tôi cần làm nổi bật không có gì mới về nó - đây là mô hình tiên phong và được mô tả chi tiết trong Kiến trúc Elm mà chính nó đã bị ảnh hưởng bởi Flux.

Server Rendering

Mọi người đã được dựng hình trên máy chủ tốt với Flux, nhưng thấy rằng chúng tôi có 20 thư viện Flux mỗi cố gắng để làm cho máy chủ rendering "dễ dàng hơn", có lẽ Flux có một số cạnh thô trên máy chủ. Sự thật là Facebook không thực hiện nhiều kết xuất máy chủ, vì vậy họ không quan tâm lắm đến nó, và dựa vào hệ sinh thái để làm cho nó dễ dàng hơn.

Trong truyền thống, cửa hàng là những người độc thân. Điều này có nghĩa là khó phân tách dữ liệu cho các yêu cầu khác nhau trên máy chủ. Không phải là không thể, nhưng khó. Đây là lý do tại sao hầu hết các thư viện Flux (cũng như các thư viện mới) Flux Utils) bây giờ đề nghị bạn sử dụng các lớp thay vì singletons, vì vậy bạn có thể khởi tạo các cửa hàng theo yêu cầu.

Vẫn còn những vấn đề sau đây mà bạn cần phải giải quyết trong Flux (hoặc là chính bạn hoặc với sự trợ giúp của thư viện Flux yêu thích của bạn chẳng hạn như Flummox hoặc là Alt):

  • Nếu cửa hàng là các lớp học, làm cách nào để tạo và tiêu diệt chúng bằng điều phối viên theo yêu cầu? Khi nào tôi đăng ký cửa hàng?
  • Làm thế nào để tôi hydrate dữ liệu từ các cửa hàng và sau đó rehydrate nó trên máy khách? Tôi có cần triển khai các phương pháp đặc biệt cho việc này không?

Phải thừa nhận rằng các khung công tác Flux (không phải là vanilla Flux) có các giải pháp cho những vấn đề này, nhưng tôi thấy chúng quá phức tạp. Ví dụ, Flummox yêu cầu bạn triển khai serialize() và deserialize() trong cửa hàng của bạn. Alt giải quyết điều này đẹp hơn bằng cách cung cấp takeSnapshot() tự động tuần tự hóa trạng thái của bạn trong cây JSON.

Redux chỉ đi xa hơn: vì chỉ có một cửa hàng duy nhất (được quản lý bởi nhiều bộ giảm tốc), bạn không cần bất kỳ API đặc biệt nào để quản lý (hydrat hóa) lại. Bạn không cần phải "tuôn ra" hoặc "hydrate" cửa hàng - chỉ có một cửa hàng duy nhất, và bạn có thể đọc trạng thái hiện tại của nó, hoặc tạo ra một cửa hàng mới với một trạng thái mới. Mỗi yêu cầu nhận được một cá thể cửa hàng riêng biệt. Đọc thêm về dựng hình máy chủ với Redux.

Một lần nữa, đây là một trường hợp có thể có trong cả Flux và Redux, nhưng các thư viện Flux giải quyết vấn đề này bằng cách giới thiệu một tấn API và các quy ước, và Redux thậm chí không phải giải quyết nó bởi vì nó không có vấn đề trong vị trí đầu tiên nhờ sự đơn giản về khái niệm.

Trải nghiệm nhà phát triển

Tôi đã không thực sự có ý định Redux trở thành một thư viện thông dụng phổ biến - tôi đã viết nó khi tôi đang làm việc trên ReactEurope nói chuyện về tải lại nóng với thời gian du lịch. Tôi có một mục tiêu chính: làm cho nó có thể thay đổi mã giảm tốc trên bay hoặc thậm chí "thay đổi quá khứ" bằng cách vượt qua hành động, và xem trạng thái được tính toán lại.

Tôi đã không nhìn thấy một thư viện Flux duy nhất mà có thể làm điều này. React Hot Loader cũng không cho phép bạn làm điều này - trên thực tế nó sẽ bị hỏng nếu bạn chỉnh sửa các cửa hàng Flux vì nó không biết phải làm gì với chúng.

Khi Redux cần tải lại mã giảm tốc, nó gọi replaceReducer()và ứng dụng chạy với mã mới. Trong Flux, dữ liệu và các hàm bị vướng vào các cửa hàng Flux, vì vậy bạn không thể “chỉ thay thế các hàm”. Hơn nữa, bạn phải bằng cách nào đó đăng ký lại các phiên bản mới với Dispatcher — thứ mà Redux thậm chí không có.

Hệ sinh thái

Redux có một hệ sinh thái phong phú và phát triển nhanh. Điều này là do nó cung cấp một vài điểm mở rộng như middleware. Nó được thiết kế với các trường hợp sử dụng như khai thác gỗ, hỗ trợ cho Hứa hẹn, Quan sát được, định tuyến, kiểm tra bất biến, kiên trì, vv, trong tâm trí. Không phải tất cả những điều này sẽ trở nên hữu ích, nhưng thật tuyệt khi có quyền truy cập vào một bộ công cụ có thể dễ dàng kết hợp để hoạt động cùng nhau.

Sự đơn giản

Redux bảo toàn mọi lợi ích của Flux (ghi và phát lại các hành động, luồng dữ liệu một chiều, đột biến phụ thuộc) và thêm các lợi ích mới (dễ dàng hoàn tác, tải lại nóng) mà không cần giới thiệu Dispatcher và đăng ký lưu trữ.

Việc giữ cho nó đơn giản là quan trọng bởi vì nó giữ cho bạn lành mạnh trong khi bạn thực hiện các trừu tượng mức cao hơn.

Không giống như hầu hết các thư viện Flux, bề mặt API Redux rất nhỏ. Nếu bạn xóa cảnh báo, nhận xét và kiểm tra sự phát triển của nhà phát triển, đó là 99 dòng. Không có mã async phức tạp để gỡ lỗi.

Bạn thực sự có thể đọc nó và hiểu tất cả các Redux.


Xem thêm câu trả lời của tôi về nhược điểm của việc sử dụng Redux so với Flux.


1807
2017-10-03 08:26



cảm ơn cho câu trả lời ... Tôi mới để js..in câu trả lời của bạn bạn đã nói thông là sử dụng mẫu thiết kế singleton ... bạn có thể cho tôi biết trong redux loại mô hình thiết kế mà họ đang sử dụng ... và thông lượng có thể bạn cho tôi biết nơi họ đang sử dụng mẫu đơn ... bạn có thể đưa ra cả hai ví dụ ... Tôi hiểu mô hình thiết kế từ đây là gì singleton
Tôi bắt đầu triển khai Android / Java (Fluxxan) dựa trên Fluxxor (về cơ bản là thông lượng thuần túy). Một khi tôi nhìn thấy redux, tôi đã được bán. Có một số phần tôi giữ hoàn toàn flux tho nhưng người đàn ông, lib của bạn là tuyệt vời! - frostymarvelous
Bạn có muốn học Redux không? chỉ xem video này: youtube.com/watch?v=ucd5x3Ka3gw - gsalgadotoledo
Chúng tôi đã chọn redux là của nó được cách nhiều hơn ý kiến ​​hơn thông lượng. Chúng tôi đã liên tục chiến đấu về cách thức / nơi một số mã nên đi, vv Redux loại bỏ tất cả sự nhầm lẫn đó cho chúng tôi. Chúng tôi đã xây dựng ứng dụng với thông lượng cho web và phản ứng bản địa và thật tuyệt vời !! - SomethingOn
Dan is always on point Abramov !! cảm ơn vì lời giải thích này - cabolanoz


Ở Quora, ai đó nói: 

Trước hết, hoàn toàn có thể viết các ứng dụng với React mà không   Tuôn ra.

Ngoài ra điều này sơ đồ trực quan mà tôi đã tạo cho thấy một cái nhìn nhanh chóng của cả hai, có lẽ là một câu trả lời nhanh cho những người không muốn đọc toàn bộ lời giải thích: Flux vs Redux

Nhưng nếu bạn vẫn quan tâm biết nhiều hơn, hãy đọc tiếp.

Tôi tin rằng bạn nên bắt đầu với React tinh khiết, sau đó học Redux và Flux.   Sau khi bạn sẽ có một số kinh nghiệm REAL với React, bạn sẽ thấy   liệu Redux có hữu ích cho bạn hay không.

Có lẽ bạn sẽ cảm thấy rằng Redux chính xác cho ứng dụng của bạn và có thể bạn   sẽ tìm ra, rằng Redux đang cố gắng giải quyết một vấn đề mà bạn không   thực sự trải nghiệm.

Nếu bạn bắt đầu trực tiếp với Redux, bạn có thể kết thúc với quá trình thiết kế   mã, mã khó khăn hơn để duy trì và thậm chí nhiều lỗi hơn và không có   Redux.

Từ Tài liệu Redux:

Động lực 
 Do các yêu cầu đối với các ứng dụng một trang JavaScript ngày càng trở nên phức tạp, chúng tôi   mã phải quản lý nhiều trạng thái hơn bao giờ hết. Tiểu bang này có thể bao gồm   phản hồi của máy chủ và dữ liệu được lưu trong bộ nhớ cache, cũng như dữ liệu được tạo cục bộ   vẫn chưa được tiếp tục với máy chủ. Trạng thái giao diện người dùng cũng tăng   phức tạp, vì chúng tôi cần quản lý các tuyến đường đang hoạt động, các tab được chọn,   spinners, điều khiển pagination, v.v.

Quản lý trạng thái luôn thay đổi này là khó khăn. Nếu một mô hình có thể cập nhật   một mô hình khác, khi đó một lượt xem có thể cập nhật một mô hình, cập nhật một mô hình khác   và lần lượt, điều này có thể khiến một lượt xem khác cập nhật. Tại một số   , bạn không còn hiểu điều gì xảy ra trong ứng dụng của mình như bạn có   mất kiểm soát khi nào, tại sao, và trạng thái của nó như thế nào. Khi một hệ thống   mờ đục và không xác định, thật khó để tái tạo lỗi hoặc thêm   Các tính năng mới.

Như thể điều này không đủ tệ, hãy xem xét các yêu cầu mới trở thành   phổ biến trong phát triển sản phẩm front-end. Là nhà phát triển, chúng tôi   dự kiến ​​sẽ xử lý các cập nhật lạc quan, hiển thị phía máy chủ, tìm nạp   dữ liệu trước khi thực hiện quá trình chuyển tuyến, v.v. Chúng tôi tìm thấy chính bản thân mình   cố gắng quản lý sự phức tạp mà chúng tôi chưa bao giờ phải đối phó   trước đây, và chúng tôi chắc chắn đặt câu hỏi: Đã đến lúc bỏ cuộc? Các   câu trả lời là số

Sự phức tạp này khó xử lý khi chúng ta trộn hai khái niệm   rất khó cho tâm trí con người để giải thích: đột biến và   asynchronicity. Tôi gọi họ là Mentos và Coke. Cả hai đều có thể tuyệt vời khi   tách ra, nhưng cùng nhau họ tạo ra một mớ hỗn độn. Thư viện như React   cố gắng giải quyết vấn đề này trong lớp xem bằng cách xóa cả hai   không đồng bộ và thao tác DOM trực tiếp. Tuy nhiên, quản lý trạng thái của   dữ liệu của bạn được để lại cho bạn. Đây là nơi Redux đến.

Theo bước chân của Flux, CQRS và Event Sourcing, Redux   cố gắng làm cho các đột biến trạng thái có thể dự đoán được bằng cách áp đặt một số   các hạn chế về cách thức và thời điểm cập nhật có thể xảy ra. Những hạn chế này   được phản ánh trong ba nguyên tắc của Redux.

Cũng từ Tài liệu Redux:

Khái niệm cốt lõi
 Bản thân Redux rất đơn giản.

Hãy tưởng tượng trạng thái của ứng dụng của bạn được mô tả như một đối tượng đơn giản. Ví dụ,   trạng thái của một ứng dụng cần làm có thể trông giống như sau:

{
  todos: [{
    text: 'Eat food',
    completed: true
  }, {
    text: 'Exercise',
    completed: false
  }],
  visibilityFilter: 'SHOW_COMPLETED'
}

Đối tượng này giống như một "mô hình" ngoại trừ việc không có người định cư. Điều này   để các phần khác nhau của mã không thể thay đổi trạng thái   tùy ý, gây ra lỗi khó tái sản xuất.

Để thay đổi một cái gì đó trong tiểu bang, bạn cần phải gửi một hành động. An   hành động là một đối tượng JavaScript đơn giản (chú ý cách chúng ta không giới thiệu bất kỳ   ma thuật?) mô tả những gì đã xảy ra. Dưới đây là một số ví dụ về hành động:

{ type: 'ADD_TODO', text: 'Go to swimming pool' }
{ type: 'TOGGLE_TODO', index: 1 }
{ type: 'SET_VISIBILITY_FILTER', filter: 'SHOW_ALL' }

Giả dụ rằng mọi thay đổi được mô tả như một hành động cho phép chúng ta có   hiểu rõ những gì đang diễn ra trong ứng dụng. Nếu có gì đó   thay đổi, chúng tôi biết tại sao nó thay đổi. Các hành động giống như đường dẫn của những gì   đã xảy ra. Cuối cùng, để kết hợp trạng thái và hành động với nhau, chúng ta viết   chức năng được gọi là bộ giảm tốc. Một lần nữa, không có gì kỳ diệu về nó - nó chỉ là một   hàm nhận trạng thái và hành động làm đối số và trả về   trạng thái tiếp theo của ứng dụng. Sẽ rất khó để viết một hàm như vậy cho một   ứng dụng lớn, vì vậy chúng tôi viết các chức năng nhỏ hơn quản lý các phần của tiểu bang:

function visibilityFilter(state = 'SHOW_ALL', action) {
  if (action.type === 'SET_VISIBILITY_FILTER') {
    return action.filter;
  } else {
    return state;
  }
}

function todos(state = [], action) {
  switch (action.type) {
  case 'ADD_TODO':
    return state.concat([{ text: action.text, completed: false }]);
  case 'TOGGLE_TODO':
    return state.map((todo, index) =>
      action.index === index ?
        { text: todo.text, completed: !todo.completed } :
        todo
   )
  default:
    return state;
  }
}

Và chúng tôi viết một trình giảm tốc khác quản lý trạng thái hoàn chỉnh của   ứng dụng bằng cách gọi hai bộ giảm tốc đó cho các khóa trạng thái tương ứng:

function todoApp(state = {}, action) {
  return {
    todos: todos(state.todos, action),
    visibilityFilter: visibilityFilter(state.visibilityFilter, action)
  };
}

Đây là cơ bản toàn bộ ý tưởng của Redux. Lưu ý rằng chúng tôi chưa sử dụng   bất kỳ API Redux nào. Nó đi kèm với một vài tiện ích để tạo điều kiện thuận lợi cho việc này   mô hình, nhưng ý tưởng chính là bạn mô tả trạng thái của bạn   được cập nhật theo thời gian để phản hồi đối tượng hành động và 90% mã   bạn viết chỉ đơn giản là JavaScript, không sử dụng chính Redux,   API, hoặc bất kỳ phép thuật nào.


74
2018-03-22 12:59



Không tệ cho copy-pasta. :) - Léon Pelletier


Bạn có thể bắt đầu tốt nhất với việc đọc bài đăng này bởi Dan Abramov, nơi anh ta thảo luận về các triển khai khác nhau của Flux và sự đánh đổi của họ tại thời điểm anh ta viết redux: Sự tiến hóa của các khung Flux

Thứ hai là trang động lực mà bạn liên kết đến không thực sự thảo luận về động lực của Redux nhiều như động lực đằng sau Flux (và React). Các Ba nguyên tắc là nhiều hơn Redux cụ thể mặc dù vẫn không đối phó với sự khác biệt thực hiện từ kiến ​​trúc Flux tiêu chuẩn.

Về cơ bản, Flux có nhiều cửa hàng tính toán thay đổi trạng thái để đáp ứng với tương tác UI / API với các thành phần và phát những thay đổi này dưới dạng sự kiện mà các thành phần có thể đăng ký. Trong Redux, chỉ có một cửa hàng mà mọi thành phần đăng ký. IMO cảm thấy ít nhất như Redux tiếp tục đơn giản hóa và thống nhất luồng dữ liệu bằng cách hợp nhất (hoặc giảm, như Redux sẽ nói) luồng dữ liệu quay trở lại các thành phần - trong khi Flux tập trung vào việc hợp nhất phía bên kia của luồng dữ liệu - mô hình.


50
2017-09-23 14:51





Tôi là người nhận con nuôi sớm và đã triển khai một ứng dụng đơn lớn ở giữa bằng cách sử dụng thư viện Facebook Flux.

Khi tôi hơi muộn để nói chuyện, tôi sẽ chỉ ra rằng mặc dù tôi hy vọng tốt nhất Facebook dường như xem xét việc thực hiện Flux của họ là một bằng chứng về khái niệm và nó chưa bao giờ nhận được sự chú ý nó xứng đáng.

Tôi muốn khuyến khích bạn chơi với nó, vì nó cho thấy nhiều công việc bên trong của kiến ​​trúc Flux khá giáo dục, nhưng đồng thời nó không cung cấp nhiều lợi ích mà các thư viện như Redux cung cấp (không phải điều đó quan trọng đối với các dự án nhỏ, nhưng trở nên rất có giá trị đối với các dự án lớn hơn).

Chúng tôi đã quyết định tiến lên phía trước, chúng tôi sẽ chuyển sang Redux và tôi khuyên bạn nên làm như vậy;)


22
2018-01-05 13:45



Tôi đã phát triển ứng dụng Facebook Flux trong sáu tháng. Và tôi vẫn không chắc liệu thời gian di chuyển có xứng đáng với những lợi ích mà Redux cung cấp hay không. Tôi sẽ đánh giá cao tất cả các ý kiến ​​của bạn về ưu / nhược điểm của Redux trên FB thông lượng! - Volodymyr Bakhmatiuk
@VolodymyrBakhmatiuk cho chúng tôi, chủ yếu là giảm số lượng boilerplate chúng ta phải viết + xử lý lỗi tốt hơn (redux sẽ hét lên nếu bạn kích hoạt một hành động không được định nghĩa trong danh sách liên tục của bạn - FB sẽ không và nó có thể gây ra tất cả các loại vấn đề) Có một vài khả năng nâng cao hơn trong thông lượng, nhưng tôi chưa sử dụng chúng - Guy Nesher
@GuyNesher một hành động không xác định phải được phát hiện tại thời gian biên dịch, không phải lúc chạy. Flow (một đóng góp Facebook khác) cho phép bạn làm điều đó. - Dominique PERETTI
@DominiquePERETTI - đúng (cũng có thể sử dụng linting) nhưng nó không thay đổi thực tế là không bắt lỗi trong thời gian chạy là kinda buồn - Guy Nesher
Tôi đã viết một vài người trợ giúp đơn giản để xử lý FBFlux, và nó thực sự có vẻ là ít hơn soạn thảo và thiết lập ứng dụng hơn tất cả các ứng dụng Redux mẫu mà tôi đã tìm thấy. Làm việc trên một ứng dụng trong hơn 9 tháng qua giữa hai nhà phát triển và không bao giờ có bất kỳ vấn đề gì với kiến ​​trúc. - rob2d


Đây là lời giải thích đơn giản của Redux trên Flux. Redux không có dispatcher.It dựa trên các hàm thuần túy được gọi là reducers. Nó không cần một người điều phối. Mỗi hành động được xử lý bởi một hoặc nhiều bộ giảm tốc để cập nhật một cửa hàng. Vì dữ liệu không thay đổi, các trình giảm sẽ trả về trạng thái cập nhật mới cập nhật cửa hàngenter image description here

Để biết thêm thông tin http://www.prathapkudupublog.com/2017/04/flux-vs-redux.html


13
2018-04-18 14:27





Tôi đã làm việc khá lâu với Flux và giờ đã khá lâu khi sử dụng Redux. Như Dan đã chỉ ra cả hai kiến ​​trúc không quá khác biệt. Vấn đề là Redux làm cho mọi việc đơn giản và rõ ràng hơn. Nó dạy cho bạn một vài điều trên đầu trang của Flux. Ví dụ như Flux là một ví dụ hoàn hảo về luồng dữ liệu một chiều. Tách các mối quan tâm mà chúng tôi có dữ liệu, thao tác của nó và xem lớp tách ra. Trong Redux chúng ta có những điều tương tự nhưng chúng ta cũng tìm hiểu về tính bất biến và các chức năng thuần túy.


2
2018-01-25 12:26





Tuôn ra là một mô hình và Redux là một thư viện.

Flux là một cái tên ưa thích cho mẫu người quan sát đã sửa đổi một chút để phù hợp với React, nhưng Facebook đã phát hành một vài công cụ để hỗ trợ trong việc thực hiện mẫu Flux, vì vậy sau đây là sự khác biệt giữa việc sử dụng các công cụ này (thường được gọi là Flux) ) và sử dụng Redux.

Cả Flux và Redux đều có các hành động. Các hành động có thể được so sánh với các sự kiện (hoặc sự kiện kích hoạt). Trong Flux, một hành động là một đối tượng JavaScript đơn giản và đó cũng là trường hợp mặc định trong Redux, nhưng khi sử dụng phần mềm trung gian Redux, các hành động cũng có thể là các hàm và lời hứa.

Với Flux nó là một quy ước để có nhiều cửa hàng cho mỗi ứng dụng; mỗi cửa hàng là một đối tượng đơn lẻ. Trong Redux, quy ước là có một cửa hàng cho mỗi ứng dụng, thường được chia thành các miền dữ liệu nội bộ (bạn có thể tạo nhiều hơn một kho lưu trữ Redux nếu cần cho các tình huống phức tạp hơn).

Thông lượng có một điều phối viên duy nhất và tất cả các hành động phải đi qua điều phối viên đó. Đó là một vật thể đơn. Một ứng dụng Flux không thể có nhiều điều phối viên. Điều này là cần thiết vì một ứng dụng Flux có thể có nhiều cửa hàng và sự phụ thuộc giữa các cửa hàng đó cần một người quản lý duy nhất, đó là người điều phối.

Redux không có thực thể điều phối. Thay vào đó, cửa hàng có quá trình gửi đi. Một cửa hàng Redux trưng ra một vài hàm API đơn giản, một trong số đó là gửi các hành động.

Trong Flux, logic của việc cần làm trên dữ liệu dựa trên hành động nhận được được viết trong chính kho đó. Cửa hàng cũng có tính linh hoạt của các phần dữ liệu để hiển thị công khai. Người chơi thông minh nhất trong ứng dụng Flux là cửa hàng.

Trong Redux, logic của việc cần làm trên dữ liệu dựa trên các hành động nhận được là trong hàm giảm tốc được gọi cho mọi hành động được gửi đi (thông qua API cửa hàng). Không thể xác định một cửa hàng mà không có chức năng giảm tốc. Redux reducer là một hàm đơn giản nhận trạng thái trước đó và một hành động, và nó trả về trạng thái mới dựa trên hành động đó. Trong một ứng dụng Redux, bạn có thể chia bộ giảm tốc của bạn thành các chức năng đơn giản như bạn sẽ làm với bất kỳ chức năng nào khác. Trình chơi thông minh nhất trong Redux là bộ giảm tốc.

Trong Redux, ngoài ra, không có nhiều linh hoạt về những gì phơi bày như trạng thái của cửa hàng. Redux sẽ chỉ phơi bày bất kỳ thứ gì được trả lại từ bộ giảm tốc của cửa hàng. Đây là một ràng buộc.

Hạn chế lớn hơn khác là trạng thái của cửa hàng không thể thay đổi được (hoặc thực sự, không nên). Không có ràng buộc như vậy trong Flux, bạn có thể thay đổi trạng thái như bạn muốn. Sự bất biến của nhà nước, trong Redux, đạt được một cách dễ dàng bằng cách làm giảm các hàm thuần túy (không có tác dụng phụ). Trình giảm tốc Redux luôn sao chép trạng thái mà chúng nhận và trả về phiên bản sửa đổi của bản sao của tiểu bang, không phải bản gốc đối tượng gốc. Trong khi đây là một hạn chế lớn, nó làm cho cuộc sống dễ dàng hơn nhiều trong dài hạn.


0
2018-06-24 07:13