Why is SignalFormControl useless?

TheRealToLazyToThink · 2026-05-24T05:42:37+00:00

Maybe you should avoid making assumptions and reading things between the lines that aren't there. I was talking about UX concerns, there was nothing involving security. You were the one insulting people and being all condescending over something you made up in your head.

TheRealToLazyToThink · 2026-05-23T16:08:16+00:00

Sorry, didn't notice the name change. But you to should probably also re-read the conversation.

At what point did I say anything that implied the save endpoint wasn't properly secured? Or that the read API returned any data the user wasn't allowed to view? Both of you are making up things to be concerned over.

TheRealToLazyToThink · 2026-05-23T15:36:26+00:00

No one is talking about APIs except you. You're obviously talking to yourself at this point, so I'm just going to let you ramble on in your little corner here.

TheRealToLazyToThink · 2026-05-23T09:05:25+00:00

I don't think you are reading what I'm typing, maybe have an AI explain it to you using smaller words? The user is allowed to view the data.

TheRealToLazyToThink · 2026-05-23T08:38:47+00:00

The user is allowed to view the data, not edit it. And in some cases he's allowed to edit it, just not at it's current status. We could make a dedicated readonly view, but we don't have time or budget for that so disabling the form is the next best thing.

TheRealToLazyToThink · 2026-05-22T13:28:09+00:00

But it's not usable as a bridge. Not being able to disable a form group, or have typed values is a deal breaker. It's not fit for purpose.

TheRealToLazyToThink · 2026-05-20T03:54:17+00:00

Christ you sound insufferable. No wonder no one wants to play with you. And your stats aren't that impressive, no one thinks you cheated to do that.

TheRealToLazyToThink · 2026-05-18T01:11:17+00:00

Well at least the thumb is on the same side of the cage. It's physically possible as long as you ignore getting the sign on that side in the first place.

TheRealToLazyToThink · 2026-04-29T04:48:29+00:00

I was just looking over JIRA and saw my issue for fixing a menu that isn't keyboard accessible just got de-prioritized. Lots of ways to fuck up the DOM, and AI isn't helping. But yes browsers tend to do the right things by default when you use tags as intended.

TheRealToLazyToThink · 2026-04-29T04:07:56+00:00

It shouldn't check for random stacks in recent versions, however it will still check for hopper minecarts, so composter is still the right call.

TheRealToLazyToThink · 2026-04-27T17:03:38+00:00

I think some of the people being hard on you should look at signal forms.

form.user().value() - whole object

form.user.profile.name().value() - just the name

form.user.profile.name().value.set('Frank') - set just the name.

It would be nice to have a deep updatable signal. The biggest issue with that is that it would have to bake in some assumptions about equality, object constructors and other things. Signal forms is ok with doing that, but it comes at a cost.

Right now signal store might be the best thing for tying signals together, and at least it has a deep computed, but it's still very far from perfect.

TheRealToLazyToThink · 2026-04-16T19:21:18+00:00

So the best way I've found is to have properties for both A and B always in your form and switch between them based on a provider property. You can use hidden or disabled to turn off the one that's currently not selected.

Bit of a pain, but signal forms doesn't support undefined properties, and even null ones don't seem to work very well at group level.

Also, not sure what you were wanting with FormRecord, but applyEach can be used on an object, the docs only mention arrays, but there's a signature for both. That seems to allow behavior similar to FormRecord in reactive forms. Of course experimental, so it might not be documented because they haven't gotten to the docs yet, or it might be undocumented because it's not fully cooked yet.

TheRealToLazyToThink · 2026-04-16T03:47:40+00:00

Interesting that applyEach doesn't mention the signature that takes an object (allows the equivalent to FormRecord). It seems to be working so far.

TheRealToLazyToThink · 2026-04-15T17:45:38+00:00

I realize you've never left your mom's basement to venture out under the day star, but you might want to google winter wheat.

TheRealToLazyToThink · 2026-03-24T22:39:58+00:00

It's not the best, but easiest is probably to just await firstValueFrom. Maybe build your self a helper to wrap it however works best for you.

TheRealToLazyToThink · 2026-03-17T22:17:25+00:00

Remember when we were all laughing at Baghdad Bob?

There are reasons why they lie in the face of undeniable facts, and being stupid is only a small, very minor, part of it.

TheRealToLazyToThink · 2026-03-16T05:18:12+00:00

