1
votes

Dois-je toujours inclure this._super (... arguments) lors de l'écrasement d'une fonction membre Ember

Dans Ember.js, il y a beaucoup de fonctions qui nécessitent que vous appeliez this._Super (... arguments) avant de les appeler. Un exemple rapide tiré de la documentation:

import Component from '@ember/component';

export default Component.extend({
  didRender() {
    this._super(...arguments);
    console.log('I rendered!');
  }
});

Y a-t-il des cas dans Ember où nous n'avons pas besoin d'appeler this._super () ? La raison pour laquelle je pose la question est que souvent, j'écrirai des crochets pour mes contrôleurs ou des routes où j'oublie simplement d'appeler this._super (... arguments) et, pour autant que je sache , tout fonctionne de la même manière.

Dois-je toujours inclure une méthode super () avant d'écraser une fonction membre dans Ember?


2 commentaires

Je suis peut-être le plus étrange, car j'utilise seulement super dans le constructeur et init. github.com/NullVoxPopuli/emberclear/… (cette recherche inclut un didInsertElement, mais j'étends une classe de composant non de premier niveau


Je fais presque toujours. Dans un long fil perdu, quelqu'un m'a dit une fois que le comportement de la méthode surchargée n'était pas nécessairement garanti par semver, donc je devrais toujours appeler super pour éviter l'étrangeté à l'avenir si quelque chose était ajouté à une méthode en amont qui ne fait actuellement rien.


3 Réponses :


1
votes

Oui. Dans un fil de discussion perdu depuis longtemps, quelqu'un m'a dit une fois que le comportement de la méthode surchargée n'était pas nécessairement garanti par semver, donc je devrais toujours appeler super pour éviter l'étrangeté à l'avenir si quelque chose était ajouté à une méthode en amont qui ne fait actuellement rien.


0 commentaires

1
votes

Oui, vous devriez toujours le faire. Si vous ne le faites pas, ember n'exécutera pas le code qui gère les choses en coulisse, ce qui entraînera un comportement étrange que vous ne pourrez peut-être pas déboguer.

P.S: À titre expérimental, essayez simplement de remplacer une méthode setupController dans n'importe quelle route de votre application sans appeler this._super (... arguments) et voyez ce qui se passe.


6 commentaires

"En tant qu'expérience, essayez simplement de remplacer une méthode setupController dans n'importe quelle route" - J'ai beaucoup fait ça. Rien de vraiment grave ne se passe, contrairement à init .


@Gennady Dogaev Quelle version de braise utilisez-vous?


Tout, la version n'a pas d'importance. Tout ce que setupController fait par défaut est de définir le model sur le contrôleur. Vous pouvez le faire sans this._super ou utiliser une autre propriété au lieu de model


Veuillez vérifier le twiddle de braises suivant. J'ai remplacé setupController et je n'ai pas utilisé this._super () à cause de laquelle "Tout setupController fait par défaut est la configuration du modèle sur le contrôleur." ne se produit pas et rien ne s'affiche à l'écran. ember-twiddle.com/…


Bien sûr, rien ne s'affiche car vous essayez d'utiliser le modèle et n'avez pas ajouté de code qui le définit. Vérifiez ceci - tout fonctionne et il n'y a rien de tel. _super'


Exactement ce que j'essayais de faire valoir. Vous avez dû le définir explicitement car vous avez surchargé la méthode et n'avez pas utilisé 'this._super'. ce que vous avez fait peut être fait en appelant simplement «this._super». C'est le but du setupController tel que prévu par les créateurs d'Ember et c'est ce que l'OP demandait.



2
votes

Oui, vous feriez mieux d'inclure this._super , même si ce n'est pas "un must" dans la plupart des cas.

Je ne connais qu'un seul endroit où cela est critique - init . Très probablement constructeur aussi, comme mentionné ci-dessus, mais je n'ai jamais eu besoin d'écraser un constructeur. Cependant, considérez ceci:

  1. Comme beaucoup de gens l'ont mentionné, quelque chose pourrait être changé dans les versions futures et inclure this._super peut aider à éviter les bogues
  2. Si vous utilisez mixin à partir d'un addon ember, ils pourraient également écraser les méthodes ember ou le faire dans les versions futures
  3. Disons que vous étendez le composant de votre propre mixin et que pour l'instant votre mixin n'écrase pas didRender . Mais que se passe-t-il si vous devez changer cela à l'avenir?

Donc, si dans la plupart des cas, inclure this._super n'est pas critique, il est bon de l'inclure quand même. Sauf dans les cas où vous aviez l'intention d'écraser complètement le comportement par défaut.


0 commentaires