Conversation
|
@cbou Thanks for the PR! My hunch is that this change, while well-motivated, is not something we're likely to want to champion. There are two reasons for this:
This is just my personal opinion, and I will let other core team members chime in if they think this is something they'd like to champion. |
|
@cbou Can you describe a scenario where you'd like to use this feature? Hopefully, we can describe an alternative observer-less implementation in case future readers run into the same issue. |
|
My scenario is an edge case. I have a model which is save by our legacy code in JavaScript and then pushed back to ember store. When a user create one model and quickly want to open it, I have to wait until the legacy code a persisted it to our backend. I do it with an observer which is removed once it's fired. We move to EmberJS with several steps and we kept a lot of our legacy code so it's hard for us not to use observers. I'm pretty sure we won't need observers once we move everything but it will take some time since we want to also add new feature to our product. I read a lot that observers are bad and will be removed. I understand that but since there are no real alternative it's a bit frustrating for me to use them. I'm not speaking for this particular RFC, just in general how observers are cared. @tomdale you are right, if EmberJS will move away from observers this RFC is a waste of time. |
|
We discussed this RFC at the core team meeting today and had consensus that we do not want to expand the API surface area for observers at this time. We're moving this RFC to Final Comment Period to allow folks who have not had a chance to weigh in an opportunity to do so. Assuming no new substantive issues are raised in the next week, we will close the RFC at that time. |
|
@cbou - Thank you again for your work on this, I'm sorry that it didn't work out as a go forward feature. I look forward to your next RFC 😃. |
No description provided.