Why is Reactjs not suitable for complex front-end projects?

Problem One: Reactjs components are difficult to reuse in complex interactive pages

The smallest unit of reuse in a Reactjs is a component. Reactjs components are lighter than ANGULARJS controllers and view. Each component requires only the front-end developer to provide a render function that props maps and map to a state Web page element.

Such lightweight components work well when rendering simple static pages, but if the page interacts, you must pass a callback function between the components to handle the event.

I will be in the more than React (ii) components harmful to reusability? Uses native DHTML APIs, Reactjs, and Binding.scala to implement the same page that needs to be reused, and describes how the Binding.scala is simple to implement and reuse complex interactive logic.

Question two: Reactjs's virtual DOM algorithm is slow and not allowed

Reactjs's page rendering algorithm is a virtual DOM difference algorithm.

Developers need to provide render functions that are based on props and state generate virtual DOM. The REACTJS framework then render creates a true dom of the same structure based on the returned virtual DOM.

Whenever state the change occurs, the REACJS framework calls the render function back to get the new virtual DOM. The framework then compares the differences between the last generated virtual DOM and the new virtual DOM, and then applies the differences to the real DOM.

There are two major drawbacks to this:

1. Each time a change is made state , the render function generates a complete virtual DOM. Even if state the changes are small, the render function will be fully computed again. If the render functions are complex, this process wastes a lot of computational resources.
2. The REACTJS framework compares virtual DOM differences in a slow and error-prone way. For example, if you want to <ul> insert an item at the top of a list <li> , the REACTJS framework mistakenly thinks that you have modified <ul> each item and <li> then inserts one at the end <li> .

This is because the new and old virtual Dom received by Reactjs is independent of each other, and Reactjs does not know what is happening with the data source and can only guess what needs to be done based on the new and old two virtual DOM. The automatic guessing algorithm is neither slow nor easy, and the front-end developers must manually provide key properties, shouldComponentUpdate methods, componentDidUpdate methods, or componentWillUpdate other methods to help the Reactjs frame guess.

I will be in the more than React (iii) Virtual DOM is dead? In comparison with Reactjs, Angularjs and Binding.scala rendering mechanism, this paper introduces the Binding.scala accurate data binding mechanism with high simple performance.

Problem three: Reactjs HTML templates are neither complete nor robust

Reactjs supports writing HTML templates with jsx.

In theory, front-end engineers simply copy the static HTML prototype into the JSX source file, adding some variable substitution code, which can be changed to create dynamic pages. Theoretically, this is more appropriate than Cycle.js, Widok, Scalatags and other frameworks for reusing designer-provided HTML prototypes.

Unfortunately, Reactjs's support for HTML is incomplete. The developer must manually class replace the attributes with the for className and htmlFor , and then change the inline style style from CSS syntax to JSON syntax for the code to run. In this way, front-end engineers can copy and paste HTML prototypes into the code, but they need a lot of modification to actually run. Not much more than cycle.js, Widok, or scalatags.

In addition, REACTJS provides a propTypes mechanism for verifying the legitimacy of virtual DOM. However, this mechanism is also flawed. Even if specified propTypes , Reactjs cannot detect errors early in the compilation. Only projects with high test coverage can be validated when each component uses a different component. Even if the test coverage is high, propTypes still can not detect the misspelled attribute name, if you onClick write onclick , Reactjs will not error, often lead developers to spend a lot of time to troubleshoot a very simple bug.

I will be in "more than React (d) HTML can also be compiled?" Compares the HTML templates of Reactjs and Binding.scala, and describes how Binding.scala can still check for syntax errors and semantic errors while fully supporting XHTML syntax.

Issue four: REACTJS requires complex asynchronous programming when communicating with a server

Reactjs the schema when loading data from the server can be seen as MVVM (Model–view–viewmodel) mode. Front-end engineers need to write a database access layer as the model, the Reactjs as a state viewmodel, and as a render view. The Model is responsible for accessing the database and setting the data to state (that is, the view Model), which can be implemented using the promise and fetch APIs. Then, the render view, is responsible for rendering the view model onto the page.

In this entire process, the front-end programmer needs to write a large number of closure of the asynchronous process, set up, access to the state code 504 scattered, accidentally will be bug-clustered, even if the careful handling of various asynchronous events, will also lead to the program becomes complex, difficult to debug, and difficult to maintain.

Why is Reactjs not suitable for complex front-end projects?