A proposal to add signals to JavaScript

Post by wseqyrku » Tue, Apr 02, 2024, 11:37 AM UTC

Post by mattdesl » Wed, Apr 03, 2024, 1:53 PM UTC

recursive wrote: post #316

mattdesl wrote: post #314

Earlier quoted context omitted.

To do parallel tasks in a loop for the situation I outlined (getting a final array of images from URIs), it would be really cumbersome, and your implementation would be pretty much equivalent to the inner workings of Promise.all. As others have mentioned; if you aren’t using Promise.all, you are likely missing a good deal of opportunities for easier and more performant async code.

For non-rejecting promises, `await Promise.all(promises)` is basically performance equivalent to `for (const p of promises) await p;`. In case you think the second one does serial work, here's a codepen for you. https://codepen.io/tomtheisen/pen/QWPOmjp The "inner workings" could be a for loop, with the exception of rejected promises. The only opportunity for quicker resolution is when one of the promises reject, at…

  // A -- Async and parallel
  const results = await Promise.all(data.map((i) => delay(i)));

  // B -- Functionally equivalent to the above
  const promises = data.map((i) => delay(i));
  const result = [];
  for (let a of promises) {
    const r = await a;
    result.push(r);
  }

  // C -- Problematic and naive approach: much slower
  const result = [];
  for (let i of data) {
    const r = await delay(i);
    result.push(r);
  }

Post by imbnwa » Wed, Apr 03, 2024, 7:09 PM UTC

refulgentis wrote: post #161

shermantanktop wrote: post #159

Earlier quoted context omitted.

The rationale for it is the fact that multiple frameworks provide their own versions of this mechanism. The proposal is to relocate extremely popular and common functionality from framework space to the language/runtime space. The popularity of React is itself the rationale for the utility of this idea, and any terse version of the rationale is for show. Is that a good enough rationale? Maybe, maybe not, but you are…

Most importantly: OP is right re: vanilla example is most legible. Reading the proposal, I have no idea what this "Signal" word adds other than complexity. Less important: I really, really, really, really, am reluctant to consider that is something that needs standardizing. Disclaimer: I don't have 100% context if this concept is _really_ the same across all these frameworks. But frankly, I doubt it, if it was that s…

Post by recursive » Thu, Apr 04, 2024, 4:14 PM UTC

gloosx wrote: post #327

recursive wrote: post #325

Earlier quoted context omitted.

Tell me, what's the value `counter` returned by this "pure" function invocation? const [counter, tick] = useReducer(st => st + 1, 0) Answer: It depends. Sometimes 0, sometimes more. Any function that can return different results for the same inputs is impure. Therefore, `useReducer` is impure. It can return different results for the same input. React may have some alternate definition for "function" or "pure", but th…

Given function is pure, for any given input state, it will return state + 1, the state is an accumulated result of all invocations, there are no arguments nor external factors that would cause it to behave differently. There are no side-effects either, it solely relies on it's input state to produce the output, it doesn't mutate any variables outside it's scope, doesn't interact with the outside world, nor modify any…

    let current = 0;
    function getNext() { return current++; }

Post by recursive » Thu, Apr 04, 2024, 9:38 PM UTC

gloosx wrote: post #329

recursive wrote: post #328

Earlier quoted context omitted.

Crucially, the state you're referring to exists outside the function parameters. Invoking the returned reducer function mutates the `memoizedState` property on the component's fiber object. The fiber object is the state external to the function. It's not one of arguments to the function. Here's a function. Is it pure? let current = 0; function getNext() { return current++; } Note that the result is an accumulated res…

It all seems right, except the reducer function does not mutate the fiber object. Your function is certainly not pure, it boldly mutates the outside state via increment operator. It is incorrect to extrapolate this on how fiber works. The difference is that React hook, with both state and setter lives inside the dispatcher, and calling the hook setter only enqueues an update which is then handled by dispatcher, so te…