Signal Challenge Series
svenson95 opened this issue Β· 8 comments
I think it's a good idea to discuss about new challenges in the first place. So I've created this "issue" here to talk about it. Hope that's fine.
Since we talked about signal
challenges in my last challenge proposal, I've thought about a cool challenge user story. It might be a 3/4 parts series about signals, including the new input
, output
, viewChild
syntax among other things. My idea would be to create a new section in the challenges (like angular, forms, performance, testing, ...) for signals. That could be a eyecatcher for devs who want to learn more about signals.
Here is our discussion from my last challenge proposal, if you want to look at it again. Feel free to give some feedback to the draft below.
Example:
- Online-Shop application, buying a laptop.
Challenge 1: Signal Effect Bug | bug-effect-signal
- Context: Effect to open alert doesn't work as expected.
- User Story:
- Task 1: fix wrong implementation.
- Bonus Task: refactor implementation with
computed
signal.
Challenge 2: Signal Basics
- Context: Bob π§ββοΈ want's to update the project to the newest version of angular, and take advantage of the new
signal
feature. - User Story:
- Task 1: refactor a
Observable
tosignal
- Task 2: refactor
@ViewChildren()
withviewChild()
(With a suitable example that highlights the advantages)
- Task 1: refactor a
Challenge 3: Computed function with a ternary inside
- Context: You're working an application which has a light and dark theme. Bob π§ββοΈ want's a cleaner way to detect if dark mode is active.
- User Story: refactor a function
isDarkModeActive
with acomputed
signal (computed function with a ternary inside)
Challenge 4: ...
Check out e-oz's medium for a few great signal articles and more ideas.
I like the idea of exploring of some patterns not translating to signals. Like if you use an outside flag
that's not a signal and combine in a ternary with 2 signals. The outside flag doesn't update so the conditional will only be evaluated the first time. Something like this might not warrant a separate challenge, but can be included in the starter code. Maybe, have a loading
flag and conditionally render something different in the navbar.
Bob dove right into converting the app to using signals, but of course, it wasn't so easy and you need to help fix this...
.
Surprisingly, I think a good topic is bindings with signals, as this will be important for zoneless. [value]=βvalueβ
lacks reactivity.
You can have a challenge where you swap computed for effect (or vice versa) and challenger has to swap from one to the other. I think effect has issues whereby it tracks too many things and this can cause performance issues.
Leaking the reactive context and fixing it with untracked
is a must challenge. These scenarios cause leaks: creating an instance of a class that reads some signals, calling a function that calls another function, which reads a signal;
and emitting a new value to an observable.
Since the testing series uses Angular Testing Library, you don't really have to explore difficulty in testing signals.
Yes we need to think about signal challenges. This is indeed a good idea to help people embrace this new reactivity pattern
creating a challenge around untrack is a good idea, but untrack is not used very often
There is many things around effect also. I was thinking of an observable called inside an effect which is never cleanup. It's a bit messy but I'm sure we can find some in all databases π
I haven't got a lot of time recently and I'm still very busy the next two months but then I will start to do new challenges again. v18 will be released soon and some challenges around zoneless is also a good idea.
Maybe, it is best to have a dedicated issue for all challenge ideas. You could make a single comment for each idea.
Here's an article about new Angular 18 features.
Maybe, it is best to have a dedicated issue for all challenge ideas. You could make a single comment for each idea.
Here's an article about new Angular 18 features.
Yeah i started this issue to think about the challenges. We could use the same example for these challenge series, this would be cool imo.
I thought this short video from Josh Morony could be a challenge. When a toSignal
signal has an error and if the signal is read multiple times, there can be multiple alerts or errors thrown. rejectErrors
would have been the simple answer and using catchError in a different part of the stream would have been an alternative solution.
The two step process of converting to an observable with from
and converting to a signal with toSignal
may be required for the behavior.
I tried to recreate it and I wasn't able to get multiple errors. Ionic was used and I think that may have contributed to the behavior. So I have abandoned the idea. This seems like it would be a very infrequent bug anyway since toSignal
behaves like async pipe and swallows errors.
Nice idea, I will try to reproduce it.
This Deborah Kurata video seems like it would make for a difficult challenge.
Essentially, you can use computed
to wrap a read-only
signal with a new signal to make the read-only
signal a writable
signal. Then you have to use ()()
to read that signal.
She uses the case of returning a list from API and how you can't easily add a new item to said list without another request.
It probably would be best to not repeat the same scenario and maybe someone can think of another scenario for such a technique.
With zoneless, global error handling poses problems. It seems like you have to use the window object to capture errors. This could be a potential area to explore in a zoneless challenge. React-like error boundaries
may be added to address this in the future.