-
Notifications
You must be signed in to change notification settings - Fork 113
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
the [data]="text" property not updates if text variable was changed #215
Comments
@ma2ciek, can you take a look at it? |
This is my question as well. |
Sorry guys for the late response, I'll take a look. |
any update on this |
has anyone solved this problem? |
This topic is quite large (detecting the input properties changes) and the |
Hi guys, soon 1 year anniversary of this case. Nothing special, but I think any dev meet this issue want to ask why so obvious bugs don't fix for so long time? there no problem with runtime, it's just about data binding. Anyway, hope you will resolve this issue sometime. |
Fixed the bug outline in the issue ckeditor#215 where the angular component does not update the editor contents on changed data property. Implemented OnChanges interface that checks if the data property has been changed. If it has been, then we write a new value to the editor. Lastly, added one more unit test case to assert the fix.
Hello guys. I noticed some interesting behavior with ckeditor5-angular. So regular template of the editor:
if the text property was changed by
@Input()
after the config is set - so text can't be changed inside the editor anymore.For example:
I set up the field. set the config. text is still
undefined
. Editor loads with no text inside.The
@Input()
receive variabletext
changes - and there some text already. But it isn't going forward to the<ckeditor>
component. It does not affect this change of [data] unfortunately. As for me - it happened because change detection does not work as should inside component.BTW we could use ngModel,
and it will be automatically updated/bound/etc, but - the question is - is it a non-overengineering way for this case? or do we need to have the working DI there? Am I wrong?
The text was updated successfully, but these errors were encountered: