O Poder do SOLID: Desmistificando e construindo componentes com React e Typescript

// Exemplo Ruim ❌
// Este componente possui duas responsabilidades: exibir o perfil E um formulário de edição.
<>
    <UserProfileDisplayAndForm />
</>

// Bom exemplo ✅
// Cada componente agora tem uma única responsabilidade.
<>
  {/* UserProfileDisplay - Responsável apenas por exibir o perfil do usuário */}
  <UserProfileDisplay />
  {/* UserForm - Responsável apenas pelo formulário de edição do usuário */}
  <UserForm />
</>

// Exemplo Ruim ❌
export const Button({ type, children }) {
    if (type === "primary") { /* renderiza com estilo primary */ }
    else if (type === "secondary") { /* renderiza com estilo secondary */ }
    // Se precisarmos adicionar um novo tipo de botão (ex: "danger"), teríamos que modificar este componente
    // e adicionar outro 'else if', aumentando a complexidade.
    // ... retorna um estilo genérico
}

// Bom exemplo ✅
// O componente Button está aberto para extensão (novos tipos de estilo)
// e fechado para modificação (não precisamos alterar sua estrutura interna para novos tipos).
export const Button({ type, children }: { type: string, children: ReactNode | string }) {
    return <button className={`bg-${type}-500 text-white`}>{children}</button>
}

// Ou você pode utilizar também styled-components para estender o estilo
// Para um novo tipo, você cria um novo componente estilizado, sem alterar o Button base.
// Exemplo com styled-components:
const PrimaryButton = styled(Button)`
    background-color: blue;
`;
const SecondaryButton = styled(Button)`
  background-color: green;
`;

// Exemplo Ruim ❌

// Componente base ListItem que (erroneamente) assume a existência de 'price'
function ListItem({ item }) {
    // Este componente espera que 'item' SEMPRE tenha uma propriedade 'price'.
    // Se um item sem 'price' for passado, o componente pode quebrar ou exibir 'undefined'.
    return <div>{item.name} - {item.price}</div>; // Bug se item.price não existe
}

// Subtipo ArticleListItem, que não possui a propriedade 'price' esperada por ListItem
function ArticleListItem({ item }) {
    // ArticleListItem está usando ListItem, mas seus itens não possuem 'price'.
    // Isso viola o LSP porque ArticleListItem não pode substituir ListItem sem causar um erro.
    return <ListItem item={item} />; // Item de artigo não tem preço, vai quebrar!
}

// Subtipo ProductListItem, que possui a propriedade 'price'
function ProductListItem({ item }) {
    // Embora ProductListItem funcione com ListItem, a dependência implícita de 'price'
    // no ListItem base limita a substituibilidade.
    return <ListItem item={item} />; // Este funcionaria, mas o base é problemático.
}

// Uso (problema aqui!)
<ArticleListItem item={myArticle} /> // Isso causaria um erro de runtime

// Bom exemplo ✅

// Interface base que define o contrato mínimo para qualquer item de lista.
// Todos os subtipos devem, no mínimo, ter 'title' e 'author'.
interface ListItemBaseProps {
    title: string;
    author: string;
    // Opcionalmente, pode-se adicionar uma propriedade para o tipo específico do item,
    // ou usar um discriminante para unir diferentes tipos.
}

// Componente base ListItem que renderiza informações genéricas.
function ListItem({ item }: { item: ListItemBaseProps }) {
    return (
        <div>
            <h1>{item.title}</h1>
            <p>Por {item.author}</p>
        </div>
    );
}

// Interface para um item de artigo, estendendo a base e adicionando propriedades específicas.
interface ArticleItemProps extends ListItemBaseProps {
    id: string;
    summary: string;
    // NENHUMA propriedade que não seja da base é obrigatória aqui,
    // garantindo que ArticleItem possa substituir ListItemBaseProps.
}

// Componente ArticleListItem, que mantém o contrato base e estende o comportamento
function ArticleListItem({ item }: { item: ArticleItemProps }) {
    return (
        <div>
            <h3>{item.title}</h3>
            <p>{item.summary}</p>
            <small>Por {item.author}</small>
        </div>
    );
}

// Interface para um item de produto, estendendo a base e adicionando propriedades específicas.
interface ProductItemProps extends ListItemBaseProps {
    id: string;
    price: number;
    currency: string;
    // NENHUMA propriedade que não seja da base é obrigatória aqui.
}

