[proto-n]

It seems you only want to call MVC frameworks frameworks? But there's millions of other types of frameworks for thousands of purposes. Framework is a generic term (for which the definition is usually the calls into you/you call into it thing). What it does and whether it's a framework is two completely orthogonal things.

[qudat]

> It seems you only want to call MVC frameworks frameworks?

No, I'm illustrating the limited scope of React. I wouldn't call a chunk of code that handles the V in MVC a framework.

> for which the definition is usually the calls into you/you call into it thing

Again there's nuance here:

    import { useEffect, useState } from "react";
    import { createRoot } from 'react-dom/client';
    document.body.innerHTML = '<div id="app"></div>';
    const root = createRoot(document.getElementById('app'));
    root.render(<App />);

    function App() {
      const counter = useState(0);
      useEffect(() => { console.log('effect') }, []);
      return <h1>hello world: {counter}</h1>
    }

I'm "calling into" react (3) times here, while react is calling "into me" (1) time. Are we saying any external source code that accepts a function as a parameter is considered a framework?

All react does is render/diff/patch your dom, everything else is up to the end-developer. Would you call `express` a framework? Again this is semantics but look at all the react frameworks that exist on top of react, why do those exist?

[lmm]

> I'm "calling into" react (3) times here, while react is calling "into me" (1) time.

It's calling into you three or more times, invisibly, if I remember the details of what useEffect and useState actually do at runtime correctly. Which rather illustrates the point.

> Are we saying any external source code that accepts a function as a parameter is considered a framework?

Code that accepts a function for narrowly scoped use where the control flow is still under your control (e.g. map/reduce/filter libraries) is probably not a framework. But external code where you register a callback that gets called some time later, not under your control, is pretty much the definition of a framework.

[Izkata]

> It's calling into you three or more times, invisibly, if I remember the details of what useEffect and useState actually do at runtime correctly. Which rather illustrates the point.

If they were using useState() correctly and provided a button or link to call the update function, yeah, React would call into their code as many times as the user clicked the button. As it is though, it's just once (useEffect with that second argument is "only run the passed-in function once on mount").

[lmm]

> If they were using useState() correctly and provided a button or link to call the update function, yeah, React would call into their code as many times as the user clicked the button. As it is though, it's just once (useEffect with that second argument is "only run the passed-in function once on mount").

As I understand it both the useState and useEffect create points where their code will be suspended and resumed as a coroutine, even if everything only gets run once? But yeah, the more important point is that in the general case React will run it multiple times in ways that are not really under the user's control (at least not without understanding the internal details of React quite deeply).

[Izkata]

Nope:

The first run through, useState() returns the default value and your code runs to completion. When the update function is called, that entire React function is run again, but this time useState() returns the new value instead of the default value.

Likewise useEffect(), your React function runs all the way through and the callback passed to it is run afterwards at various times depending on the dependencies array. First run is immediately after, on component mount, then every time the dependencies change (if dependencies are specified), or every rerender (if null/undefined instead of an empty array).

[lmm]

> The first run through, useState() returns the default value and your code runs to completion.

Your function was still sliced into the part before and the continuation (Dispatch) after though, right? The React runtime calls that continuation immediately with the default value, so you don't notice the suspension, but control flow wise it's still React calling your code twice rather than once.