1
resposta

[Sugestão] Refatoração do isAuthenticated

Olá, percebi que para cada CarPost, precisamos ficar chamando a função do auth.....

o componente card post final, ficaria mais limpo, se fizessemos a chamada da função no Feed e passar para o CardPost como prop!
..... Creio que assim ficaria melhor..

codigo final:

import styles from "./cardpost.module.css";
import { Author } from "../Author";
import { ThumbsUpButton } from "./ThumbsUpButton";
import { ModalComment } from "../ModalComment";
import { Link } from "react-router";
import { usePostInteractions } from "../../hooks/usePostInteractions";

export const CardPost = ({ post, isAuthenticated }) => {
  const { likes, comments, handleLikeButton, handleNewComment } =
    usePostInteractions(post);

  return (
    <article className={styles.card}>
      <header className={styles.header}>
        <figure className={styles.figure}>
          <img src={post.cover} alt={`Capa do post de titulo: ${post.title}`} />
        </figure>
      </header>
      <section className={styles.body}>
        <h2>{post.title}</h2>
        <p>{post.body}</p>
        <Link to={`/blog-post/${post.slug}`}>Ver detalhes</Link>
      </section>
      <footer className={styles.footer}>
        <div className={styles.actions}>
          <div className={styles.action}>
            <ThumbsUpButton
              loading={false}
              onClick={handleLikeButton}
              disabled={!isAuthenticated}
            />
            <p>{likes}</p>
          </div>
          <div className={styles.action}>
            <ModalComment onSuccess={handleNewComment} postId={post.id} />
            <p>{comments.length}</p>
          </div>
        </div>
        <Author author={post.author} />
      </footer>
    </article>
  );
};
1 resposta

que bom que você levantou esse ponto. esse tipo de pergunta — "será que tem um jeito melhor?" — é o que separa quem copia código de quem pensa sobre código. e o usePostInteractions que você extraiu, juntando likes e comments num custom hook, é uma melhoria genuína — guarda esse reflexo.

agora, sobre o useAuth: quando você falou "ficaria mais limpo", eu parei e perguntei — limpo em qual sentido? (parece chata, essa pergunta, mas ela é o jogo todo.)

"limpo" é uma palavra traiçoeira. parece neutra mas esconde uma escolha de valor. menos linhas? menos imports? menos responsabilidade? cada leitura disso te leva pra um caminho diferente, e cada caminho cobra um preço diferente. então em vez de discutir qual versão é "melhor", eu prefiro olhar o que cada uma otimiza e o que cada uma paga em troca.

o que eu quis fazer no curso

a versão com o useAuth dentro do CardPost otimiza pra autonomia. o componente sabe o que precisa e busca sozinho.

isso me dá:

  • usar o CardPost em qualquer lugar do app sem ninguém precisar lembrar de passar isAuthenticated (ou ser forçado a chamar o useAuth só pra passar essa prop).
  • se a regra de auth mudar (booleano vira sistema de roles), eu ajusto dentro do useAuth e ninguém mais precisa saber.
  • inversão de dependência de verdade — o componente depende da abstração, não de quem renderiza ele.

custos:

  • fica acoplado ao contexto de auth. pra usar em landing pública, storybook ou teste isolado, vou ter que mockar.
  • todo CardPost chama o hook

o que a sua versão otimiza

a sua versão (recebendo isAuthenticated como prop) otimiza pra pureza. o componente vira "burro" — só renderiza o que recebe.
isso te dá:

  • dependência explícita na assinatura. olhou as props, sabe tudo que ele precisa.
  • testar isolado vira trivial. nem precisa mockar hook.
  • funciona em qualquer contexto, com ou sem auth.

custos:

  • prop drilling em potencial. se o CardPost estiver dentro de uma lista dentro de uma página dentro de um layout, alguém em algum nível tem que buscar e empurrar pra baixo.
  • todo lugar que renderiza precisa saber que ele depende de auth — a responsabilidade vaza pra cima na árvore.

quando uma vence a outra?

depende do papel do componente no sistema. as perguntas que eu faço:

  • usado em poucos ou muitos lugares?
  • vai existir em contextos sem auth?
  • vai pra design system?
  • como vai ser testado?

no curso, eu fui na do hook dentro porque queria ilustrar inversão de dependência sem distrações — era a escolha que servia o objetivo pedagógico daquela aula. num projeto real, eu tomaria essa decisão depois de responder essas perguntas.


se até hoje você sempre escolheu de um jeito só sem fazer essa pergunta, tá tudo bem — primeiro a gente aprende um jeito, depois aprende que existem outros, depois aprende a escolher. ninguém pula essas etapas.

o que eu quero é que, na próxima vez que alguém chamar alguma coisa de "mais limpa", você pare e pergunte: limpa pra quê? pra quem? em troca do quê? essa pergunta demora pra virar automática, mas quando vira reflexo, suas decisões de arquitetura sobem de nível.

continua trazendo suas decisões pro fórum, é sempre legal conversar sobre engenharia :)