Ember Textarea and wysihtml5

1

Hello. I’m new in EmberJs and I have problem with this code:

 {{textarea type="text" id="some-textarea" value=model.content rows=40 cols=40}}

    <script type="text/javascript">
        $('#some-textarea').wysihtml5({
            toolbar: {
                "font-styles": true, //Font styling, e.g. h1, h2, etc. Default true
                "emphasis": true, //Italics, bold, etc. Default true
                "lists": true, //(Un)ordered lists, e.g. Bullets, Numbers. Default true
                "html": true, //Button which allows you to edit the generated HTML. Default false
                "link": true, //Button to insert a link. Default true
                "image": true, //Button to insert an image. Default true,
                "color": true, //Button to change color of font
                "blockquote": true //Blockquote
            }
        });
    </script>

Unfortunatelly, Ember can’t catch the value from textarea(model.content). How I can fix this ?

2

I do not think that direct embedding scripts into a template is a good idea. It would be much better to use didInsertElement event:

didInsertElement: function () {
  this._super(); // Do not forget to call super method!

  Ember.run.scheduleOnce('afterRender', this, function () {
    // Your code here
  });
}
2 Likes
3

You don’t have to call _super in this case, didInsertElement is defined as Ember.K which is a function that returns this, ie it doesn’t do anything. Read more here http://ember.zone/what-the-hell-is-ember-k/

Also I don’t think you need to use scheduleOnce either, my experiments so far have indicated that it only get called once after the DOM element is inserted.

There are a few other common gotchas when wrapping a third party UI Component in an Ember.Component such as cleaning up your code and wrapping event handler logic in an Ember.run call. To see a full example of wrapping a third party UI Component in an Ember.Component I’m actually working on a cookbook recipe which you can see here, it’s not done yet but it has what you need.

4

I think it’s just good practice to call _super in most situations, and only leave it out if you understand why you can leave it out. It’s very easy to get into a habit of not including these sorts of things, which can cause some weird issues later.

1 Like
5

Agree. To me the same goes about scheduleOnce. I prefer to explicitly express my wishes. If I want something to run only once, then it is better to define it so if I can.

6

If you’re concerned about calling _super I would recommend using the event instead. To me calling _super without understanding what it is doing is also not really that great a practice to get into either.

initElement: function(){
  // Your code here
}.on('didInsertElement')
----- UPDATE -----

I thought about this more and was more on the fence after thinking more especially because I’ve noticed a push away from the native extensions in recent times. Sooo I poked around to see if I could find any core team members using didInsertElement to see what they did. I found a case of @stefan explicitly mentioning to not use prototype extension AND to he added _super https://github.com/stefanpenner/emberx-select/commit/2a344765f37f614619d8a27f277dd8c139fb7f15. I stand corrected.

----- END UPDATE -----

As for scheduleOnce, I again disagree that it’s a good idea to call it explicitly without the need. Adding in unneeded code in the name of making things more explicit isn’t always a good idea. For instance you could could also explicitly check that the dom element is not null but we don’t because we know that didInsertElement ensures the dom element will be present.

I may have overstated my lack of clarity on if didInsertElement can get called multiple times per run cycle, I’m sure enough that I never use scheduleOnce in didInsertElement. I just haven’t read the exact words in the documentation and haven’t done a deep dive into ember code to know for certain.