If this ships, it will change javascript forever

Theo - t3․gg
6 Apr 202425:53

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

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.

Mindmap

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

play00:00

after many years and suffering signals

play00:02

are finally coming to angular wait wrong

play00:04

video after a lot of effort and hard

play00:06

work signals are finally coming to

play00:08

Tailwind wait shoot wrong video again

play00:10

signals are coming to JavaScript if

play00:12

you're not familiar with signals we're

play00:13

going to go over them in a bit it's a

play00:14

really cool primitive for tracking data

play00:16

in your applications so much so that

play00:18

they've been adopted by angular they're

play00:19

being adopted in a new plugin by

play00:20

Tailwind but the thing we're here to

play00:22

talk about today is certainly not

play00:23

angular or Tailwind it's JavaScript and

play00:25

we finally have a real and honestly

play00:27

pretty promising proposal for getting

play00:29

signals in j yes itself let's take a

play00:31

look at the proposal and how we got here

play00:33

first when I was Google searching

play00:34

signals JavaScript this happened and I

play00:36

thought it was hilarious and I wanted to

play00:37

show it when you Google search for

play00:38

signals in JavaScript solid comes up

play00:40

which is a framework you might have

play00:42

heard of it's looks and feels a lot like

play00:44

react but it is signals based instead of

play00:46

reaction like rendering based so it's

play00:48

way way more performant solid regularly

play00:50

wins like every performance Benchmark

play00:52

and their signal stuff is a big part of

play00:54

how they were able to do that I also

play00:55

want to make sure it's known I wasn't

play00:56

just trolling with the Tailwind thing

play00:58

this is something I plan on covering the

play00:59

video

play01:00

probably won't be live before the

play01:01

general JS signals one but uh signals

play01:03

for Tailwind video coming soon we're

play01:05

here to talk about today is the tc39

play01:07

proposal for signals written by

play01:09

Eisenberg effect at least this blog post

play01:10

is he's one of the big Advocates this is

play01:12

the actual proposal it has a bunch of

play01:14

stuff in it it's currently in stage zero

play01:16

so it's very very early like we're

play01:17

discussing what it even should look like

play01:19

right now but the contributor list is a

play01:21

really cool set of people it includes

play01:23

little Dan Daniel erenberg who is a

play01:26

major contributor to tc39 works at

play01:28

Bloomberg and is regularly involved in

play01:30

these types of things but as we go

play01:31

through this list there's even more

play01:32

interesting people we have Dominic who

play01:34

is one of the original react core team

play01:36

members and now he works at forcell on

play01:38

spelt yes one of the react team moved to

play01:40

versel not to work on react but to work

play01:42

on spelt which I think is awesome we

play01:44

have Eisenberg effect who is one of the

play01:45

like classic modern web Architects and

play01:48

web standards guys who wrote the blog

play01:49

post we'll be reading a bunch of other

play01:51

people like null vox populi I forgot

play01:53

what they do but they've popped up on so

play01:55

much that I am positive they are

play01:56

very very productive and involved in

play01:58

these things we got another interesting

play01:59

one Michael westr he's the creator of

play02:01

mobex which is one of the first more

play02:03

signal-based solutions for State

play02:05

Management in react for a long time we

play02:07

were in the Redux versus mobx Wars and

play02:09

in a lot of ways he arguably won even if

play02:11

mobx isn't more popular the patterns

play02:13

that he introduced have taken over so

play02:14

many things he also introduce stuff like

play02:16

emmer that is essential for modern web I

play02:18

believe he's currently working at meta

play02:19

but I might be wrong on that we also

play02:20

have Patrick JS everyone's favorite

play02:22

everything developer the guy who

play02:24

accidentally killed npm check out my

play02:26

video for that if you already haven't

play02:27

seen it and so many more awesome names

play02:29

including not limited to Ben Les who is

play02:31

the creator of rxjs which kind of

play02:33

standardized the idea of signals in

play02:35

JavaScript awesome crew of people check

play02:38

out all of them they're all within some

play02:39

of my favorite devs I'm actually amazed

play02:41

how many dope people are involved in

play02:43

that list but we need to understand

play02:44

signals before we go any further we're

play02:45

minutes in and haven't actually talked

play02:47

about them yet so in August of last year

play02:50

I mentioned that I wanted to begin

play02:51

pursuing a potential standard for

play02:53

signals in tc39 today I'm happy to share

play02:55

that a VZ draft of such a proposal is

play02:57

