Casey Baggz
Cerberus Admin
This release adds new features, packages, and improvements to our entire ecosystem.
Kicking v1.1 with a bang...or should I say...signal? 👀
Takes note: never write that joke again... 😂
Here is a brief overview of what's new:
We have improved the Tabs API to support vertical orienation via the orientation
and indicatorPosition props.
The indicatorPosition will decide where the active indicator (e.g., line) is positioned matching the start/end positioning of our other position-related APIs.
Checkout the Tabs documentation for more details.
Our goal is to keep the Data Grid API growing with each release. We have two important updates with v1.1:
We've added support for a footer slot that will allow you to add custom
content within the scope of the Grid Store via the footer prop.
This works just like the toolbar in regards to just drop in the component you want
rendered in that slot (and optionally use the useDataGridContext to get juicy data).
Checkout the Data Grid footer documentation for more details.
Sometimes, you may have an intricate design that calls for the Data Grid but with
some visual tweaks. We help streamline that effort with the new theme prop.
Overall, the Data Grid doesn't style that much. The true style of the Grid comes from the cell content rendered.
Thus, the ThemeOptions offered to pass into the theme prop are the only safe
styles we define for the layout.
Checkout the Data Grid Theme documentation for more details.
In v1.1 we introduce potentially one of the most impactful tools to the React ecosystem since Tanstack: Cerberus Signals.
Since migrating to hooks, React has become more than it was ever orignally designed to be as an API. This means that it has scaled past its architecture. Especially, now that it is saturated in the market, the team can no longer move in the direction they need to for the best result for its users.
Thus, the rise of libraries like SolidJS who introduced the "Signal" pattern as an external state manager - validating there was hope for the future of frontend development.
There have been many external state libraries for React before Cerberus Signals. Rrom Redux to the closest signal-based solution Legend-State. However, all have fallen short in some area whether architecture or developer experience.
We believe that we have fixed and improved in all of those areas. Let's dive in.
Cerberus Signals is highly inspired by SolidJS in more than one way. This wouldn't exist without the Solid core team pushing boundaries and dreaming big.
Signal-based state managent is the foundation of Cerberus Signals. We intentionally avoid the use of Proxies which compliment how the React engine works. A positive side-effect of this is also providing a better developer experience for debugging.
If you have worked with Proxy-based state before, you know what we mean. 😉
With Cerberus signals, you can create global signals via createSignal or
local (component-based) via the useSignal hook.
Read the Reactivity documentation
Sometimes you may want a global single-source of truth for a chunk of signals and actions to create a scalable reactive API. This is how we design the Data Grid context!
In Cerberus Signals, you can do this elegantly without any additional APIs.
Read the Stores documentation
Since Cerberus Signals are external to the React render engine, there is no longer
a need for native APIs like useMemo or useEffect (unless you want to bring in the component lifecycle).
Thus, you can createComputed values from multiple signals and watch for changes
with createEffect.
Since these APIs are not related to React, you can use them on any scope. Likewise, effects can be nested if you wanted to.
Did we mention no dependency arrays? You don't need them with Cerberus Signals.
One of the best parts of SolidJS is the magical signal-based fetching. We provide a similar API via queries.
We use the term "fetching" but queries resolve any Promise. The only limitation to what a query is for your application is your own imagination.
Even more, when a query is referencing a signal - it will autofetch when the signal updates along with caching the result until it is invalidated.
There are two steps to creating a signal-based promise:
createQueryuseQuery hook.If you reference a signal in a query you do not need mutations. Just simply manage the signal being referenced.
💡 Any Cerberus query-related API is compatible with React Suspense and Error Boundaries out of the box.
Now for the most important part - the hard data.
None of this matters if this design doesn't scale. The goal for Cerberus Signals was to allow React developers to have as close to a SolidJS experience as possible in terms of performance and JSX rendering.
If we can't make React render at 0(1) it's a waste...
Today I'm proud to say the benchmarks on the APIs validate the effort and passion of our work has paid off.
Signal Benchmarks:

Let's break down the results:
isFlushing lock are incredibly efficient and prevent stack overflows.Query Benchmarks:

These numbers are phenomenal:
useQuery for a shared configuration or parent data state, React has to mount 10,000 hooks.createSignal wrapper will never be the bottleneck in a massive React application.If you are interested in adopting signals, you can install it today:
npm install @cerberus/signals@npm:@cerberus-design/signalspnpm add @cerberus/signals@npm:@cerberus-design/signalsdeno add npm:@cerberus/signals@npm:@cerberus-design/signalsbun add @cerberus/signals@npm:@cerberus-design/signalsThis is another monumental release introducing a massive tool to the React community via Cerberus Signals.
A special thanks to everyone who has helped validate the APIs, docs, and submitted features or bugfixes for this release.
There is no "I" in Cerber-"US"
To upgrade to this release, you can install the latest version of Cerberus React:
npm run up:cerberuspnpm run up:cerberusdeno run npm:up:cerberusbun run up:cerberusRender Count:
1{
"id": "7a08f556-fb99-4a62-8987-916636411561",
"name": "User 7a08f556-fb99-4a62-8987-916636411561"
}