If this ships, it will change javascript forever
Summary
TLDRThe transcript discusses the introduction of signals in JavaScript through a TC39 proposal, highlighting its potential for improving data flow and reactivity in applications. It emphasizes the collaborative effort of industry experts and the proposal's current stage, encouraging community involvement and feedback for further development and refinement.
Takeaways
- 🚀 Introduction of a TC39 proposal for signals in JavaScript, aiming to standardize a way to handle reactive state and computations.
- 🌟 The proposal is at an early stage (Stage 0), with significant industry collaboration and input from major contributors in the field.
- 🔗 The proposal includes detailed documentation such as background, motivations, design goals, FAQs, and proposed APIs for both state and computed signals.
- 🛠️ A spec-compliant polyfill is available for experimentation and feedback, allowing developers to start using the signal features today.
- 📈 The signal pattern is inspired by performance optimizations in frameworks like Svelte and the solid.js library, which prioritize efficient data flow and reactivity.
- 🔄 Signals enable one-way data flow, making it easier to debug and reason about application state by modeling cells of state and derived computations.
- 📊 The concept of 'clean' and 'dirty' signals allows for efficient tracking of changes and updates, only recomputing values when necessary.
- 🎯 The proposal aims to provide primitives for library authors to build their own effects, rather than prescribing a one-size-fits-all effect API.
- 🔧 The use of the `signal.subtle` namespace for APIs that should be used with care, primarily by framework authors and library maintainers.
- 🔄 The potential for increased interoperability and smaller bundle sizes if the standard is adopted across different frameworks and libraries.
- 📢 A call to action for the community to get involved in the development of the proposal, including testing, feedback, and prototyping.
Q & A
What is the main topic of the video?
-The main topic of the video is the introduction of a TC39 proposal for signals in JavaScript, which aims to enable one-way data flow and improve the debugging and understanding of application flows.
What is the significance of the Solid framework mentioned in the video?
-Solid is mentioned as a framework that is signals-based instead of reaction-based, which contributes to its high performance. It is often compared to React but is noted for its signals approach, which is a key focus of the video.
Who are some of the notable people involved in the signals proposal?
-Notable people involved in the signals proposal include Daniel Erenberg from Bloomberg, Dominic Gannaway who is an original React core team member, Michael West from Meta, and Ben Les, the creator of RxJS.
What is the current status of the signals proposal?
-The signals proposal is currently in Stage 0, which means it is in the very early stages of discussion and development. It has not yet been formally considered by TC39.
How does the signal data type work?
-A signal is a data type that models cells of state and computations derived from other state. It enables one-way data flow and can be either a source of state (signal.state) or a computed value (signal.computed). Changes in the source signal propagate to dependent computed signals.
What is the 'push then pull' model mentioned in the video?
-The 'push then pull' model refers to the way signals update. When a change occurs in a signal, the change is pushed through the graph to dependent signals. However, recomputation is delayed until a specific signal's value is explicitly pulled or accessed.
What are some advantages of using signals?
-Some advantages of using signals include automatic memoization, avoidance of unnecessary recomputation, the ability to be notified when signals become dirty, and the option to choose how to react to these changes.
How does the video suggest library authors could use the signal proposal?
-Library authors could integrate the signal proposal by updating their libraries to use signal.state and signal.computed internally. They could also build their own effects using the primitives provided in the signal.subtle namespace.
What is the role of the signal.subtle namespace?
-The signal.subtle namespace provides APIs for library and framework authors to build their own effects and handle advanced use cases. It includes utilities like signal.subtle.watcher for tracking signal changes and signal.subtle.untrack for executing code without tracking signal access.
What is the next step for the signals proposal?
-The next step for the signals proposal is to reach Stage 1 in the TC39 process, which means the proposal will be formally considered by the group. The proposal will continue to evolve based on feedback from TC39 meetings and contributions from the community.
How can interested individuals get involved with the signals proposal?
-Individuals can get involved by checking the link provided in the video description, which leads to a section on how to contribute to the proposal. Contributions can range from testing, reporting on other signal implementations, to providing feedback and ideas.
Outlines
🚀 Introduction to JavaScript Signals
The paragraph introduces the concept of signals in JavaScript, highlighting their significance in tracking data within applications. It discusses the adoption of signals by Angular and Tailwind, and the excitement around the TC39 proposal for signals in JavaScript. The paragraph also mentions the involvement of notable figures in the development community, such as Dan Abramov and Michael Jackson, and emphasizes the collaborative nature of the proposal process.
📊 Understanding Signals and their Data Flow
This paragraph delves into the mechanics of signals, explaining them as a data type that facilitates one-way data flow by modeling state cells and computations derived from other states. It draws a comparison with React's one-way data tree and discusses the benefits of this approach, such as easier debugging and improved performance. The paragraph also provides a practical example of using signals with a counter and demonstrates how signal computations propagate changes efficiently.
🤝 Collaboration on the Signals Proposal
The paragraph discusses the collaborative effort behind the signals proposal, involving developers from various frameworks and libraries. It highlights the importance of considering the needs of both application developers and library/framework authors. The paragraph also mentions the survey and interviews conducted to gather ideas and use cases, and the discovery of a common model among the diverse implementations of signals.
🌟 Utilizing Signals in Application Development
This section explores how application developers can utilize signals in their work, especially in conjunction with popular component and rendering frameworks. It discusses the potential for interoperability and smaller, faster code execution due to native signal optimization. The paragraph also provides examples of using signals with classes and decorators, showcasing the flexibility and potential for improved architectural design in applications.
🔧 Integration for Library Developers
The paragraph focuses on how library developers can integrate signals into their work, including updating library-specific implementations to use the proposed signal APIs. It discusses the creation of a simple effect function for batching updates and the use of the signal.subtle namespace for building framework-specific effects. The paragraph also touches on the importance of careful API usage to avoid unintended consequences in the signals graph.
🔄 Future Directions for the Signals Proposal
The final paragraph outlines the next steps for the signals proposal, including presenting it to TC39 for consideration and further refinement based on feedback. It emphasizes the slow and deliberate approach to standardizing signals to ensure their usability and practicality. The paragraph also calls for continued collaboration and contributions from the community to help shape the future of signals in JavaScript and the web ecosystem.
Mindmap
Keywords
💡Signals
💡TC39
💡Data Flow
💡Reactivity
💡State Management
💡Computations
💡Optimization
💡Polyfill
💡Framework
💡Collaboration
Highlights
The introduction of a TC39 proposal for signals in JavaScript, which aims to standardize a way to track data and enable one-way data flow in applications.
The mention of Solid, a framework based on signals instead of the traditional reaction-based rendering, known for its high performance.
The involvement of notable figures in the web development community, such as Dan Abramov and Ben Les, in the development and advocacy of the signals proposal.
The current stage of the proposal, which is at stage zero, indicating that it is in the very early stages of discussion and development.
The availability of a spec-compliant polyfill for the signals proposal, allowing developers to start using it today, albeit with the caution that it is a preview and may change.
The explanation of signals as a data type that models cells of state and computations derived from other state, offering a new way to handle state management in JavaScript applications.
The demonstration of how signals can be used to create reactive state and computations, such as a counter signal and a derived signal that indicates whether the counter holds an even number.
The concept of a push-then-pull model for signals, where changes are propagated through the signal graph only when a specific signal value is explicitly pulled or accessed.
The benefits of using signals, such as automatic memoization, avoidance of unnecessary recomputation, and the ability to be notified when signals become dirty.
The potential for browsers to optimize signal handling if it becomes a standard part of JavaScript, leading to improved performance and efficiency.
The collaboration between framework maintainers and library authors to explore the feasibility and integration of signals, leading to a wide range of support and input from the web development community.
The distinction between application developers and library/framework authors in terms of their needs and use cases for signals, and the proposal's consideration of both perspectives.
The proposed API for creating both state and computed signals, as well as for watching signals, providing a clear starting point for developers to understand and experiment with signals.
The explanation of how signals can be integrated with other JavaScript constructs, such as classes and decorators, to create more flexible and powerful reactive systems.
The discussion of potential issues and considerations in the standardization process, such as avoiding infinite loops and ensuring proper tracking of signal access, highlighting the thorough and responsible approach to developing the proposal.
The call to action for developers to get involved in the signals proposal, whether through direct contributions, testing, or providing feedback, emphasizing the importance of community involvement in shaping the future of the web.
The next steps for the signals proposal, including presenting it to TC39 for consideration and further refinement based on feedback and prototyping, showing the ongoing and iterative nature of the development process.
Transcripts
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
5.0 / 5 (0 votes)