publicly available along with a spec

play02:59

compliant policy fill this is really

play03:00

cool this means you can start using it

play03:02

today and it will be polyfilled to work

play03:04

the way browsers currently work there's

play03:05

also a disclaimer up here that it's a

play03:07

preview of an in progress proposal and

play03:09

could change at any time don't use this

play03:10

in production don't challenge me I swear

play03:13

every time I see this it makes me want

play03:14

to use it in production more it's like

play03:15

the do not use or you will be fired and

play03:17

react it's like that you're you're just

play03:18

telling me I should use this or at least

play03:20

making me want to what are signals

play03:22

though we haven't even talked about that

play03:23

part a signal is a data type that

play03:25

enables one-way data flow by modeling

play03:27

cells of state and computations derived

play03:29

from other state in computations this if

play03:32

you're a react Dev might sound kind of

play03:34

familiar but usually this is with

play03:35

components where you have the root

play03:37

component at the top and it passes

play03:38

things down but you can't really go back

play03:40

up and that's the magic of react is the

play03:42

one-way data tree the reason that this

play03:44

is so valuable is it makes debugging and

play03:47

understanding your application's flows

play03:48

significantly easier if you don't have

play03:50

things going up and down constantly you

play03:51

have to trace these really crazy data

play03:53

Trails across your application react

play03:55

does that not just with data but with

play03:56

the actual like application and react

play03:58

component modeling so your whole UI has

play04:00

that top to bottom approach it makes

play04:02

debugging easier it makes reasoning

play04:03

about your logic easier it makes

play04:05

compiling it to be more efficient easier

play04:06

it makes a lot of things easier if you

play04:08

don't allow for data to go two different

play04:10

directions like imagine a component that

play04:12

could pass props to its parent it makes

play04:14

things way more complex and that

play04:16

complexity has been the default of the

play04:17

web for a long time react challenged

play04:19

that for UI Frameworks signals is

play04:21

challenging that for state and data

play04:23

across all JavaScript applications the

play04:25

state and computations form an as cyclic

play04:27

graph where each node has other nodes

play04:29

that derive state from its value the

play04:30

syncs and or that contribute state to

play04:33

its value which are sources a node may

play04:35

also be tracked as clean or dirty what

play04:37

does this all mean let's take a simple

play04:38

example imagine we have a counter we

play04:40

want to track we can represent that as

play04:41

state cons counter equals new signal.

play04:44

state 0 we can read the current value

play04:46

with get so console log counter. getet

play04:48

this will log out zero cool and now we

play04:50

can change the value with set counter.

play04:52

set one and now when we log it we get

play04:54

the new value now let's imagine we want

play04:56

to have another signal that indicates

play04:58

whether our counter holds an even number

play04:59

or not cost is even equals new signal.

play05:02

computed and in here counter. getet and

play05:05

one or zero this will now give you a new

play05:07

signal of is even that will change

play05:09

whenever counter. getet changes and

play05:11

here's the magic of signals is that the

play05:13

change here cuz if counter gets changed

play05:16

the value of counter. getet is now

play05:18

different and these signal computations

play05:20

are smart enough to propagate those

play05:21

changes because when you call counter.

play05:23

getet inside of a signal computation it

play05:25

knows to recompute the signal so this

play05:27

signal is dependent on this one so when

play05:29

this one changes this one changes and

play05:31

now this fires computations aren't

play05:33

writable but we can always read their

play05:35

latest value so you can't write here

play05:37

either that's the important thing you

play05:38

can't do is even. set you can only get

play05:40

it because it's a computed value it's

play05:42

effectively read only console.log is

play05:44

even get false counter. set then when we

play05:46

log it again it's true in the above

play05:49

example is even is a sync of counter and

play05:51

counter is a source of is even good

play05:53

we can add another computation that

play05:55

provides the par of our counter here's a

play05:57

fun one we have par which will say even

play05:59

or odd it's a string depending what the

play06:01

value here is so we call is even. getet

play06:03

and then it's even if it's true and odd

play06:05

if it's false Again by calling this is

play06:07

even. getet in here this signal

play06:09

primitive knows that whenever this

play06:11

changes it needs to recompute this whole

play06:13

thing and change the results of this guy

play06:15

so now we have parity sourcing is even

play06:17

and is even is a sync of parity we can

play06:19

change the original counter and it state

play06:20

will flow unidirectionally to parity so

play06:22

I'm going to see how valuable this is

play06:24

just like react components you have a

