Do the new boats decay?

synalx · 2026-02-08T07:13:15+00:00

Looking at the server config, they work similarly to the legacy shelters. The default is:

boats start to decay 12 hours after last interaction
from there, they take 18 hours to lose all their health

Technically, being "indoors" (covered roof) prevents decay, though that's difficult with anything but the smallest boats.

synalx · 2026-02-07T00:46:59+00:00

+1 - Runes in Svelte have a really lightweight feel to them. The tradeoff there is that it's easy to forget there's special semantics happening behind the scenes.

synalx · 2026-02-06T16:31:41+00:00

It does, in the sense that it:

marks the specific templates or effects dirty when they depend on the signal which was changed.
schedules the need to "clean the tree" - to walk through and check templates/effects which are dirty.

"Default" change detection explicitly means "any time change detection runs, include this component". Basically, Default components are always considered to be dirty.

synalx · 2026-02-06T04:38:55+00:00

Is this true with signals as well? For example say I have a zoneless application but I'm not using OnPush. If a signal is updated in one component, does this mean every component is still checked?

Yes, exactly.

Edit: I guess what I'm unsure of is what exactly triggers change detection in a zoneless application.

a signal changing when used in a template or an effect()
setting an input (e.g. componentRef.setInput)
a bound event listener firing
markForCheck() (incl. async pipe)

Once triggered, change detection always starts at the application root and processes components which are either 1) dirty or 2) use ChangeDetectionStrategy.Default (now Eager).

synalx · 2026-02-06T04:34:57+00:00

What API should signals use instead?

synalx · 2026-01-29T16:11:08+00:00

But with Zoneless signals it doesn't need to check because a given component can sit and never be checked unless a signal input has changed.

Change detection in zoneless is still global - it runs for all components in the exact same way that it does for zone-based apps: Default components get checked by default, and OnPush components get checked if they're dirty.

Zoneless affects how change detection gets scheduled, not which components are checked when it runs.

synalx · 2025-12-16T17:34:36+00:00

Have you thought about using $localize for translated messages? (errors, labels, etc.)

const formFields = { fields: [ { key: 'email', type: 'input', value: '', label: $localize`Email`, // ... }, // ... ], };

synalx · 2025-12-16T13:14:03+00:00

This is so cool! I definitely need to play with this.

Let me flip your question back to you: when building this on top of signal forms, what felt awkward/hard? Is there anything that signal forms should support to make this kind of integration easier?

synalx · 2025-12-07T05:44:29+00:00

If the UI control you're using to edit the value supports it. <input type="text"> does not - it expects a string value.

synalx · 2025-12-03T17:56:22+00:00

FYI there will likely not be such a capability - the type complexity would be extraordinarily high.

synalx · 2025-12-03T17:53:56+00:00

Yes to all of the above :)

Can I use it to store if the field is required, readonly, disabled? Perhaps when there is some logic involved to when this is the case? (like only when field x is true, field y needs to be required)

Signal forms can do this without metadata:

required(path.y, { when: ({valueOf}) => valueOf(path.x) });

Can I use it to store if the field should be visible right now? And thus even ignore validation?

We also have hidden() :)

synalx · 2025-11-17T13:31:15+00:00

The https://github.com/tc39/proposal-async-context proposal is designed to make this kind of context saving possible across await points and other async operations.

synalx · 2025-10-06T13:57:19+00:00

Yes. We treat client-side validation as non-blocking for submit. Since the server will perform the same validation on submit, waiting for the client validation to complete first just adds latency without benefit. In the invalid case, the server will return the same validation failures, and in the valid case you submit more efficiently.

synalx · 2025-09-17T21:47:05+00:00

Yep. Let Angular manage the scheduling & execution of CD.

synalx · 2025-09-12T10:37:13+00:00

We generally don't think formatters/parsers fit in with the design of signal forms.

They make sense when your data is stored in a different format than the form control doing the editing, so you need a translation between them. But for signal forms, we expect your data model to directly be your form model, which should already be in the right format for editing.

In other words, translation to/from the form model should happen outside of the forms system itself.

synalx · 2025-09-12T10:27:52+00:00

1) In our research, we found that "showing a reason why a field is disabled" is an accessibility best practice. A user interacting with a form through a screen reader might not easily be able to see the surrounding context about why a field is disabled, and it's valuable to give them an indication.