// Componente ProductListItem, que mantém o contrato base e estende o comportamento
function ProductListItem({ item }: { item: ProductItemProps }) {
    return (
        <div>
            <h2>{item.title}</h2>
            <p>Preço: {item.currency} {item.price.toFixed(2)}</p>
            <small>Por {item.author}</small>
        </div>
    );
}

// No uso real, você poderia ter uma lógica para escolher qual componente renderizar:
function SpecificList({ items }: { items: (ArticleItemProps | ProductItemProps)[] }) {
    return (
        <div>
            {items.map((item, index) => {
                if ('summary' in item) {
                    return <ArticleListItem key={index} item={item as ArticleItemProps} />;
                } else if ('price' in item) {
                    return <ProductListItem key={index} item={item as ProductItemProps} />;
                }
                return <ListItem key={index} item={item as ListItemBaseProps} />;
            })}
        </div>
    );
}

// Exemplo de como você usaria:
const articles = [
    { title: "SOLID em React", author: "Dev João", id: "1", summary: "Um guia completo..." },
    { title: "Performance com Hooks", author: "Dev Maria", id: "2", summary: "Otimizando seus componentes..." },
];

const products = [
    { title: "Monitor Gamer", author: "Tech XYZ", id: "P1", price: 1200, currency: "BRL" },
    { title: "Teclado Mecânico", author: "ABC Peripherals", id: "P2", price: 450, currency: "BRL" },
];

<MyList items={articles} /> // Funciona, mas renderizaria apenas o título e autor
<MyList items={products} /> // Funciona, mas renderizaria apenas o título e autor

// Usando a SpecificList para demonstrar a substituibilidade e especialização
<SpecificList items={[...articles, ...products]} /> // Agora ambos os tipos funcionam lado a lado

// Exemplo Ruim ❌
// Interface UserProps com muitas propriedades que nem sempre são necessárias para todos os componentes.
interface UserProps {
    id: string;
    name: string;
    email: string;
    address: string;
    phone: string;
    // ... e muito mais propriedades que este componente não usa
}

// O componente UserDetails depende de uma interface UserProps, mas utiliza apenas 'name' e 'email'.
// Isso força o componente a ter uma dependência maior do que o necessário.
export function UserDetails({ user }: { user: UserProps }) {
    return (
        <div>
            <p>Nome: {user.name}</p>
            <p>Email: {user.email}</p>
        </div>
    );
}

// Bom exemplo ✅
// Interface UserSummaryProps, segregada para conter apenas as propriedades essenciais
// para exibir um resumo do usuário.
interface UserSummaryProps {
    name: string;
    email: string;
}

export function UserDetails({ name, email }: UserSummaryProps) {
    return (
        <div>
            <p>Nome: {name}</p>
            <p>Email: {email}</p>
        </div>
    );
}

// O componente agora está mais limpo e com sua interface mais segregada.
// Ele depende apenas das informações que realmente utiliza.

// Exemplo Ruim ❌
// ProductList.tsx
import { ApiServiceImpl } from './apiService'; // Dependência concreta diretamente importada

function ProductList() {
    const [products, setProducts] = useState([]);
    useEffect(() => {
            // Se o método de busca de produtos mudar (ex: de REST para GraphQL),
        // este componente ProductList precisaria ser modificado.
        ApiServiceImpl.getProducts().then(setProducts);
    }, []);
    // ...
}

// Bom exemplo ✅
// apiService.ts (abstração - define o contrato do serviço)
interface ProductService {
    getProducts(): Promise<Product[]>;
}
// apiServiceImpl.ts (implementação concreta - detalhe de como os produtos são buscados, ex: REST ou GraphQL)
class ApiServiceImpl implements ProductService {
    async getProducts() { /* busca REST ou GraphQL */ return [] }
}

// mockServiceImpl.ts (implementação concreta para testes - detalhe de como os produtos são mockados)
class MockServiceImpl implements ProductService {
    async getProducts() { return [{ id: 1, name: 'Mock Product' }]; }
}

// ProductList.tsx (depende da abstração ProductService, não da implementação concreta)
function ProductList({ productService }: { productService: ProductService }) {
    const [products, setProducts] = useState([]);
    useEffect(() => {
        productService.getProducts().then(setProducts);
    }, [productService]);
    // ... restante do componente
}

// Onde você instancia vai ficar dessa maneira:
// O ProductList recebe a implementação concreta que precisa, invertendo a dependência.
<ProductList productService={new ApiServiceImpl()} />
// Ou para testes:
<ProductList productService={new MockServiceImpl()} />