Remplacement recommandé pour modifyClass("model:composer") lors de la surcharge de save()

Dev
1

Je migre vers une alternative à api.modifyClass("model:composer", ...), qui est obsolète.

Ma surcharge actuelle de Composer#save modifie conditionnellement le comportement de l’enregistrement, mais doit sinon appeler super.save(opts).

Je vois les nouvelles API addModelMethod / addModelCallback, mais je ne trouve aucun exemple dans le code source montrant comment utiliser addModelMethod pour surcharger une méthode existante tout en conservant l’accès à l’implémentation originale.

addModelMethod est-il destiné à surcharger des méthodes de modèle existantes de cette manière ? Si oui, comment un plugin doit-il déléguer à l’implémentation originale de save() ?

Ou existe-t-il un autre point d’extension à utiliser pour ce cas d’utilisation du Composer ?

2

Je suppose que cela dépend de ce que vous voulez faire en remplaçant la méthode save…

Si vous cherchez à empêcher une sauvegarde en fonction d’une certaine condition, vous pouvez utiliser notre transformateur de valeur composer-service-cannot-submit-post.

Si vous voulez effectuer une action une fois le message créé, il y a api.onAppEvent("post:created").

Si vous ajoutez un champ, il y a api.serializeOnCreate.

Aucune de ces options ne correspond-elle à ce que vous recherchez ?

3

Merci ! J’utilise déjà composer-service-cannot-submit-post — il gère la vérification au niveau du service. Mais la méthode save() du modèle du composeur vérifie également cantSubmitPost, qui inclut missingReplyCharacters > 0, donc un corps vide est toujours bloqué à ce niveau.

onAppEvent("post:created") est trop tard car le message n’est jamais créé, et serializeOnCreate n’ajoute que des champs à la requête, donc cela n’aide pas pour la validation de la longueur du corps.

Le problème restant est donc de contourner missingReplyCharacters / cantSubmitPost pour le premier message. Existe-t-il un point d’extension officiellement pris en charge pour cela ?

Voici l’initialiseur actuel pour référence :

4

@david, je te serais reconnaissant pour tout avis que tu pourrais me donner sur la meilleure approche à adopter ici.

5

La meilleure solution serait d’ajouter un nouveau hook au cœur de Discourse, ce qui vous permettrait d’obtenir ce dont vous avez besoin de manière prise en charge. Qu’en pensez-vous de quelque chose comme ceci :

Ainsi, votre plugin ferait :

api.registerValueTransformer(
  "composer-minimum-post-length",
  ({ value, context: { composer } }) => {
    if (
      composer.siteSettings.discourse_optional_topic_body_enabled &&
      composer.topicFirstPost
    ) {
      return 0;
    }

    return value; // Keep core logic
  }
);

Dites-moi si cela fonctionne pour votre cas d’usage et je sortirai la PR du brouillon pour qu’elle puisse être examinée/fusionnée.

6

Merci David ! J’ai testé le transformateur composer-minimum-post-length et il fonctionne — les sujets avec des corps vides sont créés avec succès.

Une chose que j’ai remarquée : l’éditeur affiche toujours « Post can’t be empty » car la validation dans composer-editor contient une vérification en dur replyLength < 1 qui n’utilise pas minimumPostLength.

Cette vérification pourrait-elle également respecter le transformateur, ou être ignorée lorsque minimumPostLength est 0 ?

7

Bonne idée - ajouté à la PR :+1:

9

Ça marche parfaitement maintenant. Merci beaucoup d’avoir ajouté ça, @david ! :raising_hands: