Live data from Hacker News

What Are Signals?

signia.tldraw.dev

51–60 of 63 posts

Re: What Are Signals?

#51

I don't really understand why people like signals again. I used a signals-like reactive programming model in VueJS a while ago and hated that you could never be sure exactly where things were being changed. Thankfully it seems that the React creators and maintainers are not hopping on the signals train and are instead adamant about unidirectional dataflow with explicit mapping of state to UI, which, as has been the r…

I haven't had much success using signals as a software composition mechanism at scale ... Despite being familiar with Conal Elliott's "functional reactive animations" concepts and Racket's FrTime.

"patch languages" like PureData, Max/MSP/Jitter, QuartzComposer are much better interfaces to work with signals ... Or rather with signal processors.

Re: What Are Signals?

#52

I don't really understand why people like signals again. I used a signals-like reactive programming model in VueJS a while ago and hated that you could never be sure exactly where things were being changed. Thankfully it seems that the React creators and maintainers are not hopping on the signals train and are instead adamant about unidirectional dataflow with explicit mapping of state to UI, which, as has been the r…

A series of articles from the author of Solid discussing all those tweets, and more, including the history of signals and their vurrent state.

- The Evolution of Signals in JavaScript, https://dev.to/this-is-learning/the-evolution-of-signals-in-...

- React vs Signals: 10 Years Later, https://dev.to/this-is-learning/react-vs-signals-10-years-la...

- Making the Case for Signals in JavaScript , https://dev.to/this-is-learning/making-the-case-for-signals-...

Those two code examples are different because that's the tradeoff that Solid made. It allows Solid to track changes in a uniform way even if the data isn't inside a component. Because in Solid components are just a way to organize code, not a unit of rendering (like in React).

And on top of that if you think that React still somehow has unidirectional data flow, it doesn't. Hooks make it anything but unidirectional. And not that different from signals: https://res.cloudinary.com/practicaldev/image/fetch/s--upMC6... But often less predictable.

See also The Cost of Consistency in UI Frameworks, https://dev.to/this-is-learning/the-cost-of-consistency-in-u... which is slightly related to this.

Re: What Are Signals?

#53

Earlier quoted context omitted.

What approach do you prefer for big apps? The state has to go somewhere, curious how you choose to handle it.

Personally I just use Redux Toolkit with RTK Query for any synchronization with backend state. What I like about Redux is that it takes the immutable functional approach, you cannot change previous state but must instead derive new state from the old state very explicitly. In this way, it's the antithesis of signal-based state.

> What I like about Redux is that it takes the immutable functional approach

Strange that you don't like spaghetti, but then praise Redux that is spaghetti exemplified: dozens of functions, and wrappers, and hooks eerywhere. Trying to trace how a value gets changed through the three-four layers of wrappers is like pulling teeth through the anus.

And looking at the current reincarnation of this abomination, it is marginally less spaghetti, and converging on the same signals code that everyone is converging on.

Re: What Are Signals?

#54

Earlier quoted context omitted.

My impression is that Javascript is just an horrible language to create reactive systems, and that default purity with explicit effects is extremely underrated. (But then, I was already biased.) It is hard to even make sense of the discussion without imagining the details of how those frameworks are implemented. And the discussion on the level of normal usage, not something advanced or development oriented.

What language(s) would you recommend for building reactive systems?

Well, the OP links to 3 large threads from JS framework designers that do nothing but talk about how they deal with the lack of referential transparency.

So, I'd guess, something with referential transparency.

Re: What Are Signals?

#55

I don't really understand why people like signals again. I used a signals-like reactive programming model in VueJS a while ago and hated that you could never be sure exactly where things were being changed. Thankfully it seems that the React creators and maintainers are not hopping on the signals train and are instead adamant about unidirectional dataflow with explicit mapping of state to UI, which, as has been the r…

A series of articles from the author of Solid discussing all those tweets, and more, including the history of signals and their vurrent state. - The Evolution of Signals in JavaScript, https://dev.to/this-is-learning/the-evolution-of-signals-in-... - React vs Signals: 10 Years Later, https://dev.to/this-is-learning/react-vs-signals-10-years-la... - Making the Case for Signals in JavaScript , https://dev.to/this-is-le…

Dan Abramov replied to those as well. Personally, the purity of the React model with bringing in only local rather than global state in every function is what appeals to me. Even hooks are still local state, if you change the value in useState, you're not going to suddenly have something change elsewhere, where it wasn't explicit where you changed it.

Re: What Are Signals?

#56

Earlier quoted context omitted.

Personally I just use Redux Toolkit with RTK Query for any synchronization with backend state. What I like about Redux is that it takes the immutable functional approach, you cannot change previous state but must instead derive new state from the old state very explicitly. In this way, it's the antithesis of signal-based state.

> What I like about Redux is that it takes the immutable functional approach Strange that you don't like spaghetti, but then praise Redux that is spaghetti exemplified: dozens of functions, and wrappers, and hooks eerywhere. Trying to trace how a value gets changed through the three-four layers of wrappers is like pulling teeth through the anus. And looking at the current reincarnation of this abomination, it is marg…

Redux Toolkit is very impressive, especially with TypeScript. I'd agree that there was a lot of boilerplate in the before-times, but today, it's not "marginally less," it's significantly less boilerplate. The debugging tools are top notch as well, I can trace values and their changes pretty easily these days.

