Choosing an Angular Report Builder
I was recently given the task of providing a WYSIWYG (What You See Is What You Get) editor for a client to produce a report of a selection of their data. The data management system was written in Angular so I needed the WYSIWYG editor to fit into the angular framework. Beyond the basic expectations of a WYSIWYG editor, we needed it to accomplish 3 main things:
- Load a pre-generated version of the report into the editor
- Allow for custom functionality to insert pre-generated elements into the report
- Print the report
Basically, we needed the ability to pre-generate HTML from their data and pre-load it into the editor for adjustments, and make adjusting the report as easy as possible for the end user (via custom functionality in the editor). Users also needed the ability to print the contents of the WYSIWYG once they were finished. I googled around for a bit and found 4 editors worth some investigation:
I chose to look deeper into the ngWYSIWYG and angular-wysiwyg editors because they were specifically designed with Angular in mind, which is what the client’s site was using. Wysihtml made the cut because one of the first things it promises is, if attached to a textarea control, the generated HTML from the editor will be the textarea’s value. Finally, TinyMCE was worth including because of the robustness of the documentation for it, and the plug-in capabilities of the editor (to add new functionality).
I quickly ended up discarding the angular-wysiwyg editor because, as I looked into it, I found that Bootstrap was a requirement. For various reasons, my client could not use Bootstrap so that was out.
Next, I looked at the other angular editor – ngWYSIWYG – and with my first once-over it looked pretty decent. Plus, it had the benefit of being in Angular, so it made it past round 1. Similarly, TinyMCE looked great as I demoed it, and it certainly has an active community of users and developers singing its praise, so it too was worth diving deeper into. The wysihtml editor didn’t have anything specifically wrong with it per se, but just by virtue of being the weakest candidate amongst my 3 remaining choices, I decided against pursuing it.
This left me with an Angular WYSIWYG editor and a non-Angular editor. I initially thought the Angular editor was going to win this battle royale simply by virtue of being in Angular and thus fitting in nicely with the framework already in place on my client’s site. However, as I started to play with the two editors more in-depth, it quickly became apparent that TinyMCE would be much easier to work with from a development perspective – specifically adding new functionality. The documentation for TinyMCE‘s API is superb and the community support is top-notch, plus there are all sorts of plugins to choose from (including printing!) to add additional functionality.
Since I didn’t specifically NEED this editor to do anything angular-y, documentation and ease of adding new functionality to TinyMCE ended up tipping the scales in its favor. And now, after having worked with it for a few weeks – adding new buttons, custom element insertion popups, custom printing – I must say it was the right choice. I even managed to wrap it in an angular directive to quasi-angular-ify it! The documentation alone made working with TinyMCE so much nicer than it would have been otherwise. And my client has yet to come up with something they’d like added to their report editor that I haven’t been able to accomplish with relative ease.