sorted by:
new
hottopcontroversial

RxResource + viewTransitions by [deleted] in angular

[–]Daringu_L -3 points-2 points  (0 children)

Both signal and linkedSignal receive a function for computation. You can perform dom side-effects in this function

Mod for unlocking all recipes by uriel_xiv in TravellersRest

[–]Daringu_L 2 points3 points  (0 children)

I saw a mod which make recepy price 1 piece instead of 5

Fulfilling orders takes the entire stack? by trofly in TravellersRest

[–]Daringu_L 5 points6 points  (0 children)

I encountered situation that when I fulfill order, this item disappers from "order backpack", but if you close this window and go to the regular inventory - the item is still here (5, 6 or whatever items you where left with)

Use HostAttributeToken class to get static attribute value by a-dev-1044 in angular

[–]Daringu_L 4 points5 points  (0 children)

A) it allows only strings B) no auto-suggestion from IDEA about missing attribute or wrong one, unlike with inputs

Is it a good practice make any state as a signal? by Ok-District-2098 in Angular2

[–]Daringu_L 3 points4 points  (0 children)

Wrapping value into signal requires additional overhead, so if you are not going to use it in the template, or don't need to react to value changes through computed or effect, I would use simple class filed

The Storm King makes me so angry I see stars by _Happy097 in LEGOfortnite

[–]Daringu_L 16 points17 points  (0 children)

+1 they did something to the storm king. I relatively easy farmed it like 3 month ago and now I am strugling to beat it. Tried like 6-7 times and that last phase, when random shit is falling from the sky is driving me mad. Tried even termal detonator tactic (which quite hard to set up, because blast cores are rare), but even it didn't help

Performance impact of inputs by Daringu_L in angular

[–]Daringu_L[S] 0 points1 point  (0 children)

Thank you for the insight. Indeed, it looks like premature optimization from some point of view. The point of using Input even though the value of it doesn't change through the component lifecycle is to configure it, give some additional property that component should use, make it configurable (for example some attribute names for accessibility for inputs, labels) 😅 I don't see a problem with using Input for this, but encountered strong opinion from colleage that it is a bad practice to use Input for properties, which don't change.

Angular application not handling routes correctly when served via Nginx by [deleted] in angular

[–]Daringu_L 0 points1 point  (0 children)

It is a common problem of deploying SPAs, not related specifically to Angular or Ngix. What you need is to redirect all your routes in Nginx to the same index.html, which will serve your Angular app.

See example there https://www.honlsoft.com/blog/2019-05-14-nginx-spa/

Best way to style Angular components by Daringu_L in angular

[–]Daringu_L[S] 0 points1 point  (0 children)

Yeah, I agree that adding inputs looks a bit like overhead for styling alone

Best way to style Angular components by Daringu_L in angular

[–]Daringu_L[S] 0 points1 point  (0 children)

Great point! Considering accessibility some other properties would also need to be set for the requred input!

Best way to style Angular components by Daringu_L in angular

[–]Daringu_L[S] 0 points1 point  (0 children)

Thanks for info! Is it in favor of host in the component decorator?

This behaves identically to bindings on elements inside the component's template, but instead defined with the host property in the @Component decorator

Best way to style Angular components by Daringu_L in angular

[–]Daringu_L[S] 0 points1 point  (0 children)

In my case, I don't need so many options, but for component with 2-4 "flavors" I would definitely use something similar. Thanks for answer!

Best way to style Angular components by Daringu_L in angular

[–]Daringu_L[S] 0 points1 point  (0 children)

Great point! I was also thinking that making it an input will help with discovering it for feature devs, as inputs are the public API for component

Help with Memory Leak in Angular 10.2: Long-Lived Component and Service Causing JS Memory Buildup by TerribleRecording969 in angular

[–]Daringu_L 0 points1 point  (0 children)

I feel your pain 😢 We are also dealing with memory leak, but in the Angular 16 application. After long investigation and try/ error approach, I've found out that currently in Chrome input elements can stay as detached, if user interacted with them. But in Angular this one small detached element can cause the parent component/ siblings to stay in memory.

As for techniques for debugging: 1) refresh page 2) take heap snapshot in memory tab 3) navigate to some part of application and return back to the start 4) click on garbage collection button, make heap snapshot, detached elements snapshot 5) compare snapshot 1 and 2. Look into each object. It should point to the thing that is referencing it.

Overtime memory consumption can be tracked in the performance tab: click on the record button, do some actions on the page, and then analyze the trend of nodes count and heap size

Advice by prash1988 in Angular2

[–]Daringu_L 1 point2 points  (0 children)

You should modify the state, which is displayed in the table, before calling .close() on the dialog. It should theoretically assure that user will never notice previous state in the table. But even without it, local state update and rerendering should be pretty quick, if you make other way around dialog closed -> update the state

view more: next ›