When to use Signals in Angular - Decision Tree

When to use Signals in Angular – Decision Tree

The content discusses a problem with resetting and syncing cascading dropdowns in Angular, where changing a root dropdown unintentionally resets a third dropdown. The solution involved moving the reset logic to the linkedSignal, illustrated through a flowchart and decision tree outlining various signal handling strategies in React.

I found this nice flow chart from the video of Deborah Kurata Youtube Channel

I was having issue in resetting and syncing state for cascade drop downs. Where on changing a root dropdown would reset the third drop down in the chain.

I was doing bunch of signal rest explicitly on change of the first drop down linked signal. All I had to do is move reset logic to linkedSignal.

Here is the mermaid diagram of the decision tree

flowchart TD
    A[React to Signal\n Changes]
    A --> |No| B[Use a regular\n function]
    A --> |Yes| C[Set a readonly\n signal?]
    C --> |Yes| D["Use computed()" ] 
    C --> |No| E[Set a writable \n signal?]
    E --> |Yes| F["Use linkedSignal()"]
    E --> |No| G[Perform an async \n operation?]
    G --> |Yes| H["Use resource() \n on rxResource()"]
    G --> |No| I["Use an effect()"]

An ascii tree would look like

React to Signal Changes?
├── No
│   └── Use a regular function
└── Yes
    └── Set a readonly signal?
        ├── Yes
        │   └── Use computed()
        └── No
            └── Set a writable signal?
                ├── Yes
                │   └── Use linkedSignal()
                └── No
                    └── Perform an async operation?
                        ├── Yes
                        │   └── resource()/rxResource()
                        └── No
                            └── Use an effect()

Leave a Reply Cancel reply