Discussion on: Moving away from ReactJs and VueJs on front-end using Clean Architecture

[peerreynders]

In the "Architecture, the lost years" he's talking about MVC (which is an architectural design pattern)

If you had actually watched the video rather than just glanced at the thumbnail you would have realized that MVC was only a minor aside around 29:00 and that he considers MVC a design pattern

MVC is not an architecture

and that he really doesn't like Web MVC.

Aside: MVC: misunderstood for 37 years

He's at a Ruby conference and he's talking about how Rails applications in general don't have an architecture that clearly manifests the nature of the application being implemented other than that they're implemented with Rails.

Similarly many React applications have a "same-ish" structure without a clear demarcation where the UI ends and the application(-logic) begins.

In 2011 SPAs weren't commonplace so client-side architecture wasn't a discussion point (though Martin Fowler brought up Segregated DOM in 2014).

In Make the Magic go away Robert C. Martin even calls rxJava (ReactiveX) a framework which most people would classify as a library. However going "all in" with RX has a framework-like effect on solution architecture.

so let's see which kind of frameworks we can find

Wrong frame.
What are the characteristics that most if not all frameworks share? The key one in Johnson and Foote:

The framework often plays the role of the main program in coordinating and sequencing application activity.

React is invoking your components for the lifetime of the application session so as far as your components are concerned React is their "main program". And the way many if not most React components are authored - i.e. components include a fragment of the application logic - React becomes the "main program" for the entire application.

That being said, lets look at your "Component Framework" write up:

These components are generally thought of as "pluggable" in the sense that the system can be configured with a set of components to accomplish a particular task or set of tasks.

Your React components plug into React

• to render markup in a way that is specific to your application
• to trigger application activities, which in turn may modify component instance state causing React to schedule them for re-render.

The framework, on the other hand, is the invariant "superstructure" that manages the components, providing services to each component that, when combined with the services/behaviours supplied by that component, create the net behaviour defined by that component in that framework.

React definitely manages React components, delivers events to the component instances via its synthetic event system, delivers props from owner component instances to the nested component, renders the DOM on behalf of the component based the generated ReactNode (a framework specific type) and provides application infrastructure like Context - all of which can be considered services for the components and all for the purpose of rendering the UI and running the application activities.

type ReactNode = ReactChild | ReactFragment | ReactPortal | boolean | null | undefined;

The framework has the effect of decoupling or isolating the components from each other since it the component interactions are handled by the framework in a manner that is opaque to the components.

React components don't interact directly with one another. All interactions go through React facilitated by the ReactNode objects generated by the components.

In other words, it is the framework that is "running the show", directing the calls to the component services, not the other way around.

That's React. Calls the component to get the rendered ReactNode and to schedule the application effects.

Also "Hollywood Principle":

"Don't call us, we'll call you"_

Relevant when you are writing a class/component that must fit into the constraints of an existing framework. You implement the interfaces, you get registered. You get called when the time is right.

This requires a distinctly different way of thinking from that which is taught in introductory programming where the student dictates the flow of control.

That pretty much describes React components.

So React is a component framework.

Hence the title of my gist : React is a (view component) framework.

Now, in the React components, props, etc, you can apply these concepts in order to make components independent and exchangeable.

The objective of dependency-injecting a database is to treat the database as an implementation detail. What persistence storage product is ultimately used should not affect your application's ability to function.

Your UI layout and behaviour on the other hand is specific to the needs your application - and ideally it's the UI technology (e.g. React) that you want to treat as an implementation detail, so it's React that you want to be exchangeable. Given that isn't possible, the standard tactic is to make the UI as dumb as possible (The Humble Dialog Box) and inject the whole UI as a single plugin into the application. That isn't what typically happens with React applications - typically the application is injected into React via the component tree.

The "component exchange-ability" argument is largely associated with the component reuse and replace-ability objective which is an entirely different goal. And you have to specifically design for components to adhere to a specific interface (what props, which context) to be independent and exchangeable so that isn't a by default feature, you have to put in some extra effort in for that to happen. And after all that it's still only reusable within React.

You can learn more in the great Martin Fowler Article.

Read it many times since its publication in 2004. The component tree is injected into React before anything else can happen - so React is in control.

The Render Props technique for example, allows you to create a component that gets the data and render it using another component that it knows nothing about, the renderer gets injected into it

And it has never occurred to you that it's kind of strange that a "UI library" needs support for non-visual components? You are injecting parts of the application into the UI. This is just further evidence that React is a framework.

it may help you understand the insights.

The first thing that I notice is that it's React-centric. Other than that nothing new.

And that may point to the underlying problem - in the mind of some people React is the center of the universe because React is the center of their applications.

To properly decouple the application from React it better look something like:

import { h, render } from 'preact';
import { UI } from './components/ui.jsx';
import { Shop } from './components/shop.js';
import { makeShop } from './app/shop.js';

const shop = (() => {
  const client = {
    getBooks: () => fetch('/books.json').then(response => response.json())
  };

  return makeShop(client);
})();

render(
  <App />,
  document.getElementById('root')
);

function App(_props) {
  return (
    <Shop.Provider value={ shop }>
      <UI />
    </Shop.Provider>
  );
}

that is, your components access nothing but React or the shop application object to get the job done.

"hey I got a framework" but react itself does not cover the requirements for being one and even react can be a lib to extend functionality inside another framework.

And again you're talking about an "application framework".

send an email to React team with your complains to see if they change its own description

After 8 years they are not going to change anything.

Best guess: "JavaScript library" is being treated as a marketing (propaganda) term:

• So that people don't have false expectations of a "batteries included" solution like Angular.
• So that people buy into the whole "so simple, React can be learned in a weekend" meme.

You can start here for example.

That article is irrelevant as it commits the same mistake of equating "framework" with "application framework" (perhaps even a case of false equivalence) as the author does not convey an understanding of the fundamental characteristics of a general framework (vs library) that were established long before React was authored.

The distinction is important because IoC used by frameworks to run user code impacts how you structure an application - often not in a good way. If you're comfortable re-writing your client-side apps every two years or so or start to look for another job then you won't have to bear the consequences of not countering the bias that React can introduce into an application (i.e. React is opinionated - in its own way).

[JoelBonetR 🥇]

Yeah ok, watever. TLDR.
All people is wrong but you.
This is my last answer to this thread, sincerely, you make all of us loosing time from a biased pov or misunderstanding of concepts.

I let you this link from a person I appreciate within the industry for his way of explaining things describing just that concepts.

[peerreynders]

Please listen to your own advice.

[fabio-rizzello-omnia]

Best guess: "JavaScript library" is being treated as a marketing (propaganda) term:
So that people don't have false expectations of a "batteries included" solution like Angular.
So that people buy into the whole "so simple, React can be learned in a weekend" meme.

Exactly