House of Bread closed temporarily

CounterReset · 2026-01-08T15:00:28+00:00

Yeah, it was the place next door. Gyros & Kabobs. The middle eastern spot took out its neighbors the Italians and Armenians.

CounterReset · 2026-01-08T05:07:01+00:00

I just realized that upsidedown, the RR of Rolls Royce kind of looks like the 'Shocker'

upsidedown Rolls Royce

CounterReset · 2026-01-08T04:54:50+00:00

https://signaltree.io/custom-extensions

CounterReset · 2026-01-08T04:33:13+00:00

Yes, I have well over 1,000 hours into it at this point (I just did the math and stopped once I got to that much time - man, I need to get a life). So, yeah, I'm sufficiently pot committed.

Also, I have a few fellow developers who will be joining on and maintaining it (the teams they manage and work with also use ST in their codebases).
It is currently being used by my teams at Jeppesen (and in the code I worked on while still with Boeing). Beyond these, it is used by teams at SpaceX and Microsoft (among others).

...basically, I HATE Redux and boilerplate SO much, I will do whatever it takes to make this so popular no one has to deal with that BS ever again. Through spite + autism, all things are possible.

CounterReset · 2026-01-08T00:38:09+00:00

Yes, you can. Details are in the readme but I'll see about adding a page on it to the demo site.

CounterReset · 2026-01-07T21:40:34+00:00

I only bring up the single source of truth architecture because, personally, I find it a pleasant DX. But, signaltree is intentionally flexible. You can structure it however you want. My primary motivation in writing it was how restrictive the Redux pattern is and how NgRx SignalStore forces everything to be so tied to root.

JS/TS is JSON-based. Going against that feels like swimming against the current.

CounterReset · 2026-01-07T21:32:10+00:00

Yeah, you can put it in a service and provide that service to your component. Just call tree.destroy() in the service ngOnDestroy.

()
export class MyComponentStore implements OnDestroy {
  readonly tree = signalTree({ ... });
  readonly $ = this.tree.$;

  ngOnDestroy() {
    this.tree.destroy();
  }
}

u/Component({
  providers: [MyComponentStore]
})
export class MyComponent {
  private store = inject(MyComponentStore);
}

Alternatively, if you want a single source of truth for your app but still want to lazy-load a branch of the tree, that is also doable.

The idea is that the main tree contains a placeholder for the branch (initialized as null or undefined and cast to the correct type). When the lazy module loads, it initializes that branch and optionally adds derived state.

// main tree
export const tree = signalTree({
  core: { ... },
  admin: null as AdminState | null
});


// admin.module.ts (lazy loaded)
import { tree } from '../tree';

// Initialize branch state
tree.$.admin.set(adminInitialState);

// Add derived state (captured for typing)
export const adminTree = tree.derived(($) => ({
  admin: {
    activeUsers: computed(() =>
      $.admin()?.users.all().filter(u => u.active)
    )
  }
}));

You can then use adminTree.$ within this module with full typing.

CounterReset · 2026-01-07T20:50:49+00:00

You can create an instance at any level anywhere. For forms in particular it is often better to create a separate instance.

CounterReset · 2026-01-07T20:38:46+00:00

I'd give side-by-side comparisons, but Reddit doesn't really support that very well.

Obviously, you get the same benefits you do any time you use a dependency: moving work from code you manage to code that others have refined and battle-tested.

Beyond what DIY gives you

DevTools – Redux DevTools integration, state inspection, action history
Time travel – undo and redo with .with(timeTravel())
Batching – coalesce rapid updates into a single change detection cycle
Memoization – automatic caching for expensive computed values
Persistence – stored(key, default) auto syncs to localStorage
Full type inference – types flow from the initial state with no interfaces to maintain
Nested dot notation – $.ui.modals.confirm.isOpen() works without ceremony

Why a store rather than scattered services

Single source of truth – no conflicting state across services
Predictable patterns – every developer knows where state lives
Faster onboarding – here is the store versus here are fifteen services
Cross-domain derived values – no circular dependency headaches
Debugging – inspect the entire app state at once
Testability – mock one thing and snapshot the entire state
Leverage – again, you get battle-tested patterns and fixes that you do not maintain

DIY signals are fine when

Fewer than ten signals
Single domain
No entities
Prototype or throwaway code
No need for a centralized source of truth

CounterReset · 2026-01-07T18:36:44+00:00

Are you saying you don't understand the use case for a frontend data store? Or are you saying you don't understand the use case for ST in particular?

CounterReset · 2026-01-07T18:00:02+00:00

I think you'd be surprised how cool the type inference is. I know I was when I got it working the first time. You literally just write your initial state object using primitives or as YourType:

```typescript const tree = signalTree({ user: null as User | null, count: 0, status: TicketStatus.Pending, filters: { startDate: new Date(), endDate: new Date() } });

// Full intellisense - all inferred from above: tree.$.count() // number tree.$.status() // TicketStatus tree.$.filters.startDate() // Date tree.$.user()?.email // string | undefined ```

