Tại sao nên sử dụng Redux trên Facebook Flux? [đóng cửa]

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

Theo tôi hiểu, các động lực tài liệu redux chính thức cung cấp ưu điểm so với các 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 và không chức năng? Hoặc câu hỏi là trong các khả năng / công cụ phát triển theo phương pháp tiếp cận? Có thể nhân rộng? Hay 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 độ phức tạp của các điểm động lực của redux khi thực hiện trên thông lượng so với redux.

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

1. Xử lý các cập nhật lạc quan ( theo tôi hiểu, 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 không? )
2. Kết xuất trên máy chủ ( thông lượng facebook 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 không thể đạt được thông lượng trên facebook? Lợi ích là gì? )
4. Tải lại nóng ( Có thể với React Hot Tải lại . Tại sao chúng ta cần redux? )
5. Hoàn tác / Làm lại chức năng
6. Còn điểm nào khác không? Giống như trạng thái dai dẳng ...

Redux tác giả ở đây!

Redux không phải là rằng khác với Flux. Nhìn chung, nó có cùng kiến ​​trúc, nhưng Redux có thể cắt giảm một số góc phức tạp bằng cách sử dụng thành phần chức năng trong đó 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 việc trừu tượng hóa trở nên dễ dàng hơn, hoặc ít nhất là có thể thực hiện, điều đó sẽ khó hoặc không thể thực hiện trong Flux.

Thành phần giảm tốc

Lấy ví dụ, phân trang. Ví dụ Flux + React Router của tôi xử lý phân trang, nhưng mã cho điều đó thật tồi tệ. Một trong những lý do khủng khiếp là Flux khiến việc sử dụng lại chức năng trên các cửa hàng trở nên không tự nhiên. 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, thì chúng cần phải kế thừa từ một cửa hàng cơ sở chung (xấu! Bạn tự 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 một chức năng được xác định bên ngoài từ bên trong xử lý sự kiện, sẽ cần bằng cách nào đó hoạt động trên trạng thái riêng tư của cửa hàng Flux. Toàn bộ điều này 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 phân trang Redux là tự nhiên nhờ thành phần giảm tốc. Đó là bộ giảm tốc hoàn toàn, vì vậy bạn có thể viết một nhà máy giảm tốc tạo ra bộ giảm tốc 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 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 tốc có thể được lồ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ư hoàn tác / làm lại mã không sử dụng . 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, đó là Babagain, nhờ mô hình thành phần giảm tốc. Tôi cần nhấn mạnh rằng không có gì mới về nó. Đây là mô hình được tiên phong và mô tả chi tiết trong Elm Architecture , nơi chịu ảnh hưởng của Flux.

Kết xuất máy chủ

Mọi người đã kết xuất 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 lần cố gắng làm cho máy chủ hiển thị 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 đến điều đó và dựa vào hệ sinh thái để làm cho nó dễ dàng hơn.

Trong Flux truyền thống, các cửa hàng là singletons. Đ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ư Flux Utils mới ) hiện khuyên bạn nê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 mà bạn cần giải quyết trong Flux (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 như Flummox hoặc Alt ):

• Nếu các cửa hàng là các lớp, làm cách nào để tạo và hủy chúng với bộ điều phối theo yêu cầu? Khi nào tôi đăng ký cửa hàng?
• Làm cách nào để hydrat hóa dữ liệu từ các cửa hàng và sau đó bù nước cho khách hàng? Tôi có cần phải thực hiện 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 Flux (không phải vanilla Flux) 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 thực hiện serialize()và deserialize()trong các 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ý (tái) hydrat hóa. Bạn không cần phải dọn dẹp các cửa hàng của Argentina và các cửa hàng của Hyd hyd trên 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 một cửa hàng mới với một trạng thái mới. Mỗi yêu cầu được một ví dụ cửa hàng riêng biệt. Đọc thêm về kết xuất máy chủ với Redux.

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

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

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