play06:25

component at the bottom and you can wrap

play06:26

and wrap and wrap but when that one

play06:27

component in the middle changes

play06:29

everything's hand

play06:30

this is that for your data it's so

play06:32

powerful to have variables where when

play06:34

things change within them anything

play06:35

depending on them also changes

play06:37

accordingly instead of like another way

play06:39

to think of this if I just open up some

play06:41

crappy JavaScript here something we've

play06:43

all seen before is like const x equal 2

play06:46

cons doubled = x * 2 what if this isn't

play06:50

cons what if it's let and I do x + 5 or

play06:53

X+ 4 xal X+ 4 doubled is still going to

play06:57

be a different number because doubled

play06:59

was created at this point in time so

play07:01

there's no way to change X such that

play07:03

doubled also updates by default the

play07:05

magic of this new model is that if we

play07:07

make this a sync and then we have other

play07:10

things that are computed off of it one

play07:12

change will persist through all of the

play07:14

other signals that have been bound this

play07:16

is very very powerful stuff we're

play07:18

already getting a really good question

play07:19

which is this is valuable but is it

play07:21

valuable enough to be on the web

play07:22

platform I'll make the argument of yes

play07:24

not just because everyone should be

play07:25

using this and the polyfills aren't good

play07:26

enough or something like that

play07:27

specifically because if this is

play07:29

introduced in the browser there are a

play07:30

lot of optimizations the browser can do

play07:32

to make it really really efficient and

play07:34

really performant and that's what I'm

play07:35

excited about with this being in the

play07:36

browser is the potential of this being

play07:38

really really fast it's already

play07:40

pretty fast but if you The optimizations

play07:42

Happening where like memory assignments

play07:43

aren't being made where they're not

play07:44

necessary and such and everything's

play07:45

computed on the Fly this can fly

play07:48

everything we've done so far seems like

play07:50

it could be done through normal function

play07:51

composition but if implemented that way

play07:53

without signals there will be no Source

play07:54

or sync graphs behind the scenes so why

play07:57

do we want this graph what's it doing

play07:58

for us recall I mentioned signals can be

play08:00

clean or dirty when we change the value

play08:02

of counter it becomes dirty because we

play08:04

have a graph relationship we can then

play08:05

Mark all of the syns of counter dirty as

play08:08

well and all of the sinks that those

play08:09

have as well and so on and so forth this

play08:11

is where that propagation becomes magic

play08:12

the ability to identify which things

play08:14

need to be changed and just change them

play08:16

all synchronously as a result of that

play08:17

initial Change magic and makes your data

play08:19

update model much easier there's an

play08:21

important detail to understand here the

play08:23

signal algorithm is not a push model

play08:25

making a change to counter does not

play08:27

eagerly push out an update to the value

play08:28

of is even and then via the graph and

play08:30

update to parity it is also not a pure

play08:32

pull model this is an important thing

play08:34

it's not just going to force everything

play08:37

to be in the updated State and it's also

play08:38

not going to recompute every time you

play08:40

call it it's somewhere in between

play08:42

reading the value of parity doesn't

play08:43

always compute the value of parity or is

play08:45

even rather when counter changes it

play08:47

pushes only the change in the dirty flag

play08:50

through the graph any potential

play08:51

recomputation is delayed until a

play08:53

specific signals value is explicitly

play08:54

pulled really cool stuff we call this a

play08:57

push then pull model so by marking

play08:59

everything is dirty like right here

play09:01

we're not using doubled for anything so

play09:03

technically it never actually has to

play09:05

compute this value it doesn't know what

play09:07

double is but if we wanted to use this

play09:09

by like I don't know console.log doubled

play09:12

now it's actually going to do the

play09:13

compute it's not going to do the compute

play09:14

here where we assign it it's going to do

play09:16

the compute here where we actually call

play09:18

it and then when we change it here to X

play09:20

= X+ 4 only this has changed the things

play09:22

that it's dependent on haven't changed

play09:24

until we use them obviously this would

play09:26

be like double. getet instead and we'

play09:28

have all the signal syntax and

play09:29

everything but the point is that the

play09:30

actual computation here the actual work

play09:33

being done after the change only occurs

play09:35

if and when the thing that is dependent

play09:38

on is being consumed it's very lazy

play09:40

which is a good thing lazy thank you to

play09:42

zcb Q QJ qg cool thank you for pointing

play09:46

out that it is lazy because that is a

play09:47

very important way to describe it it is

play09:49

