getEditor returning undefined

[patrickkforrit]

When trying to follow the example from here:

public initialize(initControls) {
  this.initControls = initControls;
  this.deleteAll = function() {
    this.initControls.getEditor()('html.set', '');
  };
}

initControls.getEditor() is returning undefined in version 4.5.1, npm had updated me because of a security vulnerability.

Workaround is setting npm to use version 4.3.1 which has no security vulnerability and getEditor() is returning an instance.

[zahidkarim24]

The issue you're facing editorInstance being undefined inside the froalaInit handler can happen if the instance isn’t ready yet at that point in Angular. Instead of using event.initialize()You should directly access the editor instance via event.editor Please take a look at the demo example: https://codesandbox.io/p/sandbox/froala-react-4-0-forked-88rh4z?file=%2Fsrc%2Findex.js%3A11%2C1
If it’s still not working, feel free to reproduce the issue in the following example provided above on CodeSandbox.

[patrickkforrit]

Hi @zahidkarim24 Thanks for your response.

It's strange that the editor is available in 4.3.1 but not in 4.5.1 without any other changes to the angular code.

I will try with event.editor and let you know. When I inspected the event previously there was no reference to the editor.

Is this the official way to access the editor now? If so maybe the documentation needs to be updated?

[Jakartoine]

They really created some bugs with the output "froalaInit" event emitter in the v.4.4.0 (see more here).

They updated the way they load the froala-editor js library. It is now loaded dynamically on demand.

Since the froalaInit emits inside the function generateManualController which is directly called by the setup function, itself called inside the ngAfterViewInit lifecycle method, It exists a greater time gap where the dynamic import is still loading the library but the froalaInit has already been called.

If the dynamic import were loaded quicker, we would never have seen any problem (because they already instanced the _froalaEditor property (which is returned in a computed property in your getEditor() func) in a kind of async way due to the encapsulation around ngZone.runOutsideAngular function).

I think that their updates in v4.4.0 just highlight a problem even more that always existed in this froala wrapper.

---

@patrickkforrit
If you want to confirm what I've explained here, you can naturally add a setTimeout of 1/2 seconds and call this.initControls.getEditor() which should cover the delay of the library being loaded.

IMHO and as a permanent good fix, we should definitely find a way to isolate the _froalaEditor property instanciation/loading of the lifecycle methods and so on. If the developer puts the directive on a DOM element, it must mean the developer wants the froala to be loaded whenever it will really use the froala editor. Using this assumption, I would really go for something that automatically loads the froala-editor in the constructor of the directive before doing anything else.

I could check to fix this at some point if someone can validate somehow the approach.