Melhorias na legibilidade do WP_Query (para manutenção)

Trabalhar com WP_Query, especialmente quando você está fazendo algum trabalho personalizado fora do usual "obter alguns posts e exibi-los em um modelo" pode ser poderoso. Isso é especialmente verdadeiro para alguns dos argumentos avançados (como usar WP_Meta_Query, por exemplo) .

Também é legal que a configuração do processo tenha uma maneira padrão de fazer as coisas. Nomeadamente:

1. Defina os argumentos,
2. Instanciar WP_Query,
3. Verifique se há postagens,
4. Passe por eles,
5. Acabe com eles.

Mas se você chegar onde está fazendo qualquer trabalho avançado, como trabalhar com um tipo de postagem personalizado de uma solução de terceiros, ter que carregar mídia lateralmente, determinar se algo existe antes de realmente fazer qualquer trabalho com ele, então pode ser um um pouco mais complicado de trabalhar, não é?

Descobri que, como com qualquer coisa na programação, dividi-lo em módulos muito mais legíveis (ou funções ou partes ou como você quiser chamá-los) pode facilitar muito o trabalho.

Então, aqui está uma maneira de trabalhar para melhorar a legibilidade do WP_Query em uma variedade de coisas que fiz recentemente.

Melhorias na legibilidade do WP_Query

Antes de passar por qualquer exemplo, vale ressaltar que existem algumas coisas que a forma como o WP_Query está configurado que não podemos fazer.

Por exemplo, uma vez que a consulta é instanciada, talvez não possamos fazer coisas muito mais avançadas com ela (quer dizer, configurar qualquer teste de unidade que não exija o núcleo do WordPress será impossível).

Essa é a cara de quem não consegue seguir seu código.

Com isso dito, aqui está um exemplo de como ele pode parecer quando você começa e, em seguida, como ele pode ser refatorado para ter funções menores, cada uma das quais é mais intencional do que um método longo.

Um exemplo

Para este post, digamos que eu precise consultar o banco de dados para todos os posts e posts publicados e quero ordená-los pelo ID.

Em seguida, quero determinar se alguma ferramenta de terceiros atribuiu alguns metadados a ela que correspondam a um modelo que eu possa atribuir programaticamente posteriormente, dado um tema que tenho.

Talvez a versão inicial do código possa ser algo assim :

Isso é muito código para fazer um pouco de trabalho para uma função. No mínimo, ele estabelece tudo o que precisa acontecer, não é?

Antes de continuar lendo, observe que o array de mapeamento é apenas um exemplo, mas as chaves representam a meta-chave para  mapeá -lo, e isso nos ajuda a mapear a definição do  valor _wp_page_template quando chegar a hora de mapeá-lo para os arquivos de modelo reais do WordPress.

Então, como isso pode ser dividido?

1 Chute a coisa toda fora

A primeira coisa que queremos fazer é criar uma função que coloque tudo em movimento. Existem algumas maneiras que você pode escolher para fazer isso.

Aqui está como eu optei por fazê-lo :

Simplificando, ele usará algumas funções auxiliares – todas as quais documentarei abaixo – e, em seguida, atribuirá os modelos que tivermos no array de mapeamento definido acima.

2 Carregar Posts e Páginas

Naturalmente, a primeira coisa que queremos fazer é configurar uma função para chamar que retornará usar os resultados da consulta:

Isso retorna os resultados da consulta. Dessa forma, podemos determinar se precisamos fazer algum trabalho adicional que dizemos na essência na etapa anterior:

Se não, então terminamos. Caso contrário, obviamente, continuamos.

3 Recupere o ID do modelo de terceiros

Em seguida, a ideia de atribuir modelos – como mostrado no código acima – parece bastante simples, mas há algumas coisas que precisamos fazer primeiro:

1. iterar pelas postagens,
2. pegue o ID de terceiros do modelo,
3. pegue o nome do modelo de terceiros,
4. atribua o modelo da constante de mapeamento definida anteriormente na classe.

A iteração inicial da função pode ser assim :

Mas como você pode ver, ainda existem funções auxiliares que precisam de definições. Coisas como a capacidade de obter o ID do modelo, o nome do modelo e, finalmente, atribuir o modelo.

Observe, no entanto, que se alguma das funções auxiliares não retornar um valor útil, continuamos com o loop. Isso é necessário se não por outro motivo além de ter certeza de que não estamos tentando mapear modelos que não existem (mas acho que também facilita um pouco a leitura).

4 Encontre o arquivo para o qual o ID do modelo mapeia

Em seguida, uma pequena função pode ser usada para examinar o ID do modelo de terceiros e determinar se podemos mapear esse valor para as páginas que existem em nosso banco de dados.

Se não puder, podemos retornar uma string vazia e fazer com que a função que invocou essa verificação específica para ver se vale a pena continuar com o loop que definimos.

5 Pegue o nome do modelo

Supondo que tenhamos um ID de postagem válido, agora precisamos recuperar o nome do modelo do array de mapeamento definido anteriormente no post:

Aqui está a coisa: ou vamos retornar o nome do modelo, ou vamos retornar um valor nulo. Novamente, isso é para que possamos determinar se precisamos continuar com o loop de atribuição de modelos ou não.

6 Atribuir o Modelo

Por fim, podemos pegar o ID do modelo fornecido pelo terceiro e usá-lo para mapear para o arquivo que incluímos em nosso trabalho, conforme descrito anteriormente na postagem:

E é assim que você pode criar códigos e funções muito menores, mais fáceis de ler e usar ao trabalhar com consultas um pouco mais complicadas.

E assim, melhorias de legibilidade

Para aqueles acostumados a escrever métodos longos de leitura ou fazer coisas da maneira que muitos tutoriais na web mostram como fazer as coisas no WordPress, isso pode parecer um monte de código inútil.

Mas considere isso:

1. Métodos mais longos são mais difíceis de ler,
2. Eles podem ser mais difíceis de depurar,
3. E eles não dividem o problema em partes mais gerenciáveis.

Claro, eu adoraria dividir isso em ainda mais classes com suas responsabilidades, e acredito que isso possa ser feito, mas dada a natureza do WP_Query, isso exigiria um pouco mais de trabalho.

Por isso, tentei atingir o máximo de meio-termo possível.

Se você estiver trabalhando com usos ainda um pouco mais avançados de WP_Query, recomendo pelo menos considerar dividi-lo em partes menores.

Isso ajuda a cuidar da legibilidade, potencialmente qualquer manutenção, e escrever um código mais limpo em vez de um método longo com muitas condicionais e dependência de uma variedade de outros dados.