Nice video. The fact that two different frontends use the same signal store is awesome.

I'm definitely going to push that into prod right now

@jherr

2 ай бұрын

Aggghhhh!!!!! 😂

*Preact Signals* has entered the chat

Kind of wild the difference b/w how svelte and react can be integrated with this lol

This is revolutionary❤

Fantastic video ❤

Nice one jack❤

Bravo, thanks

This is a great video, thanks Jack! Reminds me a lot of MobX. I’m pretty happy that these patterns are making it to mainstream (heh) React.

@jesusidev

2 ай бұрын

Was thinking the same thing, I’ll keep using mobx and the indexeddb

@__WONTFIX__

2 ай бұрын

Yeah surprised signaljs popped off but not mobx

@mfpears

2 ай бұрын

Wasn't MobX mainstream? I was doing Angular in 2017 and knew what MobX was

Legend state is production ready and is great for react signals

Can you tell me what the theme of zsh in your vscode? It looks good!

It is still early phase, use it once it's api is confirmed.

Great stuff as always J. I'm hoping you might have a suggestion re: first steps in learning about building a decentralized blockchain - possible project coming and I'm definitely not "up to speed" fon this subject,. thanks in advance :)

@jherr

2 ай бұрын

I don't do crypto or blockchain.

what zsh theme you are using?

@jherr

2 ай бұрын

It's oh-my-posh on top of oh-my-zsh.

I do not see react get signals in recent days the problem is the reason for that the reactive model of react is about re-evalute the component this mean of you want to opt-out you need to use useMemo useCallback memo other framework you need to opt-in so signals for react it is like useState

@jherr

2 ай бұрын

Don't forget that we are getting the React Forget compiler. Which is going to reduce/remove the need for useMemo/useCallback.

@xxXAsuraXxx

2 ай бұрын

React Compiler: let me introduce myself.

@user-tb4ig7qh9b

2 ай бұрын

@@xxXAsuraXxx for me what react team doing just kill react yeah react forget will do awesome job i think that but consider most of the framework changed the way doing things even vue and angular and intgrate js library for other framework will be easier than do that for react.

I'm wondering, what do you think about web components and webassembly?

@jherr

2 ай бұрын

Those are two entirely different things. I think both are incredibly cool. Is there something in particular you'd like me to comment on?

The effect function, in React, is called inside useEffect. Of course, cause there is a "unsubscribe". BUT... in Svelte example, effect function is called directly and never unsubscribed. Is this how it is intended, or??

@jherr

2 ай бұрын

Probably a mistake on my part. I don't know Svelte all that well. If there is an unmount, then I should have called the cleanup in there.

Hi Jack, I really enjoy your videos and I would also like to share the knowledge you've shared with my friends. May I have your permission to repost your video? Due to regional network restrictions, I have to download and repost it, but I will credit the original author and indicate that it is for educational purposes only. I look forward to your response.

Omg

I'm personally OK with the explicit "get()". No indirections, and clearly tells the user that this is a Signal which will subscribe to any changes and re-run any computed computations. If you wanted, you could easily build your own function that returns its own API, i.e. like Solid's "createSignal" function, which returns a tuple with a getter and setter similarly to React's useState.

It's too complicated, I will wait for the final native version. Angular uses signal and the usage is simpler.

@jherr

2 ай бұрын

That's probably because they are doing the effect work that we had to do here by hand. We are doing the framework's job in this video.

I also have a experimental vue lib for it www.npmjs.com/package/vue-use-signal Didnt make the repo public as I want it to be for testing purposes

@user-tb4ig7qh9b

2 ай бұрын

Signal already packed on vue ?

@wobsoriano

2 ай бұрын

@@user-tb4ig7qh9byeah, using Proxy. Just love to play with it!

That looks like a whole mess of gnarly boilerplate, compared to what I'm seeing in Preact signals. I'm excited about this evolution, especially because useEffect is so messy, and you're otherwise left with a myriad of non-standard, third-party options that may not be around for years. Signals brings simplicity and maturity to React, which is desperately needs. I'll wait for the standard to make it into JS and trickle down through all the frameworks.

I don't like the way signals syntax looks like, if if is a proposal why not take the chance and make a totally new syntax to make it cleaner, Her just an Example: signal count = 0; signal double = count * 2; effect { console.log("count ", count); console.log("double", double); };

@jherr

2 ай бұрын

If this `signal double = count * 2;` expression works then you would no longer need `effect` and this `console.log("double", double);` expression would have to automatically re-run on any change to `double`. Which would very quickly get out of control which is probably the reason that this wasn't the way the spec went. This would be a fundamental change to the whole JS language and engine. And no language that I know of works this way (outside of something like Svelte that has a very limited way of doing this which has been supplanted by Runes).

@ivan.jeremic

2 ай бұрын

@@jherr yeah the idea is to have `double` re-run automatically without needing a function, I called the effect in this example effect just to differentiate, it could be called just `signal` aswell and the engine would know to re-run this code block. I agree that this is what runes try to look like kind of, this example is taking it to the engine level.

@jherr

2 ай бұрын

@@ivan.jeremic Runes still have a pseudo callback function to update the signal the `computed(...)` brackets the `...` to something that lexically we can understand and limit. Where if you just had `double = count * 2` it could also include anything around that expression.

@ivan.jeremic

2 ай бұрын

@@jherr if I think more about it, if everything about my example should be engine level, there is not even a need for a code-block/effect, you write you code naturally and vanilla and the engine knows what parts and from where to re-run. Maybe impossible to add to JS but why not throw some ideas at them.

@jherr

2 ай бұрын

@@ivan.jeremic Oh, absolutely go for it. But I think you'll be answering a lot of tough questions about language design with this variant.

Such unnecessary complexity.

Why all these `new`? Soon enough people will get tired of writing them. Too verbose for JS!