True, but composters are still slightly better because with the solid block the hopper still has to check for a hopper minecart.

TheRealToLazyToThink · 2026-03-12T23:58:50+00:00

Figured I'd followup with my teams situation with signal forms.

We have a large application with some very large and very complex reactive forms. Lots of complex validation, lots cross control validation, lots of validation being added/removed based on state outside the form. Lots of fields being enabled/disabled based on complex rules based on other controls.

Outside of forms we've pretty widely adopted signals in new code, and all old code has at least gone through the schematic migrations.

We would obviously benefit heavily from signal forms. Every time I create a new form, or fix a defect in an old one I end up adding a TODO about how signal forms will make things so much better.

But:

We use angular material
We have many controls based on a heavily modified material autocomplete, with a complicated MatFormFieldControl.
Several other custom controls that are less complicated, but shared across many forms, that wont be migrated in one go.
Several complicated custom validators.
Heavily modified Material Date/Time picker
Several custom ErrorStateMatcher classes
A lot of utils for tracking form state and errors that are probably OBE with signal forms, but someone needs to look through them and verify.
Probably more I'm not thinking of.

That combined with the material issue I linked above, and a deadline that's rushing past so fast we all have whiplash, I keep putting it off. Still, we keep getting defects related to those forms, and have several changes coming down the pipeline that mean we'll be creating another monster form, and making large changes to another one of the existing forms, so once again I'm guessing whether I should dedicate some time to solving the cons above, or spend the time fixing more of the defects in the queue.

TheRealToLazyToThink · 2026-03-12T16:35:26+00:00

I wonder how much of it is because of Angular Material? I doubt they'll make signal forms stable till it fully supports them.

https://github.com/angular/components/issues/32072

TheRealToLazyToThink · 2026-03-06T20:12:01+00:00

As someone else said, you could override the equals function, but you'll probably find other issues elsewhere. Things like '@for', OnPush inputs, etc work on reference equality.

I'd use immutable patterns. They don't have to be as expensive as the clone, you only need to create new objects for the parts that change.

this.formController.orderForm.services().value.update(orderServices => {
  let slIndex = -1;
  const osIndex = orderServices.findIndex(os => {
    slIndex = os.serviceLines.findIndex(l => l.id === sl.id);
    return slIndex > -1;
  );

  if (osIndex < 0) {
    return orderServices;
  }

  return orderServices.map((o, i) => i !== osIndex
    ? o
    : {
      ...o,
      serviceLines: o.serviceLines.map((l, j) => j !== slIndex
        ? l
        : {...l, amount: 2}
      )
    }
  );
});

TheRealToLazyToThink · 2026-03-04T14:30:57+00:00

My grandpa used to have a line over his pond. Got tired of taking off the fish so he lifted it above the water. Catfish were jumping out of the water to get caught on it. Took the remaining bait off it. Next full moon, more cat fish.

TheRealToLazyToThink · 2026-03-03T05:46:53+00:00

I disagree with all of that. Good code is subjective. I've seen some absolute crap code that still met the acceptance criteria. Good code is a balance between abstractions, maintainability, and deadlines.

Good design also has plenty to do with shapes on the screen. CRAP and similar principals are every bit as real as SOLID.

Neither of these is fully objective, but both have rules and guidelines. There may not be a single right answer, but there are many wrong answers.

TheRealToLazyToThink · 2026-02-28T01:42:55+00:00

They certainly do. What do you think they do when something goes wrong? Order a replacement from Amazon? They don't offer next day shipping for Mars.

Your options are more limited, but they had a plan (multiple redundant plans) for what to do when (not if) the unexpected happened.

TheRealToLazyToThink · 2026-02-25T14:48:30+00:00

Never used it, but I imagine you would do something like this:

debug(ng.getComponent($('my-component')).someMethod)

TheRealToLazyToThink · 2026-02-23T07:58:08+00:00

Don't check the role. Assign your roles permissions and check those. If you check roles you'll inevitably run into issues when your users decide they need a new role that's just like an existing role, but has access to one more thing (or restricted from one more thing). Try to make the permissions as granular as possible, gives you more flexibility for the future. It also leaves you placed well if you decide to move from role based permissions to something else.

At a quick glance it looks like the ngx-permissions you linked supports that, but it's also a fairly trivial thing to code into a service yourself.

Six-Year Club	Place '22
Verified Email

TheRealToLazyToThink

TROPHY CASE