lazily evaluated because we don't need

play09:51

to do this compute unless we know we

play09:52

actually need the values there are a

play09:54

number of advantages that arise out of

play09:55

combining an a cyclic graph data

play09:57

structure with a push then pull

play09:59

algorithm them here's a few signal.

play10:01

computed is automatically memorized if

play10:02

the source value hasn't changed there's

play10:04

no need to recompute that's really cool

play10:06

there's no idea of like a memo we don't

play10:08

need one because things are lazy anyways

play10:10

unneeded values aren't recomputed even

play10:12

when sources change if a computation is

play10:14

dirty but nothing reads its value then

play10:15

no recomputation occurs false or over

play10:17

updating can be avoided for example if

play10:20

we change counter from 2 to four yes it

play10:22

is dirty but when we pull the value of

play10:23

parody his computation will not need to

play10:25

rerun because is even once pulled will

play10:28

return the same value for four as it did

play10:29

for two that's a really cool point I

play10:31

hadn't thought of actually which is that

play10:33

with this chain where we have is even if

play10:36

you assign a new value such that is even

play10:38

needs to recompute to be sure it's still

play10:41

the same as long as the results the same

play10:42

you don't have to rerun this one after

play10:44

that's a really cool thing I hadn't

play10:45

thought about there that is a good point

play10:47

we can also be notified when signals

play10:49

become dirty and choose how to react

play10:51

also very useful you can put listeners

play10:52

on all of these things these

play10:55

characteristics turn out to be very

play10:56

important when efficiently updating user

play10:58

interfaces to see how we can introduce a

play11:00

fictional effect function that will

play11:02

invoke some action when one of its

play11:03

sources becomes dirty for example we

play11:05

could update a text node in the Dom with

play11:06

the parody so here we have an effect

play11:09

everyone's favorite I know us react devs

play11:11

get triggered when we hear this word but

play11:13

doesn't have to be that complex I

play11:14

promise so here we have node. text

play11:16

content equals parody doget since we put

play11:18

this in an effect now whatever

play11:20

functionality we put in here reruns

play11:22

whenever this signals response changes

play11:25

so if we switched from two to four it's

play11:27

not actually going to rerun if we change

play11:29

it from two to three it will actually

play11:30

rerun and it will update the text

play11:31

content so the first time this runs the

play11:33

node text is updated with odd because

play11:35

the default value is one so it's odd the

play11:37

effect watches the Callback Source

play11:39

parity for dirty changes now we set

play11:41

counter to two this dirties the counter

play11:43

graph which means that this needs to

play11:45

rerun and this time when it reruns it

play11:47

sees that this is different so it

play11:48

actually sets this value this time but

play11:50

if parody. getet doesn't respond

play11:53

differently then it's not going to

play11:54

trigger all of its dependencies so we

play11:56

see here counter out set four since this

play11:58

results in par having the same answer

play12:01

because the is even check before it has

play12:03

the same answer this never gets run

play12:05

again theer begins to re-evaluate the

play12:07

effect call back by pulling parody

play12:09

parody begins to evaluate by pulling is

play12:10

even is even pulls counter resulting in

play12:13

the same value for is even as before is

play12:14

even as marked clean because a even is

play12:16

clean parody is marked clean and because

play12:18

parody is marked clean the effect

play12:19

doesn't run and the text is unaffected

play12:21

nice and easy hopefully this brings some

play12:23

clarity to what a signal is an

play12:25

understanding of the significance of the

play12:26

combination of the as cyclic source and

play12:28

sync graph with its push PA algo I would

play12:30

say so so who's been working on this

play12:32

late in 2023 I partnered with Daniel

play12:34

ringberg Ben Les and Dominic ganway to

play12:36

try and round up as many signal Library

play12:38

authors and maintainers of frontend

play12:39

Frameworks as we could you picked a good

play12:41

group anyone who expressed an interest

play12:43

was invited to help us to begin

play12:44

exploring the feasibility of signals as

play12:46

a standard we started with a survey of

play12:48

questions in one-onone interviews

play12:50

looking for common themes ideas use

play12:52

cases semantics Etc we didn't know

play12:53

whether there was even a common model to

play12:55

be found that's another scary point

play12:56

because everyone's emed signals in their

play12:58

own weird chaotic ways I'm pumped that

play13:00

they were able to find something as they

play13:01

say here to our Delight we discovered

play13:03

that there was quite a bit of agreement

play13:05

from the start over the last 6 to S

play13:07

