Sostituzione dei metodi include_* nei serializers

Ciao @david,

Una rapida domanda sul ragionamento dietro questa deprecazione

Avviso di deprecazione: add_to_serializer non deve essere utilizzato per sovrascrivere direttamente i metodi include_*?

Contesto: DEV: Improve add_to_serializer include_* options (#21220) · discourse/discourse@26b7f8a · GitHub

Comprendo il desiderio di spostare gli utenti sull’argomento include_condition in un uso standard del metodo add_to_serializer, ovvero per aggiungere i propri metodi ai serializer.

Tuttavia, ci sono alcuni casi in cui un plugin potrebbe voler aggiungere un metodo include_* a un serializer che non corrispondono a quel caso, ovvero quando non si determina se il proprio attributo personalizzato è incluso, ma si sta sovrascrivendo un metodo include_* in un serializer principale, ad esempio

Metodo principale: discourse/app/serializers/site_serializer.rb at main · discourse/discourse · GitHub

Apprezzo che quell’uso particolare possa essere ripensato per non richiedere una sovrascrittura del metodo del serializer del sito, o che la sovrascrittura possa essere ottenuta in altri modi, ma mi chiedo se ci sia uno svantaggio intrinseco nel consentire tale uso del metodo add_to_serializer in questo modo, e se la deprecazione porterà alla rimozione dell’uso del metodo in questo modo.

4 Mi Piace

Sì, questa sarebbe la mia raccomandazione.

Abbiamo recentemente introdotto un nuovo sistema per ‘plugin modifiers’, che sono punti di estensione super economici simili a DiscourseEvent ma prendono un valore di input e restituiscono un valore. Quindi, nel tuo caso, potresti fare una PR core per aggiungere una chiamata DiscoursePluginRegistry.apply_modifier nel metodo include_ pertinente, e quindi puoi usare register_modifier nel tuo plugin per sovrascrivere il valore.

È probabile che alla fine lo bloccheremo completamente, sì. Inoltre, non vorrai davvero usare un metodo che stampa rumore di deprecazione nei log.

Se proprio devi sovrascrivere un metodo senza la cooperazione del core, allora modify_class sembrerebbe la scelta migliore. Il motivo principale per cui abbiamo un add_to_serializer dedicato è perché definisce automaticamente un metodo include_* in modo che si applichi solo quando il plugin è abilitato.

Ciò significa che lo snippet di codice che hai collegato sta attualmente definendo due metodi. include_wizard_required? e include_include_wizard_required? :sweat_smile:

11 Mi Piace

Quel Readme dice che “opera come uno stack (first in, first out)”, ma quella è una coda. Uno stack è first in, last out. (Non riesco a capire nemmeno come copiare il testo sul mio telefono).

4 Mi Piace

buona osservazione. sì, lo stack è LIFO e la coda è FIFO

Caratteristiche principali di questi modificatori:

  • Operano in uno stack (primo registrato, primo chiamato)
  • Disabilitati automaticamente quando il plugin è disabilitato
  • Passano il risultato cumulativo di tutte le invocazioni di blocco al chiamante
1 Mi Piace

È più simile a uno ‘stack middleware’: una serie di metodi che vengono eseguiti in ordine, ognuno dei quali passa il proprio risultato all’input del metodo successivo.

Non credo che cercare di applicare la terminologia LIFO/FIFO qui funzionerà: nulla viene aggiunto/rimosso dallo ‘stack’ - non c’è un ‘fuori’.

4 Mi Piace

Oh. Quindi non una struttura dati stack.

Ho iniziato a dire qualcosa su come ho preso la mia laurea in informatica nel 1987 e non sapevo cosa imparassero le persone ora. :joy:

2 Mi Piace

Questo è in un certo senso il mio problema. Ho un intervallo recente di quasi 10 anni in cui sono stato quasi lontano da un computer (dopo oltre 25 anni di lavoro con essi) e sembra una sezione mancante di base di conoscenza.

3 Mi Piace

Questo argomento è stato chiuso automaticamente 30 giorni dopo l’ultima risposta. Non sono più consentite nuove risposte.