The main point of Redux is that it follows functional programming paradigms of immutable data, which makes reasoning about changes much easier. Compare that to the global state everywhere of signals/reactive/observables-based approaches like MobX or RxJS.

Re: What Are Signals?

#57

Earlier quoted context omitted.

A series of articles from the author of Solid discussing all those tweets, and more, including the history of signals and their vurrent state. - The Evolution of Signals in JavaScript, https://dev.to/this-is-learning/the-evolution-of-signals-in-... - React vs Signals: 10 Years Later, https://dev.to/this-is-learning/react-vs-signals-10-years-la... - Making the Case for Signals in JavaScript , https://dev.to/this-is-le…

Dan Abramov replied to those as well. Personally, the purity of the React model with bringing in only local rather than global state in every function is what appeals to me. Even hooks are still local state, if you change the value in useState, you're not going to suddenly have something change elsewhere, where it wasn't explicit where you changed it.

useEffect, useContext, and usSyncExternalStore are no longer about "local only".

And you never use only local state. You advocate for Redux in a different comment which is literally a global state where you are going to have something suddenly change somewhere from the point of view of a component.

Re: What Are Signals?

#58

Earlier quoted context omitted.

> What I like about Redux is that it takes the immutable functional approach Strange that you don't like spaghetti, but then praise Redux that is spaghetti exemplified: dozens of functions, and wrappers, and hooks eerywhere. Trying to trace how a value gets changed through the three-four layers of wrappers is like pulling teeth through the anus. And looking at the current reincarnation of this abomination, it is marg…

Redux Toolkit is very impressive, especially with TypeScript. I'd agree that there was a lot of boilerplate in the before-times, but today, it's not "marginally less," it's significantly less boilerplate. The debugging tools are top notch as well, I can trace values and their changes pretty easily these days. The main point of Redux is that it follows functional programming paradigms of immutable data, which makes re…

> Compare that to the global state everywhere of signals/reactive/observables-based approaches like MobX or RxJS.

What are you on about? Redux is literally about global state everywhere. But with three to four layers of abstractions between.

You define your state globally. Then use hooks to fetch data from that global state, and then "dispatch" aka call actions on that global state. If something else somewhere else updates data in that global state your component will be affected if it uses that data.

But it also requires you to write an insane amount of useless stuff like "define your store, then reducers, then slices, then god knows what" to arrive at almost the same code:

   // redux

   import { useSelector, useDispatch } from 'react-redux'
   import { decrement, increment } from './counterSlice'

   export function Counter() {
     // note how we reach into magical global state that useSelector knows about
     const count = useSelector((state: RootState) => state.counter.value)
     const dispatch = useDispatch()

     return 
         dispatch(increment())}>Increment
        {count}
         dispatch(decrement())}>Decrement
     ;
   }


   // solid

   // state is immutable. It's also not magical, you explicitly refrence and import it
   //
   // increment and decrement would use a `set` function to update the store to required value
   // see https://www.solidjs.com/docs/latest/api#createstore
   // and https://www.solidjs.com/docs/latest/api#updating-stores
   //
   import { state, increment, decrement } from './counter-store';

   export function Counter() {
     return 
         increment()}>Increment
        {state.count}
         decrement()}>Decrement
     ;
   }

Re: What Are Signals?

#59

Earlier quoted context omitted.

Dan Abramov replied to those as well. Personally, the purity of the React model with bringing in only local rather than global state in every function is what appeals to me. Even hooks are still local state, if you change the value in useState, you're not going to suddenly have something change elsewhere, where it wasn't explicit where you changed it.

useEffect, useContext, and usSyncExternalStore are no longer about "local only". And you never use only local state. You advocate for Redux in a different comment which is literally a global state where you are going to have something suddenly change somewhere from the point of view of a component.

You are misunderstanding me. I never said to use only local state with no global state at all. My point is that signals automatically make all state global because you can reference what should be a local value in a component, in another component entirely which is not at all connected to the initial component either in a parent or a child relationship. In other words, you are making a graph, not a tree.

For Redux, at least that's explicit, for signals, it's really not.

Re: What Are Signals?

#60

Earlier quoted context omitted.

Redux Toolkit is very impressive, especially with TypeScript. I'd agree that there was a lot of boilerplate in the before-times, but today, it's not "marginally less," it's significantly less boilerplate. The debugging tools are top notch as well, I can trace values and their changes pretty easily these days. The main point of Redux is that it follows functional programming paradigms of immutable data, which makes re…

> Compare that to the global state everywhere of signals/reactive/observables-based approaches like MobX or RxJS. What are you on about? Redux is literally about global state everywhere. But with three to four layers of abstractions between. You define your state globally. Then use hooks to fetch data from that global state, and then "dispatch" aka call actions on that global state. If something else somewhere else u…

Solid is basically using the same Flux architecture that Redux and Vuex is using then, with stores and actions. It's just more hidden away than in Redux which is more explicit. Yes, I do want to explicitly see what my data store looks like and in Redux I'm able to. That I have to create slices (which are automatically mapped to TypeScript by the way) is fine with me, it's only a few lines more than in your Solid example.

To add, this is also why I explicitly mentioned Rx and Mob, which are not as clean as the Flux architecture in terms of creating spaghetti code. And I believe we are also defining spaghetti differently. Spaghetti != boilerplate.

Post reply on HN