3 ms·

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 te

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 2y ago
> 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 2y ago
  > 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 2y ago
    > 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 2y ago
      > 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 2y ago
        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 2y ago
        > 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.

qudat 2y ago

> 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 2y ago
> 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 2y ago
  > 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 2y ago
    > 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 2y ago
      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 2y ago
        > 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.