Earlier quoted context omitted.
Which ways are those?
- It "calls you" (i.e. you never explicitly call your React components, React does) - It permeates your codebase (e.g. migration from moment to date-fns is something you can realistically do piecemeal, React to Vue or vice versa not so much) - It enforces a specific architectural paradigm (components) to the exclusion of others (e.g. MVC, MVVM, etc) - Its direct competitors are frameworks (Angular, Vue, Backbone, Aur…
It "calls you" (i.e. you never explicitly call your React components, React does)
The starting point for doing anything with React is where you call it to render a certain component at a certain point in your document. There are things built on top of React, such as Next.js, that add more layers and do follow more of a framework design, but even there they are still calling React when they need to rather than the other way around.
It’s true that React provides features can automatically trigger a rerender later on. You don’t have to use any of those, though.
There are also integrations with many other libraries, such as those for managing state in one way or another, where the library can trigger rerendering of specific React components when relevant state changes. In this case, it’s the library calling React rather than React calling out.
Another alternative is the original React “philosophy”, simply rerendering the entire tree whenever you need to and letting the VDOM mechanism and perhaps a few helping hands that avoid unnecessary rerenders in your components keep this reasonably efficient. When to call into React for a rerender is entirely your own choice.
I suppose you could argue that React operates somewhat like a framework because it calls the render function for each component, but to me this is more analogous to a generic sorting algorithm that calls a comparison function I pass in when it needs to. It still doesn’t do anything until I call `sort`, and the code I write is still what decides the overall control flow for the program.
It permeates your codebase (e.g. migration from moment to date-fns is something you can realistically do piecemeal, React to Vue or vice versa not so much)
It is possible to use React only as a convenient rendering library and keep other responsibilities like state management and communications separate, just like any other software.
Some people choose not to do that and instead write React components that manage state and call remote APIs and cook you breakfast in the morning. Whether this strategy is wise is a different question.
I’m working on a new front-end using React right now, and even at an early stage when presentation code is a large part of what has been written so far, maybe 1/3 of the code even knows React exists. I’ll be surprised if that figure is even 20% by the time we launch. Even now, we could drop React tomorrow in favour of any other rendering code, and nothing would need to change in the code that handles our data model, diagram layouts, communications with our back-end APIs, etc.
It enforces a specific architectural paradigm (components) to the exclusion of others (e.g. MVC, MVVM, etc)
Components are just a way to build a rendering hierarchy: data in, DOM out. Nothing about that forces you to adopt any specific architecture in the rest of your application. Again, some people do choose to put other responsibilities within their components, even using React components to model non-presentational aspects so almost their entire front-end architecture becomes one big tree of React components, but you don’t have to do this and then deal with all the problems it potentially creates that you didn’t otherwise have.