New components that implement an abstract component, vs variants on a single component.

Question

I have created some stateless functional components that represent round social media icons used for links/sharing, the code looks like this:

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;

And then later, I'm going to use it like:

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

etc

Now it strikes me that I could do this a different way - something like:

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}
    />
  );
};

And use it like:

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

The question is - is there any reason one is better than the other? In terms of bundling size - is the second way necessarily a larger bundle size than the first? (ie. what if I was creating a library of potentially 20 social media icons - but the user might only use three of them).

Certainly I think the first version is tidier.

What principles should I be paying attention to when making this kind of design decision?

score 6 · Answer 1 · answered Oct 01 '18 at 00:55

In the clean code book, there is a passage that goes something like:

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.

I think the biggest difference between the 2 approaches is the first 1st gives you the ability to have instance methods which behaves differently depending on the “class”(Prototype)

and the 2nd one allows you to add more icons easier.

If all your icon classes behaves the same, the 2nd approach might be favorable. If each icon class implements some logic specific to it, the 1st approach might be better.

In the 1st pattern:

Cons:

Adding a new icon requires you to create a new file (maybe) and a export a new component type.

Pros:

Adding logic specific to this component is easier. In your example, components don’t have logic but imagine a Shape base class then Circle Square Triangle classes which extend and overwrite a draw method.

In the the 2nd pattern:

Pros:

Adding a new icon is just a question of adding 1 more entry to your dictionary(object).

Cons:

Adding logic specific to a component type will require a switch statement. Imagine a draw method which switches on the type then draws differently for circles, triangles, etc.

I don’t know about effects on bundle sizes. Sorry.

New components that implement an abstract component, vs variants on a single component.

1 Answers1