Replies: 120 comments 562 replies
-
I advise you to take a look at the following signal implementations: artalar/act, nanostores/nanostores. |
Beta Was this translation helpful? Give feedback.
-
Amazing. Can't wait to see the prototype 😃 |
Beta Was this translation helpful? Give feedback.
-
Thank you for the transparency. I've taken a look at the code and "WOW!". This specific test puts a smile on my face. |
Beta Was this translation helpful? Give feedback.
-
Here are a few libraries you may find interesting for the prototyping phase: https://github.com/damianstasik/awesome-reactivity |
Beta Was this translation helpful? Give feedback.
-
I would also add Effector to the list https://github.com/effector/effector |
Beta Was this translation helpful? Give feedback.
-
I do not like dirty functions (functions with the internal state, AKA “hooks”), I think that functions should be pure and for keeping the state we have class instances. So, the fact the “hooks plague” is corrupting Angular is bad news for me, but if it will help us to get rid of zone.js - amazing. Because zone.js is much worse. |
Beta Was this translation helpful? Give feedback.
-
So basically after 7 years of development you figured out that RxJS is "doesn't fit all the needs" huh? |
Beta Was this translation helpful? Give feedback.
-
Angular is the best framework |
Beta Was this translation helpful? Give feedback.
-
Exciting development. Thanks for all the work and for the team's transparency along the way. |
Beta Was this translation helpful? Give feedback.
-
I hope it will not have too much impact on the existing development model. |
Beta Was this translation helpful? Give feedback.
-
Awesome! |
Beta Was this translation helpful? Give feedback.
-
I kinda want to stress-test this RFC with some questions that the Angular team may want to consider:
Those are just some questions I can think of at the moment, and I'll update this comment when I think of more questions. I am sorry being a pessimist with this RFC, and I am not trying to shoot this RFC down; however, RxJS is a critical part of Angular, and replacing it will cause millions of websites to break if this RFC is not handled carefully. If this RFC goes through, I would suggest creating an extended LTS version or a compatibility mode, so websites have a good window of time to migrate before the pre-RFC versions sunset. |
Beta Was this translation helpful? Give feedback.
-
Thank Angular team! I have been watching the progress of optional zone for many months. It is fantastic to adopt signal fine-grained reactivity to Angular core. Will the signal be able to run outside of component like Solidjs? If it does, that will be super helpful to reuse/organize many common logics. |
Beta Was this translation helpful? Give feedback.
-
wow congratulations 🥳🥳 |
Beta Was this translation helpful? Give feedback.
-
Should be a great addition! I guess it might change how we look at state management. Is there any thought how signals can enhance state management? Or maybe even a native angular solution? |
Beta Was this translation helpful? Give feedback.
-
the problem with that is that you just can’t see code organization as a problem. You’re talking about attacking “real” problems, get things done. Quickly. Forcefully.
But it’s not how the reality is. In reality first come codebase. Already existing code base which already do something. And the business consider it's working fine.
Then they throw at you problems. And you need to code them. All while keeping previously established correctness of your application intact.
So reality is not implementing new features, no! Far from that! Reality is CONTINUOUS REFACTORING. And for that you need to keep your code in certain state,
Always ready to be refactored. And this state is what they call "referential transparency”, keeping everything in pure functions. Or FP.
And when you see reality in this light you will see that this “pure” code organization will also lead you to “correct” implementations of your problems.
Not the other way around.
(But yeah, I’m talking about real programming, not about those cases when you just every time rewriting everything from scratch in what fashionable at the moment manner)
… On Mar 10, 2023, at 5:07 PM, Timon ***@***.***> wrote:
Are we now philosophers? Is it really a discussion about signals in angular anymore?
I think there are real world apps that are roughly at this level of complexity and for that I would consider anything that is not straight forward to implement over engineered. Since I am interested in how it is practical in the real world.
—
Reply to this email directly, view it on GitHub <#49090 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMUAE6Q2WXJPIDULO6Z54DW3M7UJANCNFSM6AAAAAAU5H2RGI>.
You are receiving this because you were mentioned.
|
Beta Was this translation helpful? Give feedback.
-
I'm just replying to comments in my email. It says “ Reply to this email directly”. So I do.
but ok, I think I made my point. I will probably unsubscribe now as this will not lead to anything and not exactly interesting to me anymore
… On Mar 10, 2023, at 5:16 PM, Clara Castillo ***@***.***> wrote:
@robounohito <https://github.com/robounohito> it's really hard to follow a discussion if you make a new comment every single time. Just reply directly to the comment you want to anwer to... Now the whole thread is cluttered...
—
Reply to this email directly, view it on GitHub <#49090 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMUAEZEJDLUXMTOLGQNXRLW3NAWRANCNFSM6AAAAAAU5H2RGI>.
You are receiving this because you were mentioned.
|
Beta Was this translation helpful? Give feedback.
-
I was reading about How would E.g.
I thought that a Signal always has an initial value... |
Beta Was this translation helpful? Give feedback.
-
Would there be an equivalent to ngrx component store selectors with signals? So, when you have a more complex state object with multiple properties in it and your component is only interested in getting updates on one of them, will this be possible and how will it look like with signals? |
Beta Was this translation helpful? Give feedback.
-
Already on its way :
ngrx/platform#3796
W dniu sob., 11.03.2023 o 13:26 Jan Wedel ***@***.***>
napisał(a):
… Would there be an equivalent to ngrx component store selectors with
signals?
So, when you have a more complex state object with multiple properties in
it and your component is only interested in getting updates on one of them,
will this be possible and how will it look like with signals?
—
Reply to this email directly, view it on GitHub
<#49090 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFKBQQOD7U7X6MNUQCKJXADW3RVRBANCNFSM6AAAAAAU5H2RGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Just an idea, looking at the current implementation of the graph that keeps tracks of dependencies and versions https://github.com/angular/angular/blob/main/packages/core/src/signals/src/graph.ts specifically at the notification implementation. ie:
This keeps track of the versions at the edges, could this be replaced with https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Atomics/waitAsync |
Beta Was this translation helpful? Give feedback.
-
The prototype of the RxJS interop in this PR looks very promising: https://github.com/angular/angular/pull/49154/files Here a small idea to push RxJS interop one step further (based on the new
|
Beta Was this translation helpful? Give feedback.
-
One more thing I thought about is how would signals play with It adds up to the type safety guards in And lastly the ngIf problem whether to use the |
Beta Was this translation helpful? Give feedback.
-
Hey guys, im still having fun with signals, i also couldn't resist and had to test fromSignal/fromObservable Live demo: https://playground-angular-signal.netlify.app/ Repo: https://github.com/viniciusschuelter/playground-angular-signal |
Beta Was this translation helpful? Give feedback.
-
What I find funny with signals with We also can use signal with async pipe! |
Beta Was this translation helpful? Give feedback.
-
@pkozlowski-opensource
|
Beta Was this translation helpful? Give feedback.
-
Please, consider adding something like class ExampleComponent {
@Input() standardInput: number;
@SignalInput() signalInput: Signal<number>;
} without this we would need to create setters and private fields that sets these values as signals |
Beta Was this translation helpful? Give feedback.
-
You're solving one of the interesting problems in Angular. Hats off!!!! That said, this got me extremely curious, and have some questions/comments! :)
Once again thank you so much for your awesome work! |
Beta Was this translation helpful? Give feedback.
-
So, I managed to remove I also created a method to transform signals to observables. With several cancellation mechanisms - because we must cancel on ngDestroy, right? My personal favorite is using the native 'AbortController' (because I think it's the simplest - and is guaranteed to not dangle in memory, unlike a signal, observable, or promise). https://stackblitz.com/edit/angular-3xsgv1 Do check it out and tell me what you think. I think, with this, we can start using signals today, and if we don't use libraries that depend on zone.js (like angular material), we can even get rid of zone.js. EDIT: I added a 'signal' pipe which transforms the signal into an observable so that we don't have to. I have provide both the templates - with and without the signalPipe. The observables can be commented out when using the signalsTemplate, leaving us with signals from start to finish (except in the helper functions, obviously) |
Beta Was this translation helpful? Give feedback.
-
Thousands of reactions, over 650 comments, many questions, and several discussion topics! This is the level of interest that we didn’t anticipate, but are grateful for. Thank you for taking time to comment, share feedback, and engage in deep technical discussions. It is clear that the Angular community cares as much as we do. We’ve read and re-read every single comment and responded directly to many. Looking at the discussion as the whole, there are some clear patterns worth addressing. First of all we should acknowledge that this is a significant change and improvement to the Angular inner workings. This is not the change we are taking lightly: backward-compatibility is non-negotiable and we do everything to assure that the existing applications and libraries continue working as-is, without any modification. This is a gradual, opt-in change. As any other substantial change, the idea of introducing reactive primitives and modifying change detection, generates lots of questions: both philosophical (“Where is Angular heading?”), architectural (“What about zone.js or RxJS?”), technical (“What is this API doing?”) and tactical (“When?”). More specifically, we’ve noted the following questions that generated most interest: Backward compatibility and ecosystem evolution:
Architecture
Role and place of RxJS
Signals library:
Project plans:
We plan to address all those questions (and more!) in the RFC that we intend to publish in the coming weeks. We’ve spent hundreds and hundreds of hours discussing every aspect of this proposal and can’t wait to share design and technical details with you all. Stay tuned! |
Beta Was this translation helpful? Give feedback.
-
tl;dr: we've begun some prototyping work around adding signals as a reactive primitive in Angular, in advance of a formal Request For Comments (RFC) which we plan to open soon. Prototyping early and in the open aligns with our team values and allows us to get the most out of an RFC.
If you've seen our talk from ng-conf 2022, Angular: A Design Review 10 Years Later, you know we've been thinking long and hard about some fundamental design decisions of the framework. Last year, we kicked off a long-term research project with an ambitious goal: to embrace fine-grained reactivity in the core of the framework.
In a fine-grained reactive web framework, components track which parts of the application's data model they depend on, and are only synchronized with the UI when that model changes. This is fundamentally different from how Angular works today, where it uses zone.js to trigger global top-down change detection for the whole application.
We believe adding built-in reactivity to Angular unlocks many new capabilities, including:
ExpressionChangedAfterItHasBeenChecked
errors.Changing the reactivity model of an established framework like Angular is a significant project, with numerous challenges. Our plan for this project is broken out into multiple phases:
Over the last few months, we've progressed through the first and second stages of this project, and have converged on a design based on the well-known reactive primitive of signals. During our experimentation we felt that this design demonstrated the strongest alignment with our overall goals.
Signals are not a new idea in the framework space - Preact, Solid, and Vue all employ some version of this concept to great success. We've taken a lot of inspiration from these and other reactive frameworks, and we are especially grateful to Ryan Carniato of SolidJS for his willingness to share his expertise and experience in many conversations over the last year.
That said, requirements across frameworks differ widely, and we've designed our version of signals to both meet Angular's specific needs and as well as take full advantage of Angular's unique strengths. Even though it's still in the prototype stage, there are a few aspects of our design which we're particularly proud of:
WeakRef
to avoid explicit lifecycle management of signalsWe've begun prototyping this design and will be integrating it into Angular over the next few months. We're committed to our open source spirit and plan to conduct these prototyping efforts in the open. This prototyping is essential to proving that our design for signals in Angular is viable and allows us to progress to a community RFC. The RFC will cover the rationale for using signals and the detailed design of various parts (our implementation, integration with RxJS, and other topics related to this effort).
We strongly believe that adding built-in reactivity to Angular is in the long term best interest of the framework and its users, and look forward to sharing more information about this project in the upcoming RFC.
FAQ
When will the RFC be?
Sometime later this year, depending on how smoothly the prototyping efforts progress.
Why signals as the reactive primitive?
This is a great question, and one which will be thoroughly discussed in the upcoming RFC. In short, signals have many of the properties we identified as desirable in a reactivity system designed for Angular, including:
Why are you committing code before the RFC?
There are a few reasons why we've chosen to begin prototyping before opening an RFC:
We feel having a real prototype will amplify the value we can gain from an RFC, as we will be able to share more detailed designs and ask more precise questions.
In any major design, there are challenges and constraints which only become visible at the scale of a full prototype. We want to uncover these and account for them in the RFC itself.
Many technical problems are unrelated to the overall reactivity system design (such as how it will integrate into Angular's change detection algorithm). We want to tackle these problems sooner rather than later.
Google's internal codebase has a different set of build tools and constraints than the external ecosystem, and early prototyping is necessary to validate our designs in that environment as well.
Beta Was this translation helpful? Give feedback.
All reactions