Nuovi componenti che implementano un componente astratto, vs varianti su un singolo componente.

2

Ho creato alcuni componenti funzionali stateless che rappresentano icone rotonde di social media utilizzate per collegamenti / condivisione, il codice è simile al seguente:

AbstractRound

import React from 'react';
import { withStyles } from '@material-ui/core/styles';

const AbstractRound = ({
  imgSrc,
  classes,
  alt,
}) => {
  return (
    <img
      className={classes.root}
      src={imgSrc}
      alt={alt}
    />
  );
};

const styles = {
  root: {
        //Some specific styling here relating to size, borderRadius, etc
  },
};

export default withStyles(styles)(
  AbstractRound
);

FacebookRound

import React from 'react';
import AbstractRound from './AbstractRound';
import img from './facebook.svg';
const FacebookRound = () => {
  return (
    <AbstractRound
      imgSrc={img}
      alt="Find us on Facebook"
    />
  );
};

export default FacebookRound;

E più tardi, lo userò come:

<FacebookRound/> 
<GoogleRound/> 
<TwitterRound/> 

etc

Ora mi sembra di poterlo fare in un modo diverso - qualcosa come:

import facebookImage from './facebook.svg';
import googleImage from './google.svg';

const SocialMediaRound = ({
  classes, 
  variant, 
}) => {

  const variants = {
    facebook: {
      alt: "Find us on Facebook", 
      img: facebookImage
    }, 

    google: {
      alt: "Find us on Google Plus", 
      img: googleImage
    }
  }

  const {img, alt} = variants[variant]

  return (
    <img
      className={classes.root}
      src={img}
      alt={alt}
    />
  );
};

E usalo come:

<SocialMediaRound variant = "facebook"/> 
<SocialMediaRound varaint = "google"/> 

La domanda è: c'è qualche ragione per cui uno è migliore dell'altro? In termini di dimensioni di raggruppamento - la seconda è necessariamente una dimensione di fascio maggiore rispetto alla prima? (cioè, cosa succede se stavo creando una libreria di potenzialmente 20 icone di social media - ma l'utente potrebbe utilizzare solo tre di esse).

Sicuramente penso che la prima versione sia più ordinata.

A quali principi dovrei prestare attenzione quando faccio questo tipo di decisione sul design?

    
posta dwjohnston 27.09.2018 - 03:22
fonte

1 risposta

6

Nel libro di codice pulito, c'è un passaggio che va qualcosa come:

Data structures makes it easy to add new functions without changing the existing data structures. OO code(using objects), makes it easy to add new classes without changing existing functions.

Penso che la più grande differenza tra i 2 approcci è la prima che ti dà la possibilità di avere metodi di istanza che si comportano diversamente a seconda della "classe" (Prototipo)

e il 2 ° consente di aggiungere più icone più facilmente.

Se tutte le classi di icone si comportano allo stesso modo, il secondo approccio potrebbe essere favorevole. Se ogni classe di icone implementa una logica specifica, il primo approccio potrebbe essere migliore.

Nel primo modello:

Contro:

  • L'aggiunta di una nuova icona richiede di creare un nuovo file (forse) e di esportare un nuovo tipo di componente.

Pro:

  • L'aggiunta di logica specifica a questo componente è più semplice. Nel tuo esempio, i componenti non hanno logica ma immaginano una classe base Shape quindi classi Circle Square Triangle che estendono e sovrascrivono un metodo draw .

Nel secondo schema:

Pro:

  • L'aggiunta di una nuova icona è solo una questione di aggiungere un'altra voce al tuo dizionario (oggetto).

Contro:

  • L'aggiunta di una logica specifica a un tipo di componente richiede un'istruzione switch. Immagina un metodo draw che attiva type , quindi disegna in modo diverso cerchi, triangoli, ecc.

Non so sugli effetti sulle dimensioni del fascio. Siamo spiacenti.

    
risposta data 01.10.2018 - 02:55
fonte

Leggi altre domande sui tag