Ajude-me a entender: o processo pós-cozimento

spirobel · Maio 29, 2020, 9:51am

Olá,
Ficaria muito feliz se alguém pudesse me ajudar a entender como funciona o processo de pós-cozimento (post cooking). Estou especialmente interessado nesta parte:

github.com/discourse/discourse

lib/cooked_post_processor.rb

956d15d13

# frozen_string_literal: true

# Post processing that we can do after a post has already been cooked.
# For example, inserting the onebox content, or image sizes/thumbnails.

class CookedPostProcessor
  LIGHTBOX_WRAPPER_CSS_CLASS = "lightbox-wrapper"
  LOADING_SIZE = 10
  LOADING_COLORS = 32

  attr_reader :cooking_options, :doc

  def initialize(post, opts = {})
    @dirty = false
    @opts = opts
    @post = post
    @previous_cooked = (@post.cooked || "").dup
    # NOTE: we re-cook the post here in order to prevent timing issues with edits
    # cf. https://meta.discourse.org/t/edit-of-rebaked-post-doesnt-show-in-html-only-in-raw/33815/6
    @cooking_options = post.cooking_options || opts[:cooking_options] || {}

This file has been truncated. show original

Por que o processamento ocorre depois que a postagem já foi “cozida”?
Talvez possamos analisar o processo do que seria necessário para adicionar um recurso como oneboxes ou “citações de usuários específicos”, caso ainda não existissem. Então, deparei-me com o Prettytext discourse/app/assets/javascripts/pretty-text at f9608c0af5f7b1109117a5aba979acb00c28cf9a · discourse/discourse · GitHub
que lida com a conversão de e para Markdown e com a renderização da caixa de pré-visualização. Também encontrei a função rebake no modelo de postagem (post model) no backend:

github.com/discourse/discourse

app/models/post.rb

d9a02d133


      
                else
                  post.custom_fields["rebake_attempts"] = attempts + 1
                  post.save_custom_fields
                end
          
              end
            end
            problems
          end
          
          def rebake!(invalidate_broken_images: false, invalidate_oneboxes: false, priority: nil)
            new_cooked = cook(raw, topic_id: topic_id, invalidate_oneboxes: invalidate_oneboxes)
            old_cooked = cooked
          
            update_columns(
              cooked: new_cooked,
              baked_at: Time.zone.now,
              baked_version: BAKED_VERSION
            )
          
            if is_first_post?

que chama o método cook do postanalyzer:

github.com/discourse/discourse

app/models/post_analyzer.rb

9bff0882c


      
          end
          
          def has_oneboxes?
            return false unless @raw.present?
          
            cooked_stripped
            found_oneboxes?
          end
          
          # What we use to cook posts
          def cook(raw, opts = {})
            cook_method = opts[:cook_method]
            return raw if cook_method == Post.cook_methods[:raw_html]
          
            if cook_method == Post.cook_methods[:email]
              cooked = EmailCook.new(raw).cook(opts)
            else
              cooked = PrettyText.cook(raw, opts)
            end
          
            result = Oneboxer.apply(cooked) do |url|

essa função executa a conversão Markdown via JavaScript no backend

github.com/discourse/discourse

lib/pretty_text.rb

9bff0882c


      
            @ctx
          end
          
          def self.reset_context
            @ctx_init.synchronize do
              @ctx&.dispose
              @ctx = nil
            end
          end
          
          def self.markdown(text, opts = {})
            # we use the exact same markdown converter as the client
            # TODO: use the same extensions on both client and server (in particular the template for mentions)
            baked = nil
            text = text || ""
          
            protect do
              context = v8
          
              custom_emoji = {}
              Emoji.custom.map { |e| custom_emoji[e.name] = e.url }

Minha hipótese era que isso fosse feito dessa forma para reduzir a duplicação de código, mas então descobri o

CookedPostProcessor

que linkei no início. Parece que algum processamento é feito apenas em JavaScript, enquanto parte dele é feita tanto em JavaScript quanto em Ruby no CookedPostProcessor. Para resumir: 1. É necessário ter regras de conversão de e para Markdown (parece estar apenas em JavaScript). 2. É necessário ter algum código para criar o HTML (parte em JavaScript, mas também parte em Ruby). Gostaria de saber por que o item (2) é feito parcialmente em JavaScript e parcialmente em Ruby. Talvez você possa me dar um exemplo. Também ficaria muito feliz se você pudesse corrigir quaisquer suposições equivocadas que eu tenha feito neste post.
Muito obrigado!
Spirobel

fzngagan · Julho 2, 2020, 4:26pm

Para começar, basta verificar a aba de rede do console do JavaScript para saber o que é capturado no front-end e enviado ao servidor quando um post é criado. Isso significa que todos os dados enviados à API do Rails são processados posteriormente pelo Rails. Em seguida, na tabela posts, você verá as colunas raw e cooked, que indicam as formas não processada e processada do post.

spirobel · Julho 3, 2020, 3:18pm

Ok, obrigado pela sua resposta. Acredito que vou explorar isso aos poucos. Acho que talvez essa abordagem de “raciocinar a partir de princípios fundamentais” que eu adotei não funcione, pois isso surgiu por razões históricas.

Tópico		Respostas	Visualizações
Post Cooking Process with Landing Pages Development	0	369	5 de Novembro de 2021
Importing posts with Markdown Migration	11	975	19 de Outubro de 2023
Edit of rebaked post doesn't show in HTML; only in raw Bug	8	1855	29 de Setembro de 2015
How to decorate a post before it's cooked? Development	4	979	5 de Março de 2021
Working with different needs in raw/cooked content Development	7	5263	15 de Maio de 2025

Ajude-me a entender: o processo pós-cozimento

Tópicos relacionados