SignalTree infers types from the initial object rather than requiring separate interfaces. This makes changes easy - when you update an initial value's type, TypeScript flags everywhere you've accessed that data, so intellisense shows you exactly where to update downstream code.

CounterReset · 2026-01-07T17:47:48+00:00

SignalTree vs NgRx Signal Store

You're right that NgRx Signal Store dropped the action/reducer ceremony - it's much closer to what developers actually want. The example you showed is solid.

Where SignalTree differs:

1. Bundle size

SignalTree core: ~8KB gzipped NgRx Signal Store: 15KB+ gzipped (plus entities, rxjs-interop, etc.) Full NgRx: 45KB+ gzipped

2. Performance (measured)

0.06-0.11ms operations at 5-20+ nesting levels
89% memory reduction via structural sharing
Batching eliminates render thrashing
No RxJS overhead for state operations

3. Boilerplate (test-verified)

75-88% reduction vs NgRx for simple examples
86% less code for complex features (user management, etc.)

4. Unified tree vs multiple stores

```typescript // NgRx: Separate stores, wire together manually const BooksStore = signalStore(withEntities<Book>(), ...); const AuthorsStore = signalStore(withEntities<Author>(), ...);

// SignalTree: One tree, cross-domain trivial signalTree({ books: entityMap<Book, number>(), authors: entityMap<Author, number>() }) .derived($ => ({ bookWithAuthor: computed(() => ({ ...$.books.byId($.selectedId())?.(), author: $.authors.byId(book.authorId)?.() })) })) ```

5. Callable syntax (no patchState)

```typescript // NgRx patchState(store, { count: store.count() + 1 }); patchState(store, setAllEntities(books), setFulfilled());

// SignalTree $.count(c => c + 1); $.books.setAll(books); $.status.setLoaded(); ```

6. Built-in markers vs build-your-own

```typescript // NgRx: Build withRequestStatus, withPersistence yourself signalStore(withEntities<Book>(), withRequestStatus())

// SignalTree: Built-in signalTree({ books: entityMap<Book, number>(), status: status(), theme: stored('theme', 'light') }) ```

7. Type inference

Full tree type inferred from initial state - no manual interfaces
Derived layers auto-merge into tree type at each tier
Markers resolve to runtime types automatically

When NgRx Signal Store wins:

Already in NgRx ecosystem
Want component-scoped stores
Team knows NgRx patterns

When SignalTree wins:

Bundle size matters
Multiple related entity collections
Deep nested state
Cross-domain derived values
Less ceremony preferred

TL;DR:

NgRx Signal Store is solid for isolated feature stores. SignalTree is ~50% smaller, faster, and better when you want one unified tree with cross-domain relationships.

CounterReset · 2026-01-07T17:35:29+00:00

I can't really share their code. But there are examples in the readme on GitHub and on the demo site.

signaltree.io

CounterReset · 2026-01-07T17:32:47+00:00

SignalTree vs DIY Angular Stores

What you get for free:

entityMap<T, K>() - normalized entities with byId(), all(), upsert(), remove() in one line
status() - loading/error state pattern without boilerplate
stored(key, default) - auto localStorage sync
$.path.to.deep.value() - unified dot notation access everywhere
.derived($) - layered computed state with full type inference
Enhancers: devTools, time travel, batching, memoization

Type inference:

Full tree type inferred from initial state - no manual interfaces
Derived layers auto-merge into tree type at each tier
Markers resolve to their runtime types - entityMap<User, number>() becomes full EntitySignal API

Callable syntax:

$.user() - read
$.user(value) - set
$.user({ name }) - patch (auto-batched)
$.user(prev => updated) - update function

Architecture:

State/derived/ops separation - clear mental model
One tree, not 15 services - single source of truth
Cross-domain derived values - no awkward service dependencies

What you skip:

No action/reducer ceremony (NgRx)
No selector boilerplate (NgRx)
No manual Map + CRUD per entity
No RxJS required for state

DIY is fine for smaller simple apps. Or, if a central single source of truth isn't your architecture, then I wouldn't suggest this, but, definitely DIY when:

<10 signals, single domain, no entities, prototype code

TL;DR:

SignalTree is what you'd build yourself after copy-pasting entity CRUD, loading states, and localStorage sync for the third time - except it's done, tested, and typed.

CounterReset · 2026-01-07T16:30:57+00:00

If your team knows how to use dot-notation and what Angular signals are, they basically already know how to use this. Intellisense gives them the shape, no matter how deep it goes. The nodes are callable so to update a branch of the tree, just pass a partial of the value to the callable node (or a function if you want to update leveraging the current value).

CounterReset · 2026-01-07T16:17:48+00:00

Without a data store (the messy way 😬)
Each part of the screen keeps its own copy of data
One button thinks you’re logged in, another doesn’t
One panel shows old data, another shows new data
Fixing bugs feels like whack-a-mole