months detail after detail was poured

play13:09

over attempting to move from General

play13:11

agreement to the specifics of data

play13:12

structures algorithms and an initial API

play13:15

you may recognize a number of the

play13:16

libraries and Frameworks that have

play13:17

provided design input at various times

play13:19

throughout the process so far hular

play13:21

bubble Ember fast mobex preact quick

play13:23

rxjs solid star beam felt view whiz and

play13:26

more these are all the Frameworks that

play13:27

are considering signals or already have

play13:29

them not a bad list speaking of which it

play13:31

is quite a list and I can honestly say

play13:33

looking back at my own work in web

play13:35

standards over the last 10 years this is

play13:36

one of the most amazing collaborations

play13:38

I've had the honor to be a part of is

play13:39

truly a special group of people with

play13:41

exactly the type of collaborative and

play13:43

collective experience that we need to

play13:45

continue to move the web forward

play13:46

important if we miss your library or

play13:47

framework there's still plenty of

play13:48

opportunities to get involved nothing is

play13:49

set in stone we're still at the

play13:51

beginning of this process scroll down to

play13:52

the section titled how can I get

play13:53

involved in the proposal to learn more

play13:55

good call out so what's in this proposal

play13:57

The Proposal on GitHub includes

play13:59

backgrounds motivations design goals FAQ

play14:01

proposed API for creating both state and

play14:03

computed signals proposed API for

play14:05

watching the signals various additional

play14:06

proposed utility apis such as things for

play14:08

introspection a detailed description of

play14:10

the various signal algorithms as well as

play14:11

a spec compliant polyfill covering all

play14:13

the proposed apis so this isn't just a

play14:15

proposal this is a thing you can go use

play14:16

today interesting that their proposal

play14:18

does not include an effect API since

play14:20

such apis are often deeply integrated

play14:22

with rendering and batch strategies that

play14:24

are highly framework and Library

play14:25

dependent very good call out here a

play14:28

blank pocket boring standard effect

play14:31

would need very different

play14:32

implementations for different Frameworks

play14:34

depending on how and where they rerender

play14:35

things so it doesn't surprise me that

play14:37

didn't make it in like they call that

play14:38

out here however the proposal does seek

play14:40

to define a set of Primitives and

play14:42

utilities that Library authors can use

play14:43

to implement their own effects on that

play14:45

note The Proposal is designed in such a

play14:47

way as to recognize that there are two

play14:49

broad categories of signal users

play14:50

application devs and Library framework

play14:52

INF forevs thank you for calling this

play14:54

out early this is a thing I've been

play14:56

shouting about for a while which is that

play14:59

the experience of these two groups

play15:01

varies so widely even within well-loved

play15:04

tools I obviously am a huge typescript

play15:06

advocate I've been pushing typescript

play15:08

forever but I've done that largely as an

play15:09

appdev now that I'm working more on

play15:11

libraries I see why people hate

play15:12

typescript because getting all of your

play15:14

types right can not only be its own

play15:16

massively difficult challenge while

play15:18

building a library or framework it also

play15:19

can force you into certain directions

play15:21

with your code that you might not have

play15:22

gone into otherwise I know I'm far from

play15:24

the only Library Dev that's had to make

play15:25

significant changes to their apis and

play15:27

their sdks just to make sure that their

play15:29

stuff can be made typ safe with

play15:30

typescript so these things are very

play15:33

influential on both of these sides and

play15:35

it's not often enough that this is

play15:36

called out early in this way because the

play15:38

needs and goals and interests of these

play15:40

groups vary wildly so making sure both

play15:42

are happy very important apis that are

play15:45

intended to be used by application devs

play15:47

are exposed directly from the signal

play15:48

name space these include signal. State

play15:50

and signal. computed apis which should

play15:52

rarely if ever be used an application

play15:54

code and are more likely to involve

play15:56

subtle handling typically at the infro

play15:57

level and layer are Expos through the

play15:59

signal. subtle namespace I actually like

play16:01

that I'm not sure if subtle a word that

play16:04

is easily enough translated would be my

play16:06

big concern is like internationalization

play16:08

for this like that this word might not

play16:10

communicate to non-native English

play16:12

speakers well enough what it's for

play16:14

that's my only concern here but I do

play16:15

actually really like the use of subtle

play16:17

for this and also that it's lowercase

play16:18

and everything else is uppercase these

play16:20

include things like signal. subtle.

play16:22

Watcher as well as signal. subtle.

