.svg)
.svg)
When React got introduced, it had an edge over other libraries and frameworks present in that era because of a very interesting concept called one-way data binding or in simpler words uni-directional flow of data introduced as a part of Virtual DOM.
It made for a fantastic developer experience where one didn’t have to think about how the updates flow in the UI when data (”state” to be more technical) changes.
However, as more and more hooks got introduced there were some syntactical rules to make sure they perform in the most optimum way. Essentially, a deviation from the original purpose of React which is unidirectional flow or explicit mutations
To call out a few
And possibly a few more that if done the wrong way could cause some serious performance issues i.e. everything just re-renders. A slight deviation from the original purpose of just writing components to build UIs.
The use of signals is a good example of how adopting Reactive programming primitives can help remove all this complexity and help improve developer experience by shifting focus on the right things without having to explicitly follow a set of syntactical rules for gaining performance.
A signal is one of the key primitives of Reactive programming. Syntactically, they are very similar to states in React. However, the reactive capabilities of a signal is what gives it the edge.
| const [state, setState] = useState(0); | |
| // state -> value | |
| // setState -> setter | |
| const [signal, setSignal] = createSignal(0); | |
| // signal -> getter | |
| // setSignal -> setter |
At this point, they look pretty much the same—except that useState returns a value and useSignal returns a getter function.
Once useState returns a value, the library generally doesn’t concern itself with how the value is used. It’s the developer who has to decide where to use that value and has to explicitly make sure that any effects, memos or callbacks that want to subscribe to changes to that value has that value mentioned in their dependency list and in addition to that, memoizing that value to avoid unnecessary re-renders. A lot of additional effort.
| function ParentComponent() { | |
| const [state, setState] = useState(0); | |
| const stateVal = useMemo(() => { | |
| return doSomeExpensiveStateCalculation(state); | |
| }, [state]); // Explicitly memoize and make sure dependencies are accurate | |
| useEffect(() => { | |
| sendDataToServer(state); | |
| }, [state]); // Explicilty call out subscription to state | |
| return ( | |
| <div> | |
| <ChildComponent stateVal={stateVal} /> | |
| </div> | |
| ); | |
| } |
A createSignal, however, returns a getter function since signals are reactive in nature. To break it down further, signals keep track of who is interested in the state’s changes, and if the changes occur, it notifies these subscribers.
To gain this subscriber information, signals keep track of the context in which these state getters, which are essentially a function, are called. Invoking the getter creates a subscription.
This is super helpful as the library is now, by itself, taking care of the subscribers who are subscribing to the state’s changes and notifying them without the developer having to explicitly call it out.
| createEffect(() => { | |
| updateDataElswhere(state()); | |
| }); // effect only runs when `state` changes - an automatic subscription |
The contexts (not to be confused with React Context API) that are invoking the getter are the only ones the library will notify, which means memoizing, explicitly filling out large dependency arrays, and the fixing of unnecessary re-renders can all be avoided. This helps to avoid using a lot of additional hooks meant for this purpose, such as useRef, useCallback, useMemo, and a lot of re-renders.
This greatly enhances the developer experience and shifts focus back on building components for the UI rather than spending that extra 10% of developer efforts in abiding by strict syntactical rules for performance optimization.
| function ParentComponent() { | |
| const [state, setState] = createSignal(0); | |
| const stateVal = doSomeExpensiveStateCalculation(state()); // no need memoize explicity | |
| createEffect(() => { | |
| sendDataToServer(state()); | |
| }); // will only be fired if state changes - the effect is automatically added as a subscriber | |
| return ( | |
| <div> | |
| <ChildComponent stateVal={stateVal} /> | |
| </div> | |
| ); | |
| } |
It might look like there’s a very biased stance toward using signals and reactive programming in general. However, that’s not the case.
React is a high-performance, optimized library—even though there are some gaps or misses in using your state in an optimum way, which leads to unnecessary re-renders, it’s still really fast. After years of using React a certain way, frontend developers are used to visualizing a certain flow of data and re-rendering, and replacing that entirely with a reactive programming mindset is not natural. React is still the de facto choice for building user interfaces, and it will continue to be with every iteration and new feature added.
Reactive programming, in addition to performance enhancements, also makes the developer experience much simpler by boiling down to three major primitives: Signal, Memo, and Effects. This helps focus more on building components for UIs rather than worrying about dealing explicitly with performance optimization.
Signals are increasingly getting popular and are a part of many modern web frameworks, such as Solid.js, Preact, Qwik, and Vue.js.
Did you like the blog? If yes, we're sure you'll also like to work with the people who write them - our best-in-class engineering team.
We're looking for talented developers who are passionate about new emerging technologies. If that's you, get in touch with us.
When React got introduced, it had an edge over other libraries and frameworks present in that era because of a very interesting concept called one-way data binding or in simpler words uni-directional flow of data introduced as a part of Virtual DOM.
It made for a fantastic developer experience where one didn’t have to think about how the updates flow in the UI when data (”state” to be more technical) changes.
However, as more and more hooks got introduced there were some syntactical rules to make sure they perform in the most optimum way. Essentially, a deviation from the original purpose of React which is unidirectional flow or explicit mutations
To call out a few
And possibly a few more that if done the wrong way could cause some serious performance issues i.e. everything just re-renders. A slight deviation from the original purpose of just writing components to build UIs.
The use of signals is a good example of how adopting Reactive programming primitives can help remove all this complexity and help improve developer experience by shifting focus on the right things without having to explicitly follow a set of syntactical rules for gaining performance.
A signal is one of the key primitives of Reactive programming. Syntactically, they are very similar to states in React. However, the reactive capabilities of a signal is what gives it the edge.
| const [state, setState] = useState(0); | |
| // state -> value | |
| // setState -> setter | |
| const [signal, setSignal] = createSignal(0); | |
| // signal -> getter | |
| // setSignal -> setter |
At this point, they look pretty much the same—except that useState returns a value and useSignal returns a getter function.
Once useState returns a value, the library generally doesn’t concern itself with how the value is used. It’s the developer who has to decide where to use that value and has to explicitly make sure that any effects, memos or callbacks that want to subscribe to changes to that value has that value mentioned in their dependency list and in addition to that, memoizing that value to avoid unnecessary re-renders. A lot of additional effort.
| function ParentComponent() { | |
| const [state, setState] = useState(0); | |
| const stateVal = useMemo(() => { | |
| return doSomeExpensiveStateCalculation(state); | |
| }, [state]); // Explicitly memoize and make sure dependencies are accurate | |
| useEffect(() => { | |
| sendDataToServer(state); | |
| }, [state]); // Explicilty call out subscription to state | |
| return ( | |
| <div> | |
| <ChildComponent stateVal={stateVal} /> | |
| </div> | |
| ); | |
| } |
A createSignal, however, returns a getter function since signals are reactive in nature. To break it down further, signals keep track of who is interested in the state’s changes, and if the changes occur, it notifies these subscribers.
To gain this subscriber information, signals keep track of the context in which these state getters, which are essentially a function, are called. Invoking the getter creates a subscription.
This is super helpful as the library is now, by itself, taking care of the subscribers who are subscribing to the state’s changes and notifying them without the developer having to explicitly call it out.
| createEffect(() => { | |
| updateDataElswhere(state()); | |
| }); // effect only runs when `state` changes - an automatic subscription |
The contexts (not to be confused with React Context API) that are invoking the getter are the only ones the library will notify, which means memoizing, explicitly filling out large dependency arrays, and the fixing of unnecessary re-renders can all be avoided. This helps to avoid using a lot of additional hooks meant for this purpose, such as useRef, useCallback, useMemo, and a lot of re-renders.
This greatly enhances the developer experience and shifts focus back on building components for the UI rather than spending that extra 10% of developer efforts in abiding by strict syntactical rules for performance optimization.
| function ParentComponent() { | |
| const [state, setState] = createSignal(0); | |
| const stateVal = doSomeExpensiveStateCalculation(state()); // no need memoize explicity | |
| createEffect(() => { | |
| sendDataToServer(state()); | |
| }); // will only be fired if state changes - the effect is automatically added as a subscriber | |
| return ( | |
| <div> | |
| <ChildComponent stateVal={stateVal} /> | |
| </div> | |
| ); | |
| } |
It might look like there’s a very biased stance toward using signals and reactive programming in general. However, that’s not the case.
React is a high-performance, optimized library—even though there are some gaps or misses in using your state in an optimum way, which leads to unnecessary re-renders, it’s still really fast. After years of using React a certain way, frontend developers are used to visualizing a certain flow of data and re-rendering, and replacing that entirely with a reactive programming mindset is not natural. React is still the de facto choice for building user interfaces, and it will continue to be with every iteration and new feature added.
Reactive programming, in addition to performance enhancements, also makes the developer experience much simpler by boiling down to three major primitives: Signal, Memo, and Effects. This helps focus more on building components for UIs rather than worrying about dealing explicitly with performance optimization.
Signals are increasingly getting popular and are a part of many modern web frameworks, such as Solid.js, Preact, Qwik, and Vue.js.
.svg)
.svg)