Tôi chưa thấy một thư viện Flux nào có thể làm điều này. React Hot Loader cũng không cho phép bạn thực hiện đ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ó sẽ gọi replaceReducer()và ứng dụng chạy với mã mới. Trong Flux, dữ liệu và chức năng 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 chức năng. Hơn nữa, bằng cách nào đó bạn phải đăng ký lại các phiên bản mới với Dispatcher, một 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 chóng . Điều này là do nó cung cấp một vài điểm mở rộng như phần mềm trung gian . Nó được thiết kế với các trường hợp sử dụng như ghi nhật ký , hỗ trợ cho Lời hứa , Quan sát , định tuyến , kiểm tra dev bất biến , kiên trì , v.v., trong tâm trí. Không phải tất cả trong số 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 để làm việc cùng nhau.

Sự đơn giản

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

Giữ cho nó đơn giản là rất quan trọng vì nó giúp bạn tỉnh táo trong khi bạn thực hiện các khái niệm trừu tượng ở cấp độ 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ác cảnh báo, nhận xét và kiểm tra độ tỉnh của nhà phát triển, thì đó 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ả về 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 .

Ở Quora, ai đó nói :

Trước hết, hoàn toàn có thể viết ứng dụng bằng React mà không cần Flux.

Ngoài ra sơ đồ trực quan này mà tôi đã tạo để hiển thị một cái nhìn nhanh về 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:

Nhưng nếu bạn vẫn muốn 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 thuần túy, sau đó học Redux và Flux. Sau khi bạn có một số trải nghiệm THỰC SỰ với React, bạn sẽ thấy liệu Redux có hữu ích cho bạn hay không.

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

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

Từ tài liệu Redux :

Động lực
Khi 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, mã của chúng tôi phải quản lý trạng thái nhiều hơn bao giờ hết. Trạng thái 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ộ chưa được duy trì cho máy chủ. Trạng thái UI cũng đang tăng về độ phức tạp, vì chúng ta cần quản lý các tuyến hoạt động, các tab được chọn, spinners, điều khiển phân trang, v.v.

Quản lý nhà nước 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, thì một khung nhìn có thể cập nhật một mô hình, cập nhật một mô hình khác và chính điều này có thể khiến một khung nhìn khác cập nhật. Tại một số điểm, bạn không còn hiểu những gì xảy ra trong ứng dụng của mình vì bạn đã mất quyền kiểm soát thời gian, lý do và trạng thái của nó. 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ở nên 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, kết xuất phía máy chủ, tìm nạp dữ liệu trước khi thực hiện chuyển đổi tuyến đường, v.v. Chúng tôi thấy mình đang cố gắng quản lý một sự phức tạp mà trước đây chúng tôi chưa bao giờ phải đối phó và chúng tôi chắc chắn đặt câu hỏi: Đã đến lúc phải từ bỏ? Câu trả lời là không.

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

Theo bước chân của Flux, CQRS và Tìm nguồn sự kiện, Redux cố gắng tạo ra các đột biến trạng thái có thể dự đoán được bằng cách áp đặt một số hạn chế nhất định 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
Redux tự nó rất đơn giản.

Hãy tưởng tượng trạng thái ứ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 ứng dụng việc cần làm có thể 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ó setters. Điều này là để các phần khác nhau của mã không thể thay đổi trạng thái tùy ý, gây ra các lỗi khó tái tạo.

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

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

Thực thi rằng mọi thay đổi được mô tả là một hành động cho phép chúng tôi hiểu rõ về những gì đang diễn ra trong ứng dụng. Nếu một cái gì đó thay đổi, chúng tôi biết tại sao nó thay đổi. Hành động giống như mẩu bánh mì của những gì đã xảy ra. Cuối cùng, để gắn kết trạng thái và hành động lại với nhau, chúng ta viết một hàm gọi là bộ giảm tốc. Một lần nữa, không có gì kỳ diệu về nó - đó chỉ là một chức năng lấy 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. Thật khó để viết một chức năng 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 trạng thái:

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 bộ giảm tốc khác quản lý trạng thái hoàn chỉnh của ứng dụng của chúng tôi 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 cho mẫu này, nhưng ý tưởng chính là bạn mô tả cách trạng thái của bạn được cập nhật theo thời gian để đáp ứng với các đối tượng hành động và 90% mã bạn viết chỉ là JavaScript đơn giản, không sử dụng Redux chính nó, API của nó, hoặc bất kỳ phép thuật nào.