play16:23

untrack as well as the introspection

play16:25

apis oh crypto do subtle so this is

play16:28

already a thing

play16:29

fun this blog post is really useful

play16:31

normally I would skip an ad but uh Rob

play16:34

and crew are killing it with this so if

play16:35

you're interested in a web component

play16:37

engineering course check that out link

play16:39

is in the description for the blog

play16:40

course and you can find this in there

play16:41

youall know I'm the worst place to learn

play16:43

about web components CU I just don't

play16:45

think they're good but uh if you want to

play16:46

figure out more about them this is a

play16:48

good place to do it anyways as an app

play16:50

Dev how do I use signals many of today's

play16:52

popular component and rendering

play16:54

Frameworks are already using signals

play16:56

over the coming months we hope that

play16:57

framework maintainers will experiment

play16:58

with re-platforming their systems on top

play17:00

of this signals proposal providing

play17:02

feedback along the way and helping us

play17:03

prove out whether it is possible to

play17:05

leverage a potential signals standard If

play17:07

This Were to work out many app devs

play17:09

would use signals through their chosen

play17:10

component Frameworks their patterns

play17:12

wouldn't change however their Frameworks

play17:14

would then be more interoperable like

play17:16

reactive data interoperability imagine

play17:18

that like you write react code and then

play17:20

you have a spelt component or a solid

play17:21

component and it can use the exact same

play17:23

state model and the exact same update

play17:25

layer as your react code is using that's

play17:26

really cool exciting opportunities there

play17:29

it's also smaller because signals are

play17:30

built in and don't need to ship JS at

play17:32

least if this ships it will be the case

play17:34

and hopefully faster because native

play17:35

signals as part of the JS runtime have

play17:37

the opportunity to optimize a ton of

play17:40

stuff Library authors would then be able

play17:42

to write code using signals that works

play17:44

natively with any component or rendering

play17:46

library that understands the standard

play17:48

reducing the fragmentation in the web

play17:49

ecosystem application Deads would be

play17:51

able to build model and state layers

play17:52

that are decoupled from their current

play17:53

rendering Technologies giving them more

play17:55

architectural flexibility and the

play17:57

ability to experiment with and evolve

play17:58

their view layer without rerunning the

play17:59

entire application don't MVC this for me

play18:02

man we were agreeing don't don't use

play18:04

this as a way to encourage MVC so let's

play18:06

say you're a Dev that wants to create

play18:07

libraries using signals or who wants to

play18:09

build apps using them instead what would

play18:10

this look like well we've seen a bit of

play18:13

it already when I explain the basics of

play18:14

signals through the signal State and

play18:16

computed apis above these are the two

play18:18

primary apis that an application

play18:19

developer would use if not using them

play18:21

indirectly through a Frameworks API

play18:23

instead they can be used by themselves

play18:24

to represent Standalone reactive State

play18:26

and computations or in combination with

play18:28

other Js constructs like classes here's

play18:30

a counter class that uses a signal to

play18:31

represent its internal State no what

play18:34

part of why I love signals is they help

play18:35

FP don't don't force oop into

play18:39

here cool it works it does what it's

play18:42

supposed to you can still do dependence

play18:43

and so

play18:45

cool one particular nice way to use

play18:48

signals is in combination with

play18:49

decorators we can create an at signal

play18:51

decorator that turns an accessor into a

play18:53

signal as follows X function signal

play18:55

Target const get is Target we return the

play18:57

get get called that get set and init and

play19:00

when you init it makes a signal so now

play19:02

we have this helper signal decorator

play19:05

that we can just put over this signal

play19:07

accessor value zero and now this is just

play19:10

magically become a signal my issue here

play19:12

is like this code isn't complex enough

play19:13

that I'd want to abstract it but uh cool

play19:16

that you can weird but

play19:18

cool there are many more ways to use

play19:20

signals but hopefully these examples

play19:21

provide a good starting point for those

play19:22

who want to experiment at this state

play19:25

this is a cool call out that um setting

play19:27

on a getter plus one like this where we

play19:29

add one and then we set that that this

play19:31

could cause an infinite state in an

play19:32

infinite Loop when used within a

play19:34

computed or an effect the reason for

play19:36

that would be if this. val. set is part

play19:38

of something that is running because

play19:40

this. val. get changed this could Loop

play19:43

really rough this is not cause a problem

play19:45

in the current proposals computed nor

play19:46

does it cause a problem in the effect

play19:47

example demonstrated below should it

