If this ships, it will change javascript forever

Summary

The 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

00:00

🚀 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.

05:03

📊 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.

10:03

🤝 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.

15:04

🌟 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.

20:05

🔧 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.

25:05

🔄 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.

Keywords

💡Signals

In the context of the video, signals are a data type that enables one-way data flow by modeling cells of state and computations derived from other state. They are used to track data in applications, making debugging and understanding application flows easier. The video discusses the adoption of signals in JavaScript through a TC39 proposal, highlighting their significance in creating efficient and reactive systems.

💡TC39

TC39 is a committee tasked with the standardization of JavaScript. In the video, the speaker is involved in a TC39 proposal to introduce signals as a standard data type in JavaScript. This process involves collaboration with various industry experts and developers to ensure the proposal is robust and widely applicable.

💡Data Flow

Data flow refers to the movement of data within a program, particularly how data is passed from one component to another. In the video, the concept of one-way data flow is emphasized as a way to simplify the understanding and debugging of applications. Signals play a crucial role in facilitating this one-way data flow by ensuring that data moves in a predictable and controlled manner.

💡Reactivity

Reactivity in the video refers to the ability of a system to automatically respond to changes in data. It is a key feature of modern web development frameworks like React. The introduction of signals in JavaScript aims to enhance reactivity by providing a standardized way to track and respond to changes in state and computations.

💡State Management

State management is the process of handling the state (data) in an application, particularly in the context of user interfaces. The video discusses how signals can be used for state management, allowing for efficient tracking and updating of application state. This is particularly relevant in the context of JavaScript, where managing state in a performant and predictable way is crucial for smooth user experiences.

💡Computations

Computations in the video refer to the derived values or operations that are based on the state of other data. Signals allow for the creation of computed signals that automatically update when their source signals change. This means that any computation based on a signal will be efficiently recalculated only when necessary, leading to optimized performance in applications.

💡Optimization

Optimization in the context of the video refers to the process of improving the performance and efficiency of code, particularly in terms of how data is handled and updated. The introduction of signals in JavaScript is seen as a potential optimization, as it could allow for more efficient state management and reactivity, leading to better performance in web applications.

💡Polyfill

A polyfill is a piece of code designed to replicate the functionality of a standard feature in environments where that feature is not natively supported. In the video, a polyfill for the proposed signals in JavaScript is mentioned, indicating that developers can start using the signal features even though they are not yet part of the official JavaScript standard.

💡Framework

A framework in the context of the video refers to a foundational structure or system that developers can use to build applications. The video discusses the adoption of signals by various frameworks like Angular, Tailwind, and others, highlighting how these frameworks are leveraging signals to improve their performance and reactivity.

💡Collaboration

Collaboration in the video refers to the process of working together, particularly among industry experts and developers, to create and refine the JavaScript signals proposal. The video emphasizes the importance of collective effort in standardizing new features to ensure they are practical, efficient, and widely accepted.

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