Bạn có thể bắt đầu tốt nhất với việc đọc bài đăng này của Dan Abramov, nơi ông 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 ông đang viết redux: The Evolution of Flux Frameworks

Thứ hai, 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à 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 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 các tương tác UI / API với các thành phần và phát các thay đổi này dưới dạng các 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 ít nhất cảm thấy như Redux đơn giản hóa và thống nhất luồng dữ liệu bằng cách thống nhất (hoặc giảm, như Redux sẽ nói) luồng dữ liệu trở lại các thành phần - trong khi Flux tập trung vào việc thống nhất phía bên kia của luồng dữ liệu - xem mô hình.

Tôi là người sớm chấp nhận và triển khai một ứng dụng trang đơn cỡ trung bình bằng thư viện Facebook Flux.

Vì tôi hơi trễ cuộc trò chuyện, tôi sẽ chỉ ra rằng mặc dù hy vọng tốt nhất của tôi, Facebook dường như coi việc triển khai 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ú ý.

Tôi khuyến khích bạn chơi với nó, vì nó cho thấy nhiều hoạt động 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 là điều đó quan trọng đối với các dự án nhỏ, nhưng trở nên rất có giá trị cho những dự án lớn hơn).

Chúng tôi đã quyết định rằng tiến về 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;)

Dưới đây là lời giải thích đơn giản về Redux hơn Flux. Redux không có bộ điều phối. Nó phụ thuộc vào các hàm thuần túy gọi là bộ giảm tốc. 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 là bất biến, bộ giảm tốc trả về trạng thái cập nhật mới cập nhật cửa hàng

Để biết thêm thông tin Flux vs Redux

Tôi đã làm việc khá lâu với Flux và bây giờ khá lâu sử dụng Redux. Như Dan đã chỉ ra cả hai kiến ​​trúc không quá khác biệt. Điều này là Redux làm cho mọi thứ đơn giản và sạch sẽ hơn. Nó dạy cho bạn một vài điều trên 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 nơi chúng ta có dữ liệu, các thao tác của nó và lớp xem tách biệt. 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 hàm thuần túy.

Từ một người áp dụng phản ứng / chuyển hướng mới di chuyển từ (một vài năm) ExtJS vào giữa năm 2018:

Sau khi trượt ngược xuống đường cong học tập redux, tôi có cùng một câu hỏi và nghĩ rằng từ thông thuần sẽ đơn giản hơn như OP.

Tôi sớm thấy những lợi ích của việc chuyển hướng qua thông lượng như đã lưu ý trong các câu trả lời ở trên và đã đưa nó vào ứng dụng đầu tiên của tôi.

Trong khi nắm chặt tấm nồi hơi một lần nữa, tôi đã thử một vài libs quản lý nhà nước khác , điều tốt nhất tôi tìm thấy là tái đấu .

Nó trực quan hơn nhiều so với vanilla redux, nó cắt giảm 90% nồi hơi và cắt giảm 75% thời gian tôi dành cho redux (điều mà tôi nghĩ rằng một thư viện nên làm), tôi đã có thể có được một vài ứng dụng doanh nghiệp đi ngay

Nó cũng chạy với công cụ redux tương tự. Đây là một bài viết tốt bao gồm một số lợi ích.

Vì vậy, đối với bất kỳ ai khác đến bài đăng SO này tìm kiếm "redux đơn giản hơn", tôi khuyên bạn nên dùng thử như một cách thay thế đơn giản để chuyển hướng với tất cả các lợi ích và 1/4 của nồi hơi.

Theo bài viết này: https://medium.freecodecamp.org/a-realworld-comparison-of-front-end-frameworks-with-benchmark-2019-update-4be0d3c78075

Bạn nên sử dụng MobX để quản lý dữ liệu trong ứng dụng của mình để có hiệu suất tốt hơn chứ không phải Redux.