play19:49

cause a loop though or should it throw

play19:50

what should be the behavior this is an

play19:52

example of the many types of details

play19:53

that need to be worked through in order

play19:55

to standardize an API like this I like

play19:57

this call out actually at first I was

play19:58

like I don't agree with this being

play19:59

supported necessarily but the call out

play20:01

that he's bringing this up specifically

play20:03

so we can have conversations about it

play20:04

and how it should work this is a very

play20:06

responsible proposal where it's it's

play20:08

very considered of the the reality of

play20:10

the web dev world and not just trying to

play20:11

be like here's how we're doing this now

play20:13

I like this a lot and I hope more

play20:15

proposals are written this well in the

play20:16

future most have been pretty good thus

play20:17

far but this is dope so how do library

play20:19

devs integrate these things we hope that

play20:20

the maintainers of view and component

play20:22

libraries will experiment with

play20:23

integrating this proposal as well as

play20:24

well as those who create State

play20:26

Management and data related libraries a

play20:27

first integration step would be to

play20:29

update the library signals to use

play20:30

signal. State and signal. computed

play20:32

internally instead of the current

play20:33

Library specific implementations of

play20:35

course this isn't enough a common Next

play20:36

Step would be to update any effect or

play20:38

equivalent infra as I mentioned above

play20:40

the proposal does not provide an effect

play20:42

implementation our research showed this

play20:43

was too connected to the details of

play20:45

rendering and batching to standardize at

play20:47

this point rather the signal that subtle

play20:49

namespace provides The Primitives that a

play20:51

framework can use to build its own

play20:52

effects let's take a look at

play20:53

implementing a simple effect function

play20:55

that batches updates on the microtask

play20:57

Que let needs and Q equals true cons W

play21:00

new signal subtle Watcher if needs and Q

play21:02

false Q

play21:04

microtask I don't want to read microtask

play21:06

code I'm not paid enough for this

play21:08

I'm sorry if these are the of things

play21:10

you're interested in you have an awesome

play21:11

blog post to go read about it that's not

play21:13

the basics once you're into microtasks

play21:15

we're not in Basics land anymore one

play21:17

other fun API is subtle untrack helper

play21:19

this function takes a call back to

play21:20

execute and it ensures the signals red

play21:22

within the Callback will not be tracked

play21:24

feel the need to remind readers this is

play21:26

a names space that's designated for apis

play21:28

that should be with care and mostly by

play21:29

Frameworks are in for authors using this

play21:31

incorrectly will totally break your

play21:34

graph and result in things that are

play21:35

impossible to track so uh yeah with that

play21:38

said let's look at a legitimate use of

play21:40

this API many view Frameworks have a way

play21:43

to render a list of items typically you

play21:44

pass the framework in Array and a

play21:46

template or fragment of HTML that it

play21:48

should render for each item in the array

play21:50

as an appdev you want any interaction

play21:52

with the array to be tracked by the data

play21:54

reactivity system so that your List's

play21:55

rendered output will stay in sync with

play21:57

your data but what about the framework

play21:58

itself they must access the array in

play22:00

order to render it the framework's

play22:01

access of the array were tracked by the

play22:03

dependency system that would create all

play22:05

sorts of unnecessary Connections in the

play22:06

graph leading to false or over updating

play22:09

so imagine you have a list with items in

play22:10

it and you change one of the items in

play22:12

that list the whole list now has to

play22:14

rerender this is already kind of the

play22:15

case in react that's why we have keys to

play22:16

identify which things you should and

play22:18

shouldn't actually do the reender for

play22:20

but every framework has their different

play22:21

way of handling it and you might just

play22:22

want to untrack the list and build your

play22:24

own tracking for every item in the list

play22:26

kind of like how something like solid

play22:27

would do it so that's what I'm sure

play22:28

they're going to propose here let's see

play22:30

if the framework's access of the array

play22:31

were tracked yep it leads to the false

play22:33

or over updating but also weird bugs

play22:35

this is where lots of weird bugs tend to

play22:37

crop up even in react that's why keys

play22:38

are so important because if you do them

play22:39

wrong everything breaks the signal

play22:41

subtle untrack API provides the library

play22:43

author with a simple way of handling

play22:45

this challenge as an example let's look

play22:47

at a small bit of code from solid that

play22:48

renders arays funny that that got called

play22:50

out already which I've slightly modified

play22:52

to use the proposed standard we won't

play22:53

look at the whole implementation I've

play22:54

