A video showing the advantages and disadvantages of each reactivity model would be nice, signals have gained a lot of attention thanks to seeming like a simple solution for the rendering cycle used by React without changing much in the writing model but for me who currently use Svelte as my main framework seems to be another step backwards as it brings more work to be done during runtime and decouples state from component (making animations and lifecycles like svelte uses impossible), not that the system svelte uses doesn't have either your problems, that's why the idea of the video
Solid's state model wins me over -- it feels like how state management ought to be (IMO). Fine-grained updates, easy to use w/o being too easy like Svelte (i.e., Svelte being easy to get yourself into trouble in large project, 2-day data binding, auto-exporting props, etc). Too bad SolidStart is only in beta -- I've been coding the same project in SolidStart and SvelteKit for the past couple months, and prefer Solid in almost every way except for not being 1.0 yet (no major issues, more about knowing there will likley be breaking changes). Love your videos Jack! Always well done and informative -- a great service to the JS community. Thanks!!
8:47 you can see that fallback in For component is not when data is loading, but when you have an empty array, like when you filter doesn't match any items
Thank you for helping me keep my FOMO in check! :-) Always nice feeling when you grasp a concept you previously didn't. Thanks for all your videos Jack.
I had read that it skips the virtual DOM and updates the DOM directly but I don't know for sure. You can update the signal without the re-renders because the signals are objects with value property. You are only passing a reference to this object and unless you access the .value property, the DOM does not re-render. However you can still render the value if you omit the .value, as Jason said.
Jack as usual your research is excellent and you deliver in spades. Unfortunately, my key takeaway here is that Ryan is a friggin' genius and now that SolidStart is slowly chugging along towards a production-ey state, the rest of the class is growing restless.
Nice video, I would be interested to see the different lighthouse scores of these solutions. maybe even a performance analysis for each implementation :D
Pretty sure in release mode they would all be 100s. There just isn't enough content, CSS or data. There are no images. In the non-SSR versions there are not layout changes, and even in CSR there is only one.
Great talk. thank you Jack! I guess the reason solidjs, qwik needs signals based on how they update dom. Updating states subscribed by a component followed by full re-render of component , that's why we can't say it's fine grained state update. However, qwik and solidjs only updates some point of declaration in single component , which makes they can fine grained states management. For support their architecture, signals seems inevitable
And somewhere under a palm tree, a Java Spring Enterprise developer is sitting quietly, drinking sambuca. The one who understood life, he is in no hurry :)
Signals are quite similar to events ... And we can reimplement signals "easily" by using (react-mitt) library ... However, signals may lead to bad practices Would love to hear you thoughts on this
Thank you for this video. I do imagine time you need to get all versions work and captured. I’d be also happy to see some comparison to svelte and vue. Anyway thanks!
Is there a way to understand how the signals work under the hood without actually reading the source code? I tried first, but it feels overwhelming. I never worked on a JS library, so don’t even know where to look in the repo. At the same time, I wanna understand how these technologies work on a deeper level, because all the videos about Signals I’ve seen so far only explain the API and how to use them, but not how they work and why they are so cool and better than the V-DOM
HI @Jack Herrington! I found a little bit confusing the function `routeData` because the 1st thing we do is create this array destructuring with [users] on it, but then inside our createResource 1st parameter the function we pass returns a object with property e value for users. How it works for the array destructuring for createResource return object to get the 1st value of the returned array? Sorry if my question is a bit confusing too... But I wanted to understand how that `{ users }` object go to the first value of the returned array on line 13 at 9:15 of the video timeline. Thanks!
Great video Jack, as always! Care to share more about your terminal, looks like a modified version of vscode's? I like the fact that it shows node version and other useful stuff
The gymnastics some go to instead of simply move to Solidjs... React was a stepping stone in the age of web development, let's move on to the next already.
You can’t expect big corporations and products to just move to something that new even if the transition is smooth. Solid is great, but lacks React’s community, ecosystem and meta-frameworks. For example SolidStart has a long way until it surpasses or even becomes Nextjs :)
Happens every time, same thing when react started. Companies where still using angular or even jQuery. The big corporations are made of people and have developers that can choose the better tech, they just need a bit of courage. Starting a new thing with react is absurd given how ineficient it is.
Most of the time it's logical to stick with something that's "good enough" no doubt signals are much more performant. But unless something is so old/niche they have trouble finding devs to maintain it. Or has such bad performance that it warrants a rewrite/retool. Then corps will probably stick with react. And that's no problem if it works for them. Big eco-system, good dev-ex, developers still willing to support it. So it doesn't make sense to spend time and money retooling it to a different framework.
Thanks and really nice. Can we move the array values as separate child component to see how Signal subscribe and works in preact ? seems Signal is global state and hope it may render only child. Please let me now your thoughts.
I started using Jotai during the first release, replacing Apollo client state management with it, and it solved a lot of problems without a ton of boilerplate. I'm so happy to see it's still getting love to this day!
I notice you destructure the User component props in solid. If I'm not wrong, we should not destructure the component props in solid because it won't be reactive again. Can you confirm this?
In this case the items in the array of the signal are not in themselves reactive. So in this case we need the For to be reactive and nothing else. So I think it's ok in this case.
Great video as always @jherr. In case of both Solid-Start & Qwik-City the signal data will be computed on the server before first render, apart from the actual filtration that will be done on the client. Is there a way to run the computed on the server for lets say the preact or jotai signal if used with something like next.js?
Great question! You can definitely run state managers like Jotai on server with NextJS, but, your going to have to do the async work for them AFAIK, so that you can block on the async work in the getServerSideProps AND you will need to transit the data through server side props and initialize the atoms on startup on the client. So... not easy, but doable.
@@jherr thanks for the reply. That is why I am more keen on the new frameworks now, as they have started from scratch their solutions are alot simpler and elegant. Most features in react.js now feel like monkey patches.
In the Solid example, is there any particular reason to wrap users in "{ users }" in routeData return statement (What creates another object with key: value pair users: users?) then to destructure it in Home function? Wouldn't it be more simple to return directly the users array then assign it to users const?
FYI: In this situation you would typically use `createRouteData` (SolidStart; which wraps `createResource` (SolidJS)). And users isn't an array. It's the callable part of `ResourceReturn`, i.e. the signal that returns the user array once it is ready and updates it after a refetch.
Nothing magic. The server stores the output route data in a script tag on the page, which probably puts it in a global, and the useRouteData hook fetches that data from the script tag.
@@jherr Ah, I get it, after reading the documentation I see it says "SolidStart's file system routing allows components defined under the /routes to define a routeData function". And you actually mentioned it too at @5:24 but I somehow missed it, sorry. So it searches by convention for a function named "routeData" exported by your route file in the routes folder. I wasn't sure how would Solid know to invoke the custom routeData function since I could not see any explicit registration or call to this function. Not familiar with Solid or Next.js. Thank you for the reply by the way!
“Signals” will be great if “signals” is not tied to jsx, react, vue, solid, svelte, angular, … Advantage of framework/library independent “signals” is that developer can (1) switch from react to solid or others (2) test state management without loading up all these e2e… just use plain javascript test runner like mochajs or jasminejs.
You can use Solid or Preact Signals without JSX or anything for rendering. Solid under the hood uses another library from its creator Ryan Carniato called dom-expressions. You can absolutely separate them. And the mention of Preact's Signals in Svelte also shows how flexible it can be (used in a JSX VDOM library and in a compiled, custom DSL framework). Ryan Carniato has a few videos introducing Solid where he starts from signals in plain JS, manipulates the DOM directly, and finishes with all the Solid JSX stuff, so you can see how it is added and work together.
Based on Alex Lohr's article "Testing Solid.js code beyond jest" I was able to do that with just uvu in my solid-bookstore-a "Segregated UI in Action with SolidJS" repo. You just have to run the signals under a reactive root (`createRoot`; SolidJS) in the test code. Word is that separation will even be easier with SolidJS 2.0.
Yes, and in React you can technically just have a variable in your component function that uses a state variable, but it will also recompute on every render (even if the value of that state variable didn't change). Of course you can use useMemo in React but then you need to define the dependency array. It becomes more about how much changes and where it is used in your JSX. Solid is often seen as more efficient by default, whereas React expects you to be explicit and opt in to performance optimisations.
So one more reason to use Jotai. Can you please share if Jotai is reliable for production product or internal only? how you take that kind of decision in general?
Please i just built an app in react, utilizing signals but I get this error => { 'default' is not exported by react/jsx-runtime, imported by node_modules/@preact/signals-react/dist/signals.module.js } any time I run vite build, I have searched but couldn't get any answer... Would appreciate if you can help me please
So we are here because directly manipulating the DOM with vanilla js was too hard and untidy right? We're back to server rendering but seems like a lot of effort just to render some html
We're here because React convinced everyone that we should think of our application in terms of components that manage their internal state and UI/view. If you only care about the server rendering side, then using another programming language and their web frameworks will probably be a better experience for you. But many devs want to use JS and write code to use on the client and server (to avoid writing two apps). Thankfully there's lots of great options now with all these meta-frameworks. If you want a bit of both, I'd suggest Astro, where you can use components and still focus on vanilla JS
How would you implement something like rxjs' `switchMap()` for async results that can return out of order, and you only care about the most recent request? Or `debounce()`? Is it essentially a bunch of bookkeeping with imperative code?
The solid-primitives package implements `debounce` (and `throttle`) if you want to look at the source code. Solid signals are fine-grained reactive state while RxJS is about event streams. In RxJS terms Solid signals are Hot Behaviour Subjects because they hold current state and are multicast.
@@PeerReynders That's my point, it seems like a subset of what rxjs does (synchronous mapping). Once you add a (framework specific?) lib like you mentioned it's no longer 'simple'. RxJs can be equally fine grained, am i missing something?
@@adambickford8720 Initial versions of Cycle.js were based on RxJS. But in 2017 Andre Staltz (André Medeiros) felt that the RxJS default model of cold, unicast observables wasn't a good fit for UI and replaced them with xstream ("Why we actually built xstream"). RxJS is about asynchronous event streams while SolidJS's signals are about (largely synchronous) reactive state management (state + change propagation)-so the focus is somewhat different.
It's not so much the performance, it's the lack of dependency arrays and the ability to put signals and computed signals and effects wherever you want them.
@@wojciechjerczynski8951 No problem at all. I get your point for sure. I don't think signals or fine grained updating alone are enough for me to bail on React.
Among the apis presented in this video, in my opinion, the best by far is preact/signals By invoking the value using the .value property it is possible to destructure the signal when passed as a prop to another component (one of the most annoying parts of the solid, which brings with it other even more annoying problems such as the need for a helper function to declare default values for props), -it is possible to invoke the signal value inside an effect without adding the variable as a dependency using the .peek() method (something impossible with solid)- *as @ryansolid made me aware, it is possible to do the same with signals in solid using untrack*, it is possible to invoke the signal value inside the jsx reactively only using the variable directly without calling any method or property and on top of that thanks to the .subscribe method it becomes compatible with Svelte without any modifications
Do you like making `isSignal` calls in all your components to determine what is getting pass in is a Signal or not, or enforcing that your component props only accept Signals? Do this for a while and I wonder if opinion will change a bit. Qwik made the same call as well after experiencing this. The thing is you can use Solid this same way passing Signals and destructure props as you want, but it is generally seen as undesirable. It adds a different sort of complexity when authoring universal components. I speak to this having gone down this path for quite some time and wanting to avoid it with Solid, but I suppose only time will tell. Also small correction we have `untrack` so peeking values is definitely possible in Solid, in fact this is mechanism for how components are untracked top level.
"it is possible to invoke the signal value inside an effect without adding the variable as a dependency using the .peek() method (something impossible with solid)" Not true, you can use either `on` to specify dependencies to track , or `untrack` to not track signal inside the effect. Example using `untrack`, to not track count signal: ``` createEffect(() => { const untrackedCount = untrack(count); const trackedInput = input(); console.log(untrackedCount); }); ``` Example using `on`, to track only input signal, which results in the same outcome as `untrack` example above: ``` createEffect( on(input, () => { const untrackedCount = count(); console.log(untrackedCount); }) ); ```
@@ryansolid Yes, I prefer restricting the type of a value to ensure it works in exchange for being able to destructure props and set default values without needing a new boilerplate But I imagine it's easier to speak from my position that I don't work with OSS and use typescript in my projects Thanks for letting me know about the untrack, I'll update my comment to avoid misinformation
@@ryansolid That's a pretty silly straw man; in the same way we don't need `isString` or `isNumber` prop type checks in all of our components, we do not need `isSignal` littered everywhere. TypeScript has solved this exceptionally well, at scale, for most of the past decade. Manually opting into runtime checks, rather than leaning into de facto standard build tooling, is not only silly but completely unrepresentative of the ecosystem at this point. It's really a non-issue.
@@ryanchristian2623 So you are suggesting that you just make the props only accept Signals? Are you concerned with splitting the ecosystem for those who don't use signals? Like if I'm making a general component library like MUI for Preact what is my best approach? I've used frameworks like this, like Surplus. And it is a thing even without considering splitting the ecosystem. Technically the same is true of our Primitive Composition in Solid. If we made a `createInterval` we'd need to decide if the the delay takes a number or signal of number. Yes we typically defer to wrapping functions here. But it is an interesting question.
Signals really seems to be the future when using jsx, especially when compared to the react model But it seems to me that it is possible to go much further by dropping jsx altogether and moving dependency analysis to the build like Svelte does As Ryan Carniato himself (creator of solid) said, the implementation of signals has some disadvantages because the signals, due to the need to manage their own dependencies at runtime, already have a default minimum size, as they are natively disassociated from the component, it is not possible to have a visualization of component lifecycle and make the framework hostage to a single state management api Svelte on the other hand to avoid this differentiates local state created with the let keyword from shared/composable state created with any api that obeys a specific store contract whether it be the native implementation of the stores framework or any other external one (preact signals for example)
Svelte does so at the cost of dynamic dependency graphs. I trust there will be solutions to this in the future at some point that use a hybrid but without perfect compiler analysis across every file static graph analysis is at a disadvantage. Even with this book keeping due to being able to have more granular execution and dynamic graphs you find runtime systems generally faster than compiled today. I suspect the future is hybrid.
@@JLarky Cool. Good. Though... Not sure why that didn't show up since I was in a solid-start app. Maybe because my VS Code wasn't running with this project as the root. Hmmm... Ok. Thanks again for the reminder.
I've seen Solid and Preact both credit Vue as part of their inspiration for their signals implementation. Vue should definitely be given more credit than they get. It's also interesting that you can use JSX with Vue, if that's what you really like about React.
@@IainSimmons yes composition API makes it look less ugly and react-like. Imho Vue3 stylistically and by simplicity beats angular and react. No manual rendering dependencies, no ugly rxjs observables - just reactive variables and objects. Vuex was ugly. Now it's fixed. Looks like Vue is the best now.
Small, unimportant correction: You don't have to use in SolidJS. You can use .map and any other array method on signals-- just like you can use ternaries instead of . *Edit: See Correction Below!!!* The utility components are provided for better DX and performance. EDIT: *Correction* You can't set up a component with a ternary, but you can use one inside the return statement in {brackets}. A ternary will mount your component correctly, but it won't respond to any changes in the signals. I couldn't find any gotcha's with though-- it just seems to be more performant and easier to write than a .map.
@@jherr So, I can't find any reasons other than performance and DX to use over a map, but I realized that setting a component up with a ternary will not respond to signal reactivity. This is because components are simply set-up functions that never run again once they are mounted. I corrected my comment. Sorry for the misdirection!
@@jherr actually replying to @zombiefacesupreme, but to you as well since I want to see you to see it. Yes early conditional returns don't work because components are setup functions (only run once). But as long as boolean/ternary expressions are wrapped in JSX, they are compiled to ``, therefore be reactive. ``` function App () { return {condition ? : } } ```
I appreciate it but, having moved to React from Vue for almost two years now, I don't understand how this is becoming popular since Vue has been doing this for a while now. React is nice of course but I always liked Vue better and I wish it was the more popular option
What do you mean it had a better reactivity system? 💀 It has one of the best reactivity systems out there. Try using useState() outside of JSX file lol you can easily put Vue's ref() or reactive() in a different file and have global state management without any hassle. No useContext() or any weird quirks.
@@jamescat2386 O look I reinvented observables called it something else and put in more complexity and syntax to show you how can you make trivial things hard. O and don't forget to tell everyone its the new hotness......
Poor Vue 🥲 left out again. Having one of the best reactivity systems out there, implementing the exact same "signals" functionality, it often gets overlooked in these discussions.
A video showing the advantages and disadvantages of each reactivity model would be nice, signals have gained a lot of attention thanks to seeming like a simple solution for the rendering cycle used by React without changing much in the writing model but for me who currently use Svelte as my main framework seems to be another step backwards as it brings more work to be done during runtime and decouples state from component (making animations and lifecycles like svelte uses impossible), not that the system svelte uses doesn't have either your problems, that's why the idea of the video
Hey, I just have experience with React, but been thinking to start exploring and switching to Svelte. What's your opinion about React?
Thanks again Jack for all your hard work in putting these videos together.
Solid's state model wins me over -- it feels like how state management ought to be (IMO). Fine-grained updates, easy to use w/o being too easy like Svelte (i.e., Svelte being easy to get yourself into trouble in large project, 2-day data binding, auto-exporting props, etc). Too bad SolidStart is only in beta -- I've been coding the same project in SolidStart and SvelteKit for the past couple months, and prefer Solid in almost every way except for not being 1.0 yet (no major issues, more about knowing there will likley be breaking changes). Love your videos Jack! Always well done and informative -- a great service to the JS community. Thanks!!
8:47 you can see that fallback in For component is not when data is loading, but when you have an empty array, like when you filter doesn't match any items
Thanks for the clarification!
Thank you for helping me keep my FOMO in check! :-) Always nice feeling when you grasp a concept you previously didn't. Thanks for all your videos Jack.
There are a few creators on RUclips to which I give my like right off the bat, and you are one of them! Thanks for the - always useful - content!
It's great to have a more advanced React expert who isn't completely opinionated and telling you do everything his way because it's the "best" way.
Finally reactive concepts from angular comming to the other frameworks as well! 🙌
For people who use Vue or Svelte this feels like 1990
that thumbnail, looks so promising
It would have been a wonderful explanation of you link signals with refs in vue, as both uses proxy under the hood, but great explanation loved it ❤️
`@preact/signals-react` does support fine-grained updates - just omit the `.value` property when using signals in JSX: Filter: {filter}
How does that even work? React updates the DOM by re-rendering. It can't update single DOM elements individually?
I had read that it skips the virtual DOM and updates the DOM directly but I don't know for sure. You can update the signal without the re-renders because the signals are objects with value property. You are only passing a reference to this object and unless you access the .value property, the DOM does not re-render. However you can still render the value if you omit the .value, as Jason said.
Jack as usual your research is excellent and you deliver in spades. Unfortunately, my key takeaway here is that Ryan is a friggin' genius and now that SolidStart is slowly chugging along towards a production-ey state, the rest of the class is growing restless.
Youve come along ways man and can tell your zeal for what you do, cant thx you enough for not holding back the wealth of knowledge
Nice video, I would be interested to see the different lighthouse scores of these solutions. maybe even a performance analysis for each implementation :D
Pretty sure in release mode they would all be 100s. There just isn't enough content, CSS or data. There are no images. In the non-SSR versions there are not layout changes, and even in CSR there is only one.
Great talk. thank you Jack!
I guess the reason solidjs, qwik needs signals based on how they update dom. Updating states subscribed by a component followed by full re-render of component , that's why we can't say it's fine grained state update. However, qwik and solidjs only updates some point of declaration in single component , which makes they can fine grained states management. For support their architecture, signals seems inevitable
Hey, cool, Jack is representing team right side panel! My brother!
Still getting used to it. But the code not bouncing around on video was compelling.
Thanks for sharing, Jack!
Love the snow in the background Jack
I'll waiting this video for a long long time! Yeah!
Really loving Solid Start. 👍
And somewhere under a palm tree, a Java Spring Enterprise developer is sitting quietly, drinking sambuca. The one who understood life, he is in no hurry :)
THANK TO THE PREACT TEAM!
Appreciate your great contents! Now Jotai is even better with signal
Signals are quite similar to events ... And we can reimplement signals "easily" by using (react-mitt) library ... However, signals may lead to bad practices
Would love to hear you thoughts on this
Oh, Qwik's code - cool!
17:44 - you could show the DOM nodes updating in the element inspector
That's true. In hindsight I should have done that.
Thank you for this video. I do imagine time you need to get all versions work and captured.
I’d be also happy to see some comparison to svelte and vue. Anyway thanks!
Thank you for the nice video Jack!
Great video as always
A small correction, svelte uses the preact/signals core package
My bad.
i like the way you compare it in other libs too
Signals are also coming to Angular
I am happy react and jotai user, but I should look into solid, looks interesting 🙂
Is there a way to understand how the signals work under the hood without actually reading the source code? I tried first, but it feels overwhelming. I never worked on a JS library, so don’t even know where to look in the repo.
At the same time, I wanna understand how these technologies work on a deeper level, because all the videos about Signals I’ve seen so far only explain the API and how to use them, but not how they work and why they are so cool and better than the V-DOM
The video that got bumped to release this video was a re-implementation of Jotai, so yeah, it's coming next week.
Look for Ryan Carniato's articles "A Hands-on Introduction to Fine-Grained Reactivity" and "Building a Reactive Library from Scratch".
Check Ryan's channel. He had a long video explaining all this in depth.
HI @Jack Herrington! I found a little bit confusing the function `routeData` because the 1st thing we do is create this array destructuring with [users] on it, but then inside our createResource 1st parameter the function we pass returns a object with property e value for users.
How it works for the array destructuring for createResource return object to get the 1st value of the returned array?
Sorry if my question is a bit confusing too...
But I wanted to understand how that `{ users }` object go to the first value of the returned array on line 13 at 9:15 of the video timeline.
Thanks!
Great video Jack, as always!
Care to share more about your terminal, looks like a modified version of vscode's? I like the fact that it shows node version and other useful stuff
It's a combination of zsh, oh-my-zsh, and oh-my-posh for the prompts and then Fig for the autocompletion.
The gymnastics some go to instead of simply move to Solidjs... React was a stepping stone in the age of web development, let's move on to the next already.
You can’t expect big corporations and products to just move to something that new even if the transition is smooth. Solid is great, but lacks React’s community, ecosystem and meta-frameworks. For example SolidStart has a long way until it surpasses or even becomes Nextjs :)
Happens every time, same thing when react started. Companies where still using angular or even jQuery.
The big corporations are made of people and have developers that can choose the better tech, they just need a bit of courage. Starting a new thing with react is absurd given how ineficient it is.
Most of the time it's logical to stick with something that's "good enough" no doubt signals are much more performant. But unless something is so old/niche they have trouble finding devs to maintain it. Or has such bad performance that it warrants a rewrite/retool. Then corps will probably stick with react. And that's no problem if it works for them. Big eco-system, good dev-ex, developers still willing to support it. So it doesn't make sense to spend time and money retooling it to a different framework.
Hello Jack, I am your fans from Macau. I wnna ask you what is your theme of VScode? I really love it, can you share with me please? thank you!
Thanks and really nice. Can we move the array values as separate child component to see how Signal subscribe and works in preact ? seems Signal is global state and hope it may render only child. Please let me now your thoughts.
Cheers Jack
I already find filtering in React so easy. It’s just JavaScript but Solid looks pretty sweet though. Makes more sense to me than svelte.
Well, in this case if you want to do it right you should use useMemo, so it's not "just Javascript" in React.
Incredible video again 👏
Jotai can do lot of things really it's a great library and integrations are really cool.
I started using Jotai during the first release, replacing Apollo client state management with it, and it solved a lot of problems without a ton of boilerplate. I'm so happy to see it's still getting love to this day!
Love you man
Thanks!
Jack, looking for some feedback. If building a large enterprise app, and you had a choice of Zustand or Signals, what would your pick be?
For React? Zustand all day.
Mind blown 🤯
There is a sudden cut at the moment when you are going to show the re-renders with the profiler in the example with Jotai
Sorry about that. I'm not the best editor.
Hopefully solid steals some of the react ecosystem
Just Amazing
What's your vscode theme?
I notice you destructure the User component props in solid. If I'm not wrong, we should not destructure the component props in solid because it won't be reactive again. Can you confirm this?
In this case the items in the array of the signal are not in themselves reactive. So in this case we need the For to be reactive and nothing else. So I think it's ok in this case.
Vue does it in so much better way(not just in state management) but still ppl looking into react that implements layer on top of another layer
Hi, do you know if this is supported in nextjs? Tried multiple libraries but no luck
Is it accurate to think of reactive state management as 'use this variable x and all the changes that may happen to it'?
Yeah, kinda. Like watch variable X.
Your React `useRef` example for updating innerHtml wasn't done correctly.
What font do you use? Thank you for the video
Great video as always @jherr.
In case of both Solid-Start & Qwik-City the signal data will be computed on the server before first render, apart from the actual filtration that will be done on the client.
Is there a way to run the computed on the server for lets say the preact or jotai signal if used with something like next.js?
Great question! You can definitely run state managers like Jotai on server with NextJS, but, your going to have to do the async work for them AFAIK, so that you can block on the async work in the getServerSideProps AND you will need to transit the data through server side props and initialize the atoms on startup on the client. So... not easy, but doable.
@@jherr thanks for the reply.
That is why I am more keen on the new frameworks now, as they have started from scratch their solutions are alot simpler and elegant.
Most features in react.js now feel like monkey patches.
@@NosherwanGhazanfar I know what you mean but, dang, React has a killer ecosystem around it.
In the Solid example, is there any particular reason to wrap users in "{ users }" in routeData return statement (What creates another object with key: value pair users: users?) then to destructure it in Home function? Wouldn't it be more simple to return directly the users array then assign it to users const?
I think Solid is expecting an object there.
FYI: In this situation you would typically use `createRouteData` (SolidStart; which wraps `createResource` (SolidJS)). And users isn't an array. It's the callable part of `ResourceReturn`, i.e. the signal that returns the user array once it is ready and updates it after a refetch.
@@PeerReynders Thanks for the info, I really appreciate it.
Can we used signal in react ? Can we used preact signal package in react ?
Yes, the @preact/signal-react package is meant to be consumed by React.
Can you make a video about 'React Forget', it apparently makes React apps more performant by reducing rerenders?
AFAIK the only thing that has been released about React Forget is that video. Is there a way we can try it out?
6:45 - Through what kind of black magic does useRouteData link with routeData?
Nothing magic. The server stores the output route data in a script tag on the page, which probably puts it in a global, and the useRouteData hook fetches that data from the script tag.
@@jherr Ah, I get it, after reading the documentation I see it says "SolidStart's file system routing allows components defined under the /routes to define a routeData function". And you actually mentioned it too at @5:24 but I somehow missed it, sorry. So it searches by convention for a function named "routeData" exported by your route file in the routes folder. I wasn't sure how would Solid know to invoke the custom routeData function since I could not see any explicit registration or call to this function. Not familiar with Solid or Next.js.
Thank you for the reply by the way!
“Signals” will be great if “signals” is not tied to jsx, react, vue, solid, svelte, angular, …
Advantage of framework/library independent “signals” is that developer can (1) switch from react to solid or others (2) test state management without loading up all these e2e… just use plain javascript test runner like mochajs or jasminejs.
Yes!!!
You can use Solid or Preact Signals without JSX or anything for rendering.
Solid under the hood uses another library from its creator Ryan Carniato called dom-expressions. You can absolutely separate them.
And the mention of Preact's Signals in Svelte also shows how flexible it can be (used in a JSX VDOM library and in a compiled, custom DSL framework).
Ryan Carniato has a few videos introducing Solid where he starts from signals in plain JS, manipulates the DOM directly, and finishes with all the Solid JSX stuff, so you can see how it is added and work together.
Based on Alex Lohr's article "Testing Solid.js code beyond jest" I was able to do that with just uvu in my solid-bookstore-a "Segregated UI in Action with SolidJS" repo.
You just have to run the signals under a reactive root (`createRoot`; SolidJS) in the test code. Word is that separation will even be easier with SolidJS 2.0.
Doesn't Solid do computed values automatically if you assign a value to a function which calls the original state within it? Is the createMemo needed?
yes. Create memo is just if you don't want to compute it over and over again. Memo stands for memoize.
Yes, and in React you can technically just have a variable in your component function that uses a state variable, but it will also recompute on every render (even if the value of that state variable didn't change). Of course you can use useMemo in React but then you need to define the dependency array.
It becomes more about how much changes and where it is used in your JSX.
Solid is often seen as more efficient by default, whereas React expects you to be explicit and opt in to performance optimisations.
As of latest next.js an today no need to add above text on each file
So one more reason to use Jotai. Can you please share if Jotai is reliable for production product or internal only? how you take that kind of decision in general?
I can't think of any reason why it wouldn't be reliable in production.
"What are they?" - That's why I am here 😂
Well, hopefully by the end you should know. :)
Signals rock. Sync reactive state. Use Rxjs for async (or also for sync if you want)
Please i just built an app in react, utilizing signals but I get this error => { 'default' is not exported by react/jsx-runtime, imported by node_modules/@preact/signals-react/dist/signals.module.js } any time I run vite build, I have searched but couldn't get any answer... Would appreciate if you can help me please
You should check with the preact support channel.
@@jherr ok, thanks
Had to use CRA for now, until i figure out the solution!
So we are here because directly manipulating the DOM with vanilla js was too hard and untidy right? We're back to server rendering but seems like a lot of effort just to render some html
We're here because React convinced everyone that we should think of our application in terms of components that manage their internal state and UI/view.
If you only care about the server rendering side, then using another programming language and their web frameworks will probably be a better experience for you.
But many devs want to use JS and write code to use on the client and server (to avoid writing two apps).
Thankfully there's lots of great options now with all these meta-frameworks.
If you want a bit of both, I'd suggest Astro, where you can use components and still focus on vanilla JS
Vuejs is so much more elegant and readable in its writing than Solid, I don't understand the current craze for this library
react/v-dom is going to be for boomers soon
v-dom is dead.
💚
How would you implement something like rxjs' `switchMap()` for async results that can return out of order, and you only care about the most recent request? Or `debounce()`? Is it essentially a bunch of bookkeeping with imperative code?
The solid-primitives package implements `debounce` (and `throttle`) if you want to look at the source code. Solid signals are fine-grained reactive state while RxJS is about event streams. In RxJS terms Solid signals are Hot Behaviour Subjects because they hold current state and are multicast.
@@PeerReynders That's my point, it seems like a subset of what rxjs does (synchronous mapping). Once you add a (framework specific?) lib like you mentioned it's no longer 'simple'.
RxJs can be equally fine grained, am i missing something?
@@adambickford8720 Initial versions of Cycle.js were based on RxJS. But in 2017 Andre Staltz (André Medeiros) felt that the RxJS default model of cold, unicast observables wasn't a good fit for UI and replaced them with xstream ("Why we actually built xstream").
RxJS is about asynchronous event streams while SolidJS's signals are about (largely synchronous) reactive state management (state + change propagation)-so the focus is somewhat different.
They solve a problem that they created it. I went back to vanilla and left react for companies with 100 developers
What's the name of that font, wow it's so attractive in coding
JETBrains Mono
somehow sound like Rxjs from angular ?
Here's one for you - Why should we care about signals? React is pretty fast with regular updates. Is the performance gain that significant?
It's not so much the performance, it's the lack of dependency arrays and the ability to put signals and computed signals and effects wherever you want them.
@@jherr Thanks for the reply I appreciate it.
@@wojciechjerczynski8951 No problem at all. I get your point for sure. I don't think signals or fine grained updating alone are enough for me to bail on React.
Among the apis presented in this video, in my opinion, the best by far is preact/signals
By invoking the value using the .value property it is possible to destructure the signal when passed as a prop to another component (one of the most annoying parts of the solid, which brings with it other even more annoying problems such as the need for a helper function to declare default values for props), -it is possible to invoke the signal value inside an effect without adding the variable as a dependency using the .peek() method (something impossible with solid)- *as @ryansolid made me aware, it is possible to do the same with signals in solid using untrack*, it is possible to invoke the signal value inside the jsx reactively only using the variable directly without calling any method or property and on top of that thanks to the .subscribe method it becomes compatible with Svelte without any modifications
Do you like making `isSignal` calls in all your components to determine what is getting pass in is a Signal or not, or enforcing that your component props only accept Signals? Do this for a while and I wonder if opinion will change a bit. Qwik made the same call as well after experiencing this. The thing is you can use Solid this same way passing Signals and destructure props as you want, but it is generally seen as undesirable. It adds a different sort of complexity when authoring universal components. I speak to this having gone down this path for quite some time and wanting to avoid it with Solid, but I suppose only time will tell.
Also small correction we have `untrack` so peeking values is definitely possible in Solid, in fact this is mechanism for how components are untracked top level.
"it is possible to invoke the signal value inside an effect without adding the variable as a dependency using the .peek() method (something impossible with solid)"
Not true, you can use either `on` to specify dependencies to track , or `untrack` to not track signal inside the effect.
Example using `untrack`, to not track count signal:
```
createEffect(() => {
const untrackedCount = untrack(count);
const trackedInput = input();
console.log(untrackedCount);
});
```
Example using `on`, to track only input signal, which results in the same outcome as `untrack` example above:
```
createEffect(
on(input, () => {
const untrackedCount = count();
console.log(untrackedCount);
})
);
```
@@ryansolid Yes, I prefer restricting the type of a value to ensure it works in exchange for being able to destructure props and set default values without needing a new boilerplate
But I imagine it's easier to speak from my position that I don't work with OSS and use typescript in my projects
Thanks for letting me know about the untrack, I'll update my comment to avoid misinformation
@@ryansolid That's a pretty silly straw man; in the same way we don't need `isString` or `isNumber` prop type checks in all of our components, we do not need `isSignal` littered everywhere. TypeScript has solved this exceptionally well, at scale, for most of the past decade. Manually opting into runtime checks, rather than leaning into de facto standard build tooling, is not only silly but completely unrepresentative of the ecosystem at this point. It's really a non-issue.
@@ryanchristian2623 So you are suggesting that you just make the props only accept Signals? Are you concerned with splitting the ecosystem for those who don't use signals? Like if I'm making a general component library like MUI for Preact what is my best approach?
I've used frameworks like this, like Surplus. And it is a thing even without considering splitting the ecosystem. Technically the same is true of our Primitive Composition in Solid. If we made a `createInterval` we'd need to decide if the the delay takes a number or signal of number. Yes we typically defer to wrapping functions here. But it is an interesting question.
Signals? The thing that C has had since 1970-something?
Plz make videos how we make API in GrapQL plz ASAP
Signals really seems to be the future when using jsx, especially when compared to the react model
But it seems to me that it is possible to go much further by dropping jsx altogether and moving dependency analysis to the build like Svelte does
As Ryan Carniato himself (creator of solid) said, the implementation of signals has some disadvantages because the signals, due to the need to manage their own dependencies at runtime, already have a default minimum size, as they are natively disassociated from the component, it is not possible to have a visualization of component lifecycle and make the framework hostage to a single state management api
Svelte on the other hand to avoid this differentiates local state created with the let keyword from shared/composable state created with any api that obeys a specific store contract whether it be the native implementation of the stores framework or any other external one (preact signals for example)
The JSX is essential to the DX for me.
Svelte does so at the cost of dynamic dependency graphs. I trust there will be solutions to this in the future at some point that use a hybrid but without perfect compiler analysis across every file static graph analysis is at a disadvantage. Even with this book keeping due to being able to have more granular execution and dynamic graphs you find runtime systems generally faster than compiled today. I suspect the future is hybrid.
Hello, this is your daily reminder to not destruct props in solid 6:58 thank you
Ok, my bad. I thought I was ok because the data itself going to the component was not reactive. But this is a stylistically defensive thing for Solid?
@@jherr this is going to show you a warning if you use solid eslint plugin
@@JLarky Cool. Good. Though... Not sure why that didn't show up since I was in a solid-start app. Maybe because my VS Code wasn't running with this project as the root. Hmmm... Ok. Thanks again for the reminder.
@@jherr I'm not sure if it's even in SolidStart yet, I know that it's there in solid playground now
Looks like react people always try to invent vue
😁
I've seen Solid and Preact both credit Vue as part of their inspiration for their signals implementation.
Vue should definitely be given more credit than they get. It's also interesting that you can use JSX with Vue, if that's what you really like about React.
@@IainSimmons yes composition API makes it look less ugly and react-like. Imho Vue3 stylistically and by simplicity beats angular and react. No manual rendering dependencies, no ugly rxjs observables - just reactive variables and objects. Vuex was ugly. Now it's fixed. Looks like Vue is the best now.
Small, unimportant correction: You don't have to use in SolidJS. You can use .map and any other array method on signals-- just like you can use ternaries instead of . *Edit: See Correction Below!!!*
The utility components are provided for better DX and performance.
EDIT: *Correction* You can't set up a component with a ternary, but you can use one inside the return statement in {brackets}. A ternary will mount your component correctly, but it won't respond to any changes in the signals. I couldn't find any gotcha's with though-- it just seems to be more performant and easier to write than a .map.
Oh awesome! I was working of an old playbook. Thanks!
@@jherr So, I can't find any reasons other than performance and DX to use over a map, but I realized that setting a component up with a ternary will not respond to signal reactivity. This is because components are simply set-up functions that never run again once they are mounted. I corrected my comment.
Sorry for the misdirection!
@@zombiefacesupreme Ah, ok.
@@jherr actually replying to @zombiefacesupreme, but to you as well since I want to see you to see it.
Yes early conditional returns don't work because components are setup functions (only run once). But as long as boolean/ternary expressions are wrapped in JSX, they are compiled to ``, therefore be reactive.
```
function App () {
return
{condition ? : }
}
```
This is a great explanation. Thank you!!
I think he just went over this on the stream, so I have no excuse lol.
create-fast-context better 😎
I don't really understand the hype for Signals, just a rebranding of an Observable?!
Observable + Fine Grained Rendering, basically.
I appreciate it but, having moved to React from Vue for almost two years now, I don't understand how this is becoming popular since Vue has been doing this for a while now. React is nice of course but I always liked Vue better and I wish it was the more popular option
All syntaxes but the Solid one look gross
Why do people always show the state as a global in these signal tutorials, aren't final variables known to be a bad idea for decades already?
So much confusing knowing all these frameworks.
I wish Vue had better reactivity system. In Solid and React we write less code.
React has a sh*tty reactivity system. It's literally the worst of all frameworks.
@@LarsRyeJeppesen Then why it's Top Framework in world right now? Explain that.
@@LarsRyeJeppesen nothing about choosing the best framework is clear cut, any successful one exists for a reason. React is pretty good in its own ways
@@LarsRyeJeppesen Bull*it
What do you mean it had a better reactivity system? 💀 It has one of the best reactivity systems out there. Try using useState() outside of JSX file lol you can easily put Vue's ref() or reactive() in a different file and have global state management without any hassle. No useContext() or any weird quirks.
Over complicated as always. Code invented to make something simple difficult great job.
these are just trivial examples to get the point accross clearly, noone expects to actually code something this simple in such a complex way
@@jamescat2386 O look I reinvented observables called it something else and put in more complexity and syntax to show you how can you make trivial things hard. O and don't forget to tell everyone its the new hotness......
Qwik syntax is garbage. Solid is the only actual threat to React honestly
Poor Vue 🥲 left out again. Having one of the best reactivity systems out there, implementing the exact same "signals" functionality, it often gets overlooked in these discussions.