A proposal to add signals to JavaScript • Hacker News Board

Re: A proposal to add signals to JavaScript

#331

Post by gloosx » Fri, Apr 05, 2024, 10:15 AM UTC

recursive wrote: post #330

gloosx wrote: post #329

Earlier quoted context omitted.

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…

Enqueuing an update is mutating an update queue. None of these semantic games affect the fact that the value of `count` does not depend only on the parameters to the function.

I have to admit: you're perfectly right here. React of course always relied on mutable state in it's implementation – just so we don't have to. I derailed a lot here to keep this funny thread going ;) I'm still not with you on your definition of "functional", since you treated it synonymously with "purely functional". Functional means just made by applying and composing functions, and react UI is created exactly like that. There is an awesome algebraic effects proposal[1], which will hopefully will be added to JavaScript one day, then react will make use of it to become purely functional.

1: https://github.com/macabeus/js-proposal-algebraic-effects

Re: A proposal to add signals to JavaScript

#332

Post by recursive » Fri, Apr 05, 2024, 4:33 PM UTC

gloosx wrote: post #331

recursive wrote: post #330

Earlier quoted context omitted.

Enqueuing an update is mutating an update queue. None of these semantic games affect the fact that the value of `count` does not depend only on the parameters to the function.

I have to admit: you're perfectly right here. React of course always relied on mutable state in it's implementation – just so we don't have to. I derailed a lot here to keep this funny thread going ;) I'm still not with you on your definition of "functional", since you treated it synonymously with "purely functional". Functional means just made by applying and composing functions, and react UI is created exactly like…

I concede the difference between "functional" as in composition and "pure". That's a significant point.

The proposal is interesting. It looks pretty thin compared to a typical TC39 proposal though. I haven't encountered the language feature before. I'm not sure what I think about it yet. I'm doubtful whether this makes it into the standard in the next 10 years, unless react affiliates somehow take over the committee.

Immutability is a pretty good tool in a lot of problem domains. But perhaps the main thing I dislike about react (and there are many) is that not only do I "not have to" rely on mutable state. I can't decide to either. Or at least, they make it tough.

Re: A proposal to add signals to JavaScript

#333

Post by recursive » Sat, Apr 06, 2024, 2:06 AM UTC

junon wrote: post #128

Related is S.js: https://github.com/adamhaile/s I love signals. I prefer them when making UIs over any other primitive (besides, perhaps, the cassowary constraint algorithm). I try to replicate them in every language I use, just for fun. I also don't believe they belong in the Javascript language whatsoever. Let the language be for a while, people already struggle to keep up with it. TC-39 is already scaring away peo…

If people are getting scared away from javascript, imagine what a popular one would look like!

Re: A proposal to add signals to JavaScript

#334

Post by recursive » Sat, Apr 06, 2024, 2:12 AM UTC

londons_explore wrote: post #39

Can't we just call javascript 'done'? We keep adding things to the language, and never subtract anything, which means learning it as a language is getting harder and harder.

You may hereby consider `with` to be removed. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: A proposal to add signals to JavaScript

#335

Post by tqwhite » Mon, Apr 08, 2024, 4:55 PM UTC

Izkata wrote: post #197

cuddlecake wrote: post #162

Earlier quoted context omitted.

Promises are, technically speaking, "abstracted crap". So is abstracted crap only ok if it's already in the JS standard library?

Promises proved themselves in libraries before they got added to Javascript.

I hate promises. Writing:

let result; let error; await blah .then(r=>result=r) .catch(e=>error=3) .final(callback(err, result));

Is disgusting.

Re: A proposal to add signals to JavaScript

#336

Post by claytongulick » Mon, Apr 08, 2024, 10:19 PM UTC

troupo wrote: post #290

claytongulick wrote: post #278

Earlier quoted context omitted.

Sure. I structure my apps with light DOM vanilla web components, using lit-html (not lit) as a renderer. I'll use a hypothetical patient profile component as an example. Let's say that it's a top level "page" and needs to support deep linking. set patient_id(value) would trigger a loadPatient(). loadPatient would set this.patient when loading is complete. The setter for this.patient triggers a render and paints the c…

Note how much work you need to do manually: - don't forget to trigger a render from a getter. Possibly not just from one getter if the component relies on more than one data point that is changing - don't forget to fire a custom event if this data needs to be propagated somewhere else - don't forget to subscribe to the custom event in the places where this data is needed and trigger the render when the data is update…

> Note how much work you need to do manually

In practice, I find the totality to be less work and easier, otherwise I'd use a framework.

> As frameworks/libraries with fine-grained reactivity will show you, literally only those places will get updated

Maybe take a look at how lit-html works.