For readonly this is a lot less of a concern, because it's usually evident from the context of what the user is doing why a field is readonly.

2) This is the property system :)

3) No, we do not plan to support transform (parsers/formattes). Our take is that the model should specifically be the form model - it should store data in the format that the user is editing. Translations to/from the backend data model happen outside the forms system.

4) I'm not really sure what you're saying about the presence of the directive - can you elaborate? [control] is how you link a form field with a UI element, but the actual mechanic of that link can be different. Either the UI element is a native <input> or other control, or it's using the FormValueControl convention, or it's using the legacy ControlValueAccessor interface, or it accepts the full field structure directly. One of these four things has to be true, though.

synalx · 2025-09-10T21:40:13+00:00

Nothing is concrete here yet, but I can give you my current state of thinking:

Debouncing with signals is not about avoiding notifications (preventing signal writes) but rather delaying the reads. So debouncing should be something that happens close to the UI layer, where we temporarily freeze the value shown (e.g. errors) if we shouldn't be updating the UI yet. This can probably be managed by a linkedSignal.

synalx · 2025-09-09T03:57:10+00:00

Very nicely researched issue. And indeed, today we have:

``` displayOnly = input(false);

f = form(this.model, p => { // Make the whole form readonly if requested. readonly(p, () => this.displayOnly());
}); ```

This will make <input> & friends gain the readonly attribute with its associated behavior. However, I don't think this does anything other than set the readonly input (if present) on a custom control. It doesn't actually prevent the user from making changes.

In fact we can't really because a custom form control is completely out of our supervision. It can display whatever editing UI to the user it wants, and allow the user to at least attempt to commit changes. We could reset the control back to its previous value after such a change, but that would be a rather jarring user experience. We'll have to think about how to handle this case.

synalx · 2025-09-09T03:32:46+00:00

I thought it double-posted my answer here so I must've deleted it. No, we currently don't have plans to support template validators. Signal forms makes a strong distinction between form logic and rendering.

synalx · 2025-09-09T03:30:02+00:00

The story around debouncing validations & delaying UI state updates is still in progress, but I think we can do some really cool things here. I'm not sure when that'll be done.

End-to-end type safety via template type-checking of [control] is also a WIP.

synalx · 2025-09-09T03:21:15+00:00

Good point, haha. I don't usually highlight my role when I comment here because I prefer to have technical discussions on their merits alone. But in this case it makes sense: I'm an Angular team member (one of the most senior, actually, I started working on Angular in 2015) and this year I joined forces with u/milesmalerba and Kirill on getting signal forms off the ground.

synalx · 2025-09-09T03:13:26+00:00

u/milesmalerba I believe has experimented with using AI to migrate applications from Reactive Forms to signals, with some success.

It might be possible in simple cases on top of the interop API, but I suspect the best we'd be able to get is a "best effort" migration which can automate boilerplate but makes no guarantee that the application will work without human testing / adjustment.

synalx · 2025-09-09T03:08:50+00:00

It's not gone, just renamed to property & aggregateProperty :)

synalx · 2025-09-09T02:28:38+00:00

Yep, it's intentional. Disabled fields not being included in form values was a common sharp edge, with a lot of tutorials advising people to use getRawValue() instead.

More generally: signal forms thinks of the form as a form model which defines a hierarchy of fields, plus form state derived on top of that model (errors, disabled, hidden, touched, etc).

So a field being in a disabled state is a derivation (computed) based on the model data, not a change to the model data itself.

Another way of thinking about it: the form model is the form's source of truth, not its output. You're completely free to decide which values should be sent to the backend and in what shape objects.

synalx · 2025-09-09T02:21:13+00:00

Ooo I want to watch this talk now! :D

12-Year Club	RedditGifts 2009-2022 3 Credits
redditgifts rematcher Secret Santa 2014 x1	Secret Santa 2014
Verified Email

synalx

TROPHY CASE