DevFestPoland

Let me elaborate on why I'm so 🕺 excited about this draft PR: When you have a signal({x: 1, y: 2}), you often need a separate Signal for x and y, e.g., for binding it to a form or making changes more local. Other frameworks, such as @solid_js, use nested signals. This leads to a Signal<{x: Signal<number>, y: Signal<number>}> in our case. As working with such a type is not especially fun, @solid_js creates this structure underneath the covers, hidden behind a Proxy and Getters and Setters. This leads to a smooth DX. However, Angular has always been quite explicit, and hence, the idea was not to hide Signals from us. Now, this PR shows a way to get the best of both worlds: We start with a signal({x: 1, y: 2}) and then derive a deep signal for x and y on demand. This is quite idiomatic, as Signals are all about deriving state. Both can be bound to a form field, for instance. If you change the Signal x, the value will be updated in the parent signal, and notifications for the Signal y will be skipped. If we go with a structuralSignal({x: 1, y: 2}) in the first place, notifications for this parent Signal will be skipped too. ➡️ So, this is a very ergonomic and elegant solution for a difficult challenge, proposed by Angular's @synalx. A good use case for this is forms, particularly the upcoming Signal Forms and the migration of existing Template-driven forms to Signals. Please note that currently this is a draft PR... teapaw.org/ManfredSteyer/status/1…

Now also on dev.to dev.to/angular/sustainable-a…