There is an admin site written in plain HTML / CSS / JS (jQuery) - i.e. this is not a SPA, server-side rendering in plain HTML and then connecting JS (jQuery) to the DOM on the client side, as in the good old days.

Many admin pages suit me in this design (namely, in development speed, where highly interactive interfaces are not required), but here is a page where you need to do something with highly interactive interfaces, for example, a table with a group tree, filtering, sorting and other things and I would like to implement this table on React components.

That's actually the question, “will it be / is it convenient / will this practice be practiced” to implement only this page on React components (with Flux or Redux, Routing, maybe with something else, I’m just not good at React) considering the fact that the entire admin is not a SPA? Those. As far as I understand, only for this page will I need to implement the REST API on the server side and interact with it on the client side React components, or it may be something else, and maybe this is not practiced at all and this is a bad decision?

    2 answers 2

    Yes, such a solution is possible, and is used quite often. At least I have met several times. The disadvantage of this approach is the need to load additional javascript libraries, react, redux itself, and so on. Although if this is for admin, then there should not be a problem.

      This is a very frequent decision, this happens very often. Yes, of course, no one can forbid you to do so! And yes, this is a fairly convenient approach for embedding gadgets into a traditional website.

      From the subtleties of implementation - immediately throw away Flux, Redux or any other routing. They are needed only in the "real" SPA, for one page in a multi-page site they are redundant. Clean React is perfect for you.

      Also take care of correctly caching your scripts on the browser side. I know that the advice is trivial - but it is with such an approach (multipage application + heavy client side) that optimal loading of client scripts is very important.

      Regarding the REST API - a strange question. If you need interactive interaction with the server, then the API will of course be needed. If not, then it will not be needed.

      An example of when an API is needed is managing the user and group tree. An example of when the API is not needed is a beautiful view of the same tree, without editing.

      • At the expense of throwing routing, I can still agree, but about throwing Redux (Flux), I would argue. Redux and Flux are not routing. - Mikhail Chibel
      • @MikhailChibel there is still excessive there. Although, I agree, they may find some use. - Pavel Mayorov
      • one
        > from implementation subtleties - immediately discard Flux, Redux or any other routing. Yes, I just wanted to say that Flux and Redux are not routing .. And about routing, how can I communicate with the server without it, via jQuery $ .get (), $ .post (), $ .ajax ()? - Alexander
      • Flux and Redux are not routing. As a result, their necessity is determined solely by the logic of building a "mini-application" and data exchange with the server. Immediately chop from the shoulder and dismiss these solutions (without assessing their applicability) does not make sense. - Dmitriy Simushev
      • 2
        @PavelMayorov please polifil - github.com/github/fetch - Vasily Barbashev