Niedawno otrzymaliśmy React w naszej firmie jako technologię front-end do budowy naszej ogromnej aplikacji internetowej firmy. Mówiąc ostatnio, mam na myśli, że nie mamy żadnego wcześniejszego doświadczenia z Reactem (mamy ogromne doświadczenie w AngularJS), a mówiąc o ogromnej aplikacji, mam na myśli to, że jest naprawdę ogromna i bardzo dynamiczna z wieloma różnymi elementami i funkcjonalnością.React architektura dla ogromnej aplikacji biznesowej
Ponieważ będziemy mieli wiele ogromnych komponentów, które odgrywają bardzo ważną rolę i mają w sobie złożoną logikę, a ponieważ chcemy, aby były łatwe do podłączenia i wielokrotnego użytku, chcemy, aby były jak najbardziej odizolowane od poza światem i innymi częściami naszej aplikacji, ponieważ w przeciwnym razie ze względu na ich rozmiar i złożoną funkcjonalność byłoby praktycznie niemożliwe ich opracowanie i utrzymanie. Z tego powodu zdecydowaliśmy, że NIE będziemy używać Redux, przynajmniej na początku, podczas gdy opracowujemy same oddzielne komponenty, ponieważ kompromituje to izolację komponentów i sprawia, że cała logika przepływu danych aplikacji jest niemożliwa do zrozumienia, gdy jest tak wiele złożonych składniki. Chociaż uważam, że nasz wybór może być błędny, ponieważ, jak już wspomniałem, nie mamy doświadczenia z React.
Jak już wspomniałem, aplikacja jest bardzo dynamiczna. Rozumiem przez to, że komponenty są faktycznie renderowane przez dane. Używamy różnych klas dostawców konfiguracji, które współdziałają z punktami końcowymi API, aby pobrać elementy konfiguracji naszej aplikacji, takie jak konfiguracje nawigacji, strony, różne formularze, listy itp., A następnie spróbować renderować komponenty, które są odczytywane z tej konfiguracji.
Problem polega na tym, że po kilku tygodniach zmagań z Reactem i znalezienia właściwych wzorów i wspólnych rozwiązań naszych problemów, rozmawialiśmy w naszej ekipie, że być może React nie jest odpowiednią technologią dla nas, ponieważ jest to biblioteka UI, nie wydarzenie jest ramą i nie pomaga nam to bardzo, ale po prostu dodaje reguły renderowania, które musimy czasem łamać, aby osiągnąć pożądaną dynamikę i niezależność od komponentów.
Zważywszy na izolację komponentów i zarządzanie przepływem danych, osobiście słyszałem, że istnieje język dla front-endowego Wiązu rozwojowego, który ma dość solidną architekturę przepływu danych, gdzie każdy komponent ma swój własny model, który jest oddzielony od innych, ale ja nie wiem, czy warto spróbować, bo wkrótce może to również stać w tyle za naszymi dużymi wymaganiami.
Powodem, dla którego piszę to pytanie, jest to, że mam nadzieję uzyskać wgląd od ludzi, którzy mają solidne doświadczenie w pracy z dużymi aplikacjami front-end. Chciałbym wiedzieć, czy możliwe jest opracowanie takiej aplikacji za pomocą React, czy React nadaje się do takiej złożoności i dynamiki, czy naprawdę potrzebujemy Redux, czy czegoś innego, jaką ścieżkę, praktyki, ideologie powinniśmy przestrzegać. Jeśli dobrze zrozumiałeś moje pytanie, to bardziej strona architektury, z którą walczymy, niż technologia. Może po prostu kroczymy ścieżką, która prowadzi do coraz większej walki i złożoności, ale nie do produkcji.
Dobrze jest wiedzieć, że ktoś tu już wiemy co przechodzisz. Mówiąc o 'Redux', próbowałem napisać z nim dynamiczny komponent formularza i bardzo szybko się pomyliłem, kiedy musiałem wprowadzić konfigurację i dane do stanu z różnych źródeł, a następnie poprawnie renderować formularz i synchronizować jego różne części. . Następnie część sprawdzania poprawności również została uruchomiona, a następnie zmienne tworzą typy pól, takie jak autouzupełnianie, które ładuje wybory z internetowego interfejsu API. Nadal jednak uważam, że zamieszanie mogło być spowodowane brakiem doświadczenia i znajomością biblioteki/frameworka. – Salivan