If this ships, it will change javascript forever

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments
Captions
after many years and suffering signals are finally coming to angular wait wrong video after a lot of effort and hard work signals are finally coming to Tailwind wait shoot wrong video again signals are coming to JavaScript if you're not familiar with signals we're going to go over them in a bit it's a really cool primitive for tracking data in your applications so much so that they've been adopted by angular they're being adopted in a new plugin by Tailwind but the thing we're here to talk about today is certainly not angular or Tailwind it's JavaScript and we finally have a real and honestly pretty promising proposal for getting signals in j yes itself let's take a look at the proposal and how we got here first when I was Google searching signals JavaScript this happened and I thought it was hilarious and I wanted to show it when you Google search for signals in JavaScript solid comes up which is a framework you might have heard of it's looks and feels a lot like react but it is signals based instead of reaction like rendering based so it's way way more performant solid regularly wins like every performance Benchmark and their signal stuff is a big part of how they were able to do that I also want to make sure it's known I wasn't just trolling with the Tailwind thing this is something I plan on covering the video probably won't be live before the general JS signals one but uh signals for Tailwind video coming soon we're here to talk about today is the tc39 proposal for signals written by Eisenberg effect at least this blog post is he's one of the big Advocates this is the actual proposal it has a bunch of stuff in it it's currently in stage zero so it's very very early like we're discussing what it even should look like right now but the contributor list is a really cool set of people it includes little Dan Daniel erenberg who is a major contributor to tc39 works at Bloomberg and is regularly involved in these types of things but as we go through this list there's even more interesting people we have Dominic who is one of the original react core team members and now he works at forcell on spelt yes one of the react team moved to versel not to work on react but to work on spelt which I think is awesome we have Eisenberg effect who is one of the like classic modern web Architects and web standards guys who wrote the blog post we'll be reading a bunch of other people like null vox populi I forgot what they do but they've popped up on so much that I am positive they are very very productive and involved in these things we got another interesting one Michael westr he's the creator of mobex which is one of the first more signal-based solutions for State Management in react for a long time we were in the Redux versus mobx Wars and in a lot of ways he arguably won even if mobx isn't more popular the patterns that he introduced have taken over so many things he also introduce stuff like emmer that is essential for modern web I believe he's currently working at meta but I might be wrong on that we also have Patrick JS everyone's favorite everything developer the guy who accidentally killed npm check out my video for that if you already haven't seen it and so many more awesome names including not limited to Ben Les who is the creator of rxjs which kind of standardized the idea of signals in JavaScript awesome crew of people check out all of them they're all within some of my favorite devs I'm actually amazed how many dope people are involved in that list but we need to understand signals before we go any further we're minutes in and haven't actually talked about them yet so in August of last year I mentioned that I wanted to begin pursuing a potential standard for signals in tc39 today I'm happy to share that a VZ draft of such a proposal is publicly available along with a spec compliant policy fill this is really cool this means you can start using it today and it will be polyfilled to work the way browsers currently work there's also a disclaimer up here that it's a preview of an in progress proposal and could change at any time don't use this in production don't challenge me I swear every time I see this it makes me want to use it in production more it's like the do not use or you will be fired and react it's like that you're you're just telling me I should use this or at least making me want to what are signals though we haven't even talked about that part a signal is a data type that enables one-way data flow by modeling cells of state and computations derived from other state in computations this if you're a react Dev might sound kind of familiar but usually this is with components where you have the root component at the top and it passes things down but you can't really go back up and that's the magic of react is the one-way data tree the reason that this is so valuable is it makes debugging and understanding your application's flows significantly easier if you don't have things going up and down constantly you have to trace these really crazy data Trails across your application react does that not just with data but with the actual like application and react component modeling so your whole UI has that top to bottom approach it makes debugging easier it makes reasoning about your logic easier it makes compiling it to be more efficient easier it makes a lot of things easier if you don't allow for data to go two different directions like imagine a component that could pass props to its parent it makes things way more complex and that complexity has been the default of the web for a long time react challenged that for UI Frameworks signals is challenging that for state and data across all JavaScript applications the state and computations form an as cyclic graph where each node has other nodes that derive state from its value the syncs and or that contribute state to its value which are sources a node may also be tracked as clean or dirty what does this all mean let's take a simple example imagine we have a counter we want to track we can represent that as state cons counter equals new signal. state 0 we can read the current value with get so console log counter. getet this will log out zero cool and now we can change the value with set counter. set one and now when we log it we get the new value now let's imagine we want to have another signal that indicates whether our counter holds an even number or not cost is even equals new signal. computed and in here counter. getet and one or zero this will now give you a new signal of is even that will change whenever counter. getet changes and here's the magic of signals is that the change here cuz if counter gets changed the value of counter. getet is now different and these signal computations are smart enough to propagate those changes because when you call counter. getet inside of a signal computation it knows to recompute the signal so this signal is dependent on this one so when this one changes this one changes and now this fires computations aren't writable but we can always read their latest value so you can't write here either that's the important thing you can't do is even. set you can only get it because it's a computed value it's effectively read only console.log is even get false counter. set then when we log it again it's true in the above example is even is a sync of counter and counter is a source of is even good we can add another computation that provides the par of our counter here's a fun one we have par which will say even or odd it's a string depending what the value here is so we call is even. getet and then it's even if it's true and odd if it's false Again by calling this is even. getet in here this signal primitive knows that whenever this changes it needs to recompute this whole thing and change the results of this guy so now we have parity sourcing is even and is even is a sync of parity we can change the original counter and it state will flow unidirectionally to parity so I'm going to see how valuable this is just like react components you have a component at the bottom and you can wrap and wrap and wrap but when that one component in the middle changes everything's hand this is that for your data it's so powerful to have variables where when things change within them anything depending on them also changes accordingly instead of like another way to think of this if I just open up some crappy JavaScript here something we've all seen before is like const x equal 2 cons doubled = x * 2 what if this isn't cons what if it's let and I do x + 5 or X+ 4 xal X+ 4 doubled is still going to be a different number because doubled was created at this point in time so there's no way to change X such that doubled also updates by default the magic of this new model is that if we make this a sync and then we have other things that are computed off of it one change will persist through all of the other signals that have been bound this is very very powerful stuff we're already getting a really good question which is this is valuable but is it valuable enough to be on the web platform I'll make the argument of yes not just because everyone should be using this and the polyfills aren't good enough or something like that specifically because if this is introduced in the browser there are a lot of optimizations the browser can do to make it really really efficient and really performant and that's what I'm excited about with this being in the browser is the potential of this being really really fast it's already pretty fast but if you The optimizations Happening where like memory assignments aren't being made where they're not necessary and such and everything's computed on the Fly this can fly everything we've done so far seems like it could be done through normal function composition but if implemented that way without signals there will be no Source or sync graphs behind the scenes so why do we want this graph what's it doing for us recall I mentioned signals can be clean or dirty when we change the value of counter it becomes dirty because we have a graph relationship we can then Mark all of the syns of counter dirty as well and all of the sinks that those have as well and so on and so forth this is where that propagation becomes magic the ability to identify which things need to be changed and just change them all synchronously as a result of that initial Change magic and makes your data update model much easier there's an important detail to understand here the signal algorithm is not a push model making a change to counter does not eagerly push out an update to the value of is even and then via the graph and update to parity it is also not a pure pull model this is an important thing it's not just going to force everything to be in the updated State and it's also not going to recompute every time you call it it's somewhere in between reading the value of parity doesn't always compute the value of parity or is even rather when counter changes it pushes only the change in the dirty flag through the graph any potential recomputation is delayed until a specific signals value is explicitly pulled really cool stuff we call this a push then pull model so by marking everything is dirty like right here we're not using doubled for anything so technically it never actually has to compute this value it doesn't know what double is but if we wanted to use this by like I don't know console.log doubled now it's actually going to do the compute it's not going to do the compute here where we assign it it's going to do the compute here where we actually call it and then when we change it here to X = X+ 4 only this has changed the things that it's dependent on haven't changed until we use them obviously this would be like double. getet instead and we' have all the signal syntax and everything but the point is that the actual computation here the actual work being done after the change only occurs if and when the thing that is dependent on is being consumed it's very lazy which is a good thing lazy thank you to zcb Q QJ qg cool thank you for pointing out that it is lazy because that is a very important way to describe it it is lazily evaluated because we don't need to do this compute unless we know we actually need the values there are a number of advantages that arise out of combining an a cyclic graph data structure with a push then pull algorithm them here's a few signal. computed is automatically memorized if the source value hasn't changed there's no need to recompute that's really cool there's no idea of like a memo we don't need one because things are lazy anyways unneeded values aren't recomputed even when sources change if a computation is dirty but nothing reads its value then no recomputation occurs false or over updating can be avoided for example if we change counter from 2 to four yes it is dirty but when we pull the value of parody his computation will not need to rerun because is even once pulled will return the same value for four as it did for two that's a really cool point I hadn't thought of actually which is that with this chain where we have is even if you assign a new value such that is even needs to recompute to be sure it's still the same as long as the results the same you don't have to rerun this one after that's a really cool thing I hadn't thought about there that is a good point we can also be notified when signals become dirty and choose how to react also very useful you can put listeners on all of these things these characteristics turn out to be very important when efficiently updating user interfaces to see how we can introduce a fictional effect function that will invoke some action when one of its sources becomes dirty for example we could update a text node in the Dom with the parody so here we have an effect everyone's favorite I know us react devs get triggered when we hear this word but doesn't have to be that complex I promise so here we have node. text content equals parody doget since we put this in an effect now whatever functionality we put in here reruns whenever this signals response changes so if we switched from two to four it's not actually going to rerun if we change it from two to three it will actually rerun and it will update the text content so the first time this runs the node text is updated with odd because the default value is one so it's odd the effect watches the Callback Source parity for dirty changes now we set counter to two this dirties the counter graph which means that this needs to rerun and this time when it reruns it sees that this is different so it actually sets this value this time but if parody. getet doesn't respond differently then it's not going to trigger all of its dependencies so we see here counter out set four since this results in par having the same answer because the is even check before it has the same answer this never gets run again theer begins to re-evaluate the effect call back by pulling parody parody begins to evaluate by pulling is even is even pulls counter resulting in the same value for is even as before is even as marked clean because a even is clean parody is marked clean and because parody is marked clean the effect doesn't run and the text is unaffected nice and easy hopefully this brings some clarity to what a signal is an understanding of the significance of the combination of the as cyclic source and sync graph with its push PA algo I would say so so who's been working on this late in 2023 I partnered with Daniel ringberg Ben Les and Dominic ganway to try and round up as many signal Library authors and maintainers of frontend Frameworks as we could you picked a good group anyone who expressed an interest was invited to help us to begin exploring the feasibility of signals as a standard we started with a survey of questions in one-onone interviews looking for common themes ideas use cases semantics Etc we didn't know whether there was even a common model to be found that's another scary point because everyone's emed signals in their own weird chaotic ways I'm pumped that they were able to find something as they say here to our Delight we discovered that there was quite a bit of agreement from the start over the last 6 to S months detail after detail was poured over attempting to move from General agreement to the specifics of data structures algorithms and an initial API you may recognize a number of the libraries and Frameworks that have provided design input at various times throughout the process so far hular bubble Ember fast mobex preact quick rxjs solid star beam felt view whiz and more these are all the Frameworks that are considering signals or already have them not a bad list speaking of which it is quite a list and I can honestly say looking back at my own work in web standards over the last 10 years this is one of the most amazing collaborations I've had the honor to be a part of is truly a special group of people with exactly the type of collaborative and collective experience that we need to continue to move the web forward important if we miss your library or framework there's still plenty of opportunities to get involved nothing is set in stone we're still at the beginning of this process scroll down to the section titled how can I get involved in the proposal to learn more good call out so what's in this proposal The Proposal on GitHub includes backgrounds motivations design goals FAQ proposed API for creating both state and computed signals proposed API for watching the signals various additional proposed utility apis such as things for introspection a detailed description of the various signal algorithms as well as a spec compliant polyfill covering all the proposed apis so this isn't just a proposal this is a thing you can go use today interesting that their proposal does not include an effect API since such apis are often deeply integrated with rendering and batch strategies that are highly framework and Library dependent very good call out here a blank pocket boring standard effect would need very different implementations for different Frameworks depending on how and where they rerender things so it doesn't surprise me that didn't make it in like they call that out here however the proposal does seek to define a set of Primitives and utilities that Library authors can use to implement their own effects on that note The Proposal is designed in such a way as to recognize that there are two broad categories of signal users application devs and Library framework INF forevs thank you for calling this out early this is a thing I've been shouting about for a while which is that the experience of these two groups varies so widely even within well-loved tools I obviously am a huge typescript advocate I've been pushing typescript forever but I've done that largely as an appdev now that I'm working more on libraries I see why people hate typescript because getting all of your types right can not only be its own massively difficult challenge while building a library or framework it also can force you into certain directions with your code that you might not have gone into otherwise I know I'm far from the only Library Dev that's had to make significant changes to their apis and their sdks just to make sure that their stuff can be made typ safe with typescript so these things are very influential on both of these sides and it's not often enough that this is called out early in this way because the needs and goals and interests of these groups vary wildly so making sure both are happy very important apis that are intended to be used by application devs are exposed directly from the signal name space these include signal. State and signal. computed apis which should rarely if ever be used an application code and are more likely to involve subtle handling typically at the infro level and layer are Expos through the signal. subtle namespace I actually like that I'm not sure if subtle a word that is easily enough translated would be my big concern is like internationalization for this like that this word might not communicate to non-native English speakers well enough what it's for that's my only concern here but I do actually really like the use of subtle for this and also that it's lowercase and everything else is uppercase these include things like signal. subtle. Watcher as well as signal. subtle. untrack as well as the introspection apis oh crypto do subtle so this is already a thing fun this blog post is really useful normally I would skip an ad but uh Rob and crew are killing it with this so if you're interested in a web component engineering course check that out link is in the description for the blog course and you can find this in there youall know I'm the worst place to learn about web components CU I just don't think they're good but uh if you want to figure out more about them this is a good place to do it anyways as an app Dev how do I use signals many of today's popular component and rendering Frameworks are already using signals over the coming months we hope that framework maintainers will experiment with re-platforming their systems on top of this signals proposal providing feedback along the way and helping us prove out whether it is possible to leverage a potential signals standard If This Were to work out many app devs would use signals through their chosen component Frameworks their patterns wouldn't change however their Frameworks would then be more interoperable like reactive data interoperability imagine that like you write react code and then you have a spelt component or a solid component and it can use the exact same state model and the exact same update layer as your react code is using that's really cool exciting opportunities there it's also smaller because signals are built in and don't need to ship JS at least if this ships it will be the case and hopefully faster because native signals as part of the JS runtime have the opportunity to optimize a ton of stuff Library authors would then be able to write code using signals that works natively with any component or rendering library that understands the standard reducing the fragmentation in the web ecosystem application Deads would be able to build model and state layers that are decoupled from their current rendering Technologies giving them more architectural flexibility and the ability to experiment with and evolve their view layer without rerunning the entire application don't MVC this for me man we were agreeing don't don't use this as a way to encourage MVC so let's say you're a Dev that wants to create libraries using signals or who wants to build apps using them instead what would this look like well we've seen a bit of it already when I explain the basics of signals through the signal State and computed apis above these are the two primary apis that an application developer would use if not using them indirectly through a Frameworks API instead they can be used by themselves to represent Standalone reactive State and computations or in combination with other Js constructs like classes here's a counter class that uses a signal to represent its internal State no what part of why I love signals is they help FP don't don't force oop into here cool it works it does what it's supposed to you can still do dependence and so cool one particular nice way to use signals is in combination with decorators we can create an at signal decorator that turns an accessor into a signal as follows X function signal Target const get is Target we return the get get called that get set and init and when you init it makes a signal so now we have this helper signal decorator that we can just put over this signal accessor value zero and now this is just magically become a signal my issue here is like this code isn't complex enough that I'd want to abstract it but uh cool that you can weird but cool there are many more ways to use signals but hopefully these examples provide a good starting point for those who want to experiment at this state this is a cool call out that um setting on a getter plus one like this where we add one and then we set that that this could cause an infinite state in an infinite Loop when used within a computed or an effect the reason for that would be if this. val. set is part of something that is running because this. val. get changed this could Loop really rough this is not cause a problem in the current proposals computed nor does it cause a problem in the effect example demonstrated below should it cause a loop though or should it throw what should be the behavior this is an example of the many types of details that need to be worked through in order to standardize an API like this I like this call out actually at first I was like I don't agree with this being supported necessarily but the call out that he's bringing this up specifically so we can have conversations about it and how it should work this is a very responsible proposal where it's it's very considered of the the reality of the web dev world and not just trying to be like here's how we're doing this now I like this a lot and I hope more proposals are written this well in the future most have been pretty good thus far but this is dope so how do library devs integrate these things we hope that the maintainers of view and component libraries will experiment with integrating this proposal as well as well as those who create State Management and data related libraries a first integration step would be to update the library signals to use signal. State and signal. computed internally instead of the current Library specific implementations of course this isn't enough a common Next Step would be to update any effect or equivalent infra as I mentioned above the proposal does not provide an effect implementation our research showed this was too connected to the details of rendering and batching to standardize at this point rather the signal that subtle namespace provides The Primitives that a framework can use to build its own effects let's take a look at implementing a simple effect function that batches updates on the microtask Que let needs and Q equals true cons W new signal subtle Watcher if needs and Q false Q microtask I don't want to read microtask code I'm not paid enough for this I'm sorry if these are the of things you're interested in you have an awesome blog post to go read about it that's not the basics once you're into microtasks we're not in Basics land anymore one other fun API is subtle untrack helper this function takes a call back to execute and it ensures the signals red within the Callback will not be tracked feel the need to remind readers this is a names space that's designated for apis that should be with care and mostly by Frameworks are in for authors using this incorrectly will totally break your graph and result in things that are impossible to track so uh yeah with that said let's look at a legitimate use of this API many view Frameworks have a way to render a list of items typically you pass the framework in Array and a template or fragment of HTML that it should render for each item in the array as an appdev you want any interaction with the array to be tracked by the data reactivity system so that your List's rendered output will stay in sync with your data but what about the framework itself they must access the array in order to render it the framework's access of the array were tracked by the dependency system that would create all sorts of unnecessary Connections in the graph leading to false or over updating so imagine you have a list with items in it and you change one of the items in that list the whole list now has to rerender this is already kind of the case in react that's why we have keys to identify which things you should and shouldn't actually do the reender for but every framework has their different way of handling it and you might just want to untrack the list and build your own tracking for every item in the list kind of like how something like solid would do it so that's what I'm sure they're going to propose here let's see if the framework's access of the array were tracked yep it leads to the false or over updating but also weird bugs this is where lots of weird bugs tend to crop up even in react that's why keys are so important because if you do them wrong everything breaks the signal subtle untrack API provides the library author with a simple way of handling this challenge as an example let's look at a small bit of code from solid that renders arays funny that that got called out already which I've slightly modified to use the proposed standard we won't look at the whole implementation I've cut most of the code out for Simplicity hopefully looking at the high level will help explain the use case hopefully let's take a look map array items mapped length cool return new items which is list or empty array I and J which are all the new things we just defined new length is new items. length and now we're going to go through and untrack the existing stuff nothing in the following callback will be tracked we don't want our Frameworks rendering work to be affecting the signals graph cool so now we have this list and I'm assuming the ah I won't assume anything let's just read how it works first so now we're doing all work in here in order to make sure that any work we do and any values we access aren't going to automatically be Trac as we want them to be so we have an early Escape for empty arrays we have a fast path for New Creations and then we just read otherwise cool even though of AED I'm not even pretend I know what that word is supposed to be even though I've skipped the bulk of solid's algorithm you can see how the main body of work is done within an untracked block of code that accesses the array there are additional apis within the signal. subtle namespace which you can explore at your leisure hopefully the above example helps to demonstrate the kinds of scenarios this part of the proposal is designed for I think that makes sense specifically the idea that um the framework rendering shouldn't trigger things in the graph that part mostly makes sense but I wish I could see something here that is actually a signal to use to follow the data trail I'm sure Ryan carniato will have a lot smarter of things to say with this than I do here the instructions on how to get involved if you're interested check the link in the description to this article to learn more I'm not going to cover this directly but it is really useful and it's awesome they're calling out the need for help even with things like testing or reporting other signal implementations even if just examples a lot of opportunity for people who are really interested in this proposal to get involved good stuff so what's next we're still at the beginning of this effort in the next few weeks Daniel and Jan from Google and Bloomberg respectively will bring the proposal before tc39 seeking stage one stage one means the proposal is under consideration so right now tc39 isn't actually considering this proposal it's just in work once it hit stage one that means they're actually thinking about it as a formal group and as he says they're not even there yet you think of signals as being at stage zero the earliest of the early out of presenting a tc39 we'll continue to evolve The Proposal based on feedback from that meeting and in line with what we hear from folks who get involved through GitHub our approach is to take things slow and to provide ideas out through prototyping we want to make sure we don't standardize something that no one can use like web components I'm I'm sorry I have to sneak a web component dig in here I was nice earlier we'll need your help to achieve this with your contributions as described above we believe we'll be able to refine this proposal and make it suitable for all I believe a signal standard has tremendous potential for for JavaScript and for the web it's been exciting to work with such a great set of folks from the industry who are deeply invested in reactive systems here's some more future collaboration and a better web for all that was a post I had High Hopes but honestly I'm even more excited now that I've read that just seeing who's involved and how much they're considering both app devs and framework authors means the future of signals is bright let me know what you guys think in the comments are you excited or is this just overhyped Madness and until next time peace nerds
Info
Channel: Theo - t3․gg
Views: 194,041
Rating: undefined out of 5
Keywords: web development, full stack, typescript, javascript, react, programming, programmer, theo, t3 stack, t3, t3.gg, t3dotgg
Id: JvE_xQVIFF0
Channel Id: undefined
Length: 25min 53sec (1553 seconds)
Published: Sun Apr 07 2024
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.