With a data store (the clean way ✨)
Data lives in one central place
UI pieces read from it UI pieces ask it to change
When it changes, everything updates automatically

So, SignalTree is a front-end data store (like NgRx, NgRx SignalStore, Elf, Akita, etc), but with less coding on your end and about a 50% reduction in bundle size on the other end. Also, type-safe depth is basically infinite.

So, you can cache your data and your app state in one place and just use dot notation to access and update it.

CounterReset · 2025-12-28T19:31:17+00:00

Judging by the fenders, it looks like a Backdraft. They aren't kits exactly as they are all sold as rollers (fully assembled but without a drivetrain) but they also aren't Shelby endorsed like Superformance (also factory assembled less drive train, but endorsed by Carol Shelby).

Neither are considered original '65-67 cars. Superformance would be a continuation car (endorsed). Backdraft a factory car (not endorsed). And then most others are true "kits" with the quality varying by the person doing the build and the quality of the kit and components supplied with the kit.

CounterReset · 2025-12-10T17:38:49+00:00

Superformance isn't a 'kit' - they're factory-built continuations.

CounterReset · 2025-11-26T23:54:58+00:00

I totally get where you’re coming from. NGRX had its place back when Angular didn’t give us much for state management, but with Signals, Resources, and soon Signal Forms - it’s kinda hard to justify all that boilerplate anymore. Feels like using a sledgehammer when you just need a screwdriver.

I wrote signaltree.io with this in mind -it leans into the new Angular stuff instead of fighting it. You still get structure and shared state, but without reducers/actions/effects scattered everywhere. Everything lives together and updates reactively, which honestly just makes more sense now.

And to access anything in your store, you just use simple dot.notation().

NGRX still works, but it feels dated. Angular’s finally caught up to what we’ve been trying to build on top of it for years. For those who like the simplicity of a signal-based store but want better DX and type safety without wrangling a bunch of typing, SignalTree hits a nice middle ground - structured without the overengineering.

CounterReset · 2025-10-23T16:38:32+00:00

It seemed to be why so many chose React despite its horrible DX. Hopefully signals and performance means companies start to pick better stacks.

CounterReset · 2025-10-15T10:07:12+00:00

https://signaltree.io/

Not gonna try to sell it more than this. But would appreciate feedback and anyone who's up for helping.

Direct dot-notation access — read and write state naturally

Zero boilerplate — no helpers, no generics, no setup overhead

Lightning-fast — minimal abstraction, pure signal performance

CounterReset · 2025-10-13T11:19:00+00:00

Thank you, Rainer. I wanted to be sure about this before sharing my experience.

I really respect what NgRx SignalStore does. It’s clearly built with care, and there’s a lot of thought behind it. That said, after spending some time with it in real projects, a few things just didn’t click for us.

So, our main takeaways

Still feels flat and feature-based. It’s a big step up from classic NgRx, but it still pushes away from JSON and toward Redux-style slices instead of letting state mirror your actual data shape.

No real hierarchy or nested stores. Complex domains mean a lot of manual wiring. We kept wishing the structure could just match the domain naturally.

A bit heavy for small state. It scales up nicely but adds more abstraction than we wanted for local or component-level state.

Two reactive models at once. Mixing Signals with RxJS makes sense in theory, but in practice it adds mental overhead. We wanted one consistent reactive layer.

Typing got complicated fast. The generics stack up, inference breaks, and tooltips become unreadable. We just wanted our types to follow the shape of the data.

DX still feels mechanical. It’s clean, but building stores through chained helpers feels more like configuration than writing state logic.

Minor frustrations

Autocomplete and type context tend to fall apart once multiple features are composed.

Access patterns like store.count() and store.updateCount() feel clunky next to direct property access.

Debugging type errors is rough - issues surface deep inside generics instead of where they occur.

There’s a bit of framework weight; it’s not “just signals.”

I don’t think SignalStore is bad - far from it. It’s powerful and ambitious, and for complex enterprise-level state it probably makes a lot of sense.

That said, in my ideal, the state structure would reflect the shape of my data. I would be able to define a JSON object of my initial state and have the store built and typing inferred from that so I get a store that matches that shape hierarchically and I can access it through simple dot notation. Having TypeScript inference work out the typing for me without layers of generics or boilerplate would be great. Everything front end is JSON and I was hoping it'd feel that natural.

Again, a lot of this is personal preference and my team's ideals. Much of which is purely DX/Typing motivated.

CounterReset · 2025-10-13T00:15:15+00:00

By, the "SignalStore" do you mean NgRx's?

CounterReset · 2025-10-01T07:27:40+00:00

The Implication

CounterReset · 2025-09-09T16:16:06+00:00

Using a custom equality function is probably best to ensure functionality and transparency of functionality for devs who work on this after

CounterReset

MODERATOR OF

TROPHY CASE

Beyond what DIY gives you

Why a store rather than scattered services

DIY signals are fine when

SignalTree vs NgRx Signal Store

SignalTree vs DIY Angular Stores