cut most of the code out for Simplicity

play22:56

hopefully looking at the high level will

play22:57

help explain the use case hopefully

play22:59

let's take a look map array items mapped

play23:02

length cool return new items which is

play23:04

list or empty array I and J which are

play23:08

all the new things we just defined new

play23:09

length is new items. length and now

play23:11

we're going to go through and untrack

play23:13

the existing stuff nothing in the

play23:15

following callback will be tracked we

play23:16

don't want our Frameworks rendering work

play23:18

to be affecting the signals graph cool

play23:21

so now we have this list and I'm

play23:23

assuming the ah I won't assume anything

play23:26

let's just read how it works first so

play23:27

now we're doing all work in here in

play23:29

order to make sure that any work we do

play23:31

and any values we access aren't going to

play23:33

automatically be Trac as we want them to

play23:35

be so we have an early Escape for empty

play23:37

arrays we have a fast path for New

play23:39

Creations and then we just read

play23:41

otherwise cool even though of AED I'm

play23:45

not even pretend I know what that word

play23:46

is supposed to be even though I've

play23:47

skipped the bulk of solid's algorithm

play23:49

you can see how the main body of work is

play23:50

done within an untracked block of code

play23:52

that accesses the array there are

play23:53

additional apis within the signal.

play23:55

subtle namespace which you can explore

play23:56

at your leisure hopefully the above

play23:58

example helps to demonstrate the kinds

play23:59

of scenarios this part of the proposal

play24:01

is designed for I think that makes sense

play24:03

specifically the idea that um the

play24:04

framework rendering shouldn't trigger

play24:06

things in the graph that part mostly

play24:08

makes sense but I wish I could see

play24:10

something here that is actually a signal

play24:11

to use to follow the data trail I'm sure

play24:14

Ryan carniato will have a lot smarter of

play24:16

things to say with this than I do here

play24:18

the instructions on how to get involved

play24:19

if you're interested check the link in

play24:20

the description to this article to learn

play24:21

more I'm not going to cover this

play24:23

directly but it is really useful and

play24:25

it's awesome they're calling out the

play24:26

need for help even with things like

play24:27

testing or reporting other signal

play24:29

implementations even if just examples a

play24:30

lot of opportunity for people who are

play24:32

really interested in this proposal to

play24:33

get involved good stuff so what's next

play24:36

we're still at the beginning of this

play24:37

effort in the next few weeks Daniel and

play24:39

Jan from Google and Bloomberg

play24:40

respectively will bring the proposal

play24:42

before tc39 seeking stage one stage one

play24:45

means the proposal is under

play24:46

consideration so right now tc39 isn't

play24:48

actually considering this proposal it's

play24:50

just in work once it hit stage one that

play24:52

means they're actually thinking about it

play24:53

as a formal group and as he says they're

play24:55

not even there yet you think of signals

play24:56

as being at stage zero the earliest of

play24:58

the early out of presenting a tc39 we'll

play25:00

continue to evolve The Proposal based on

play25:02

feedback from that meeting and in line

play25:04

with what we hear from folks who get

play25:05

involved through GitHub our approach is

play25:07

to take things slow and to provide ideas

play25:09

out through prototyping we want to make

play25:11

sure we don't standardize something that

play25:12

no one can use like web components I'm

play25:15

I'm sorry I have to sneak a web

play25:17

component dig in here I was nice earlier

play25:18

we'll need your help to achieve this

play25:20

with your contributions as described

play25:21

above we believe we'll be able to refine

play25:24

this proposal and make it suitable for

play25:25

all I believe a signal standard has

play25:27

tremendous potential for for JavaScript

play25:29

and for the web it's been exciting to

play25:30

work with such a great set of folks from

play25:31

the industry who are deeply invested in

play25:33

reactive systems here's some more future

play25:35

collaboration and a better web for all

play25:37

that was a post I had High Hopes but

play25:39

honestly I'm even more excited now that

play25:40

I've read that just seeing who's

play25:42

involved and how much they're

play25:43

considering both app devs and framework

play25:44

authors means the future of signals is

play25:47

bright let me know what you guys think

play25:48

in the comments are you excited or is

play25:49

this just overhyped Madness and until

play25:51

next time peace nerds

Rate This

5.0 / 5 (0 votes)

Related Tags
JavaScriptSignalsReactive ProgrammingData FlowWeb DevelopmentPerformance OptimizationTC39 ProposalState ManagementFrontend FrameworksCollaborative Effort