[New] When should I create a new component ?

[Elfayer]

This question comes regularly to head for any web component interface.

We learned that a component should be self sufficient and reusable.

The problem is:

• The smaller the components, the more you get. (Your project gets flooded, harder to make components communicate)
• You build less components, the biggest they get. (Harder to maintain, less reusability)

It's always complicated to find the right balance.
I wonder if there are key points/ideas that can help bring better web component interfaces.

Imagine a page having the following specifications:

• Search field
• Filter toolbar
• Result list

Search field

I think the search field could be a component and assume that it is reusable.
Just so you get an idea of what I have in mind:

var searchField = {
  // One prop for the url to call on Field keypress.enter or search button clicked.
  props: {
    request: String
  },
  data() {
    return {
      // The input value
      searchValue: ''
    };
  },
  methods: {
    search() {
      // Request the server with `${this.request}?q=${this.searchValue}`
    }
  }
};

It could also be emitting a search event to inform the parent of any search trigger, instead of having a prop.

Filter toolbar

This component could allow sorting (date, specific data, ...) or even different layouts.
It will have to be strongly coupled to the Result list component. Since it filters the result list.

Should Filter toolbar and Result list components be as one?
Otherwise I'd be creating a component that only works properly with only one of my component library.

Result list

This is just a v-for of anything actually.
So basically it shouldn't require a component.

But note that the list could be paginated, infinite scrolled, etc.
So maybe there should be some kind of list component?
Something like:

var list = {
  props: {
    layout: String,
    validator(value) {
      return value === 'paging' || value === 'infinite' || value === 'scroll';
    },
    default: 'scroll'
  }
};

Conclusion

Note the above is just an example!
Feel free to compare the idea to any other situation.

I would like to hear about other's experience on separating components, building pages.

I hope we can find some best practices or key points on that matter.

[pablohpsilva]

Hello @Elfayer !! I'm super glad to see your help.
Once again I'm gonna thank you for your help: Thank you! :D

This topic is great, but it's also subjective though. Allow me to think a little bit more about it and I'll come back to you ASAP.

Please, if you may/like, invite some friends to help us out. The more people helping, the merrier.

---

Guys, if you can, please, give us your thoughts :D
@vilaboim @shailendher @aristidesfl @uonick @shershen08

[franciscolourenco]

I would say, create components only when you need. Wait until the code needs to be reused. Or it grows too big. Like you said, they are not for free.

[shershen08]

I would also propose to think of the whole application or product creation and development not as a finite activity but as a process.

In that sense upgrading versions of libraries, adding new features or refactoring your own code are that basically may never end (at least for years, which is an epoch in world of frontend).

From that prospective creating new components or refactoring the existing ones may be a subject of change along the way.

First you create a large component in some part of the application, later you brake it down to several reusable smaller ones. Those small components evolve and later may be generalized into,again some bigger block (page?) say if it's only used in one place.

[pablohpsilva]

Hello everyone!
@Elfayer sorry for taking so long to reply.
I strongly agree with all of you. There's no guarantee of knowing exactly when a new component should be created.

What do you think about the following:

---

Create components when needed

Why?

Vue.js is a component framework based. Not knowing when create components can lead to issues like:

• If the component is too big, it probably will be hard to (re)use and maintain;
• If the component is too small, your project gets flooded, harder to make components communicate;

How?

• Separate components candidates by its functionality;
• Candidates that looks the same and does the almost the same thing should be merged in one mutable component (e.g.: an <ul> and <ol> components);
• Complex components can be created. During the development of your application, if the complex component can be broken in more components, do it;
• Check old components to see if they could be separated in more components;
• Create component when there's a need for it. A component not well implemented nor designed should not be a component.
• In general, wait until the code grows to see if some can be reused. Once it can, design your component.

[franciscolourenco]

Assuming you are open for discussion on those points, here is my point of view regarding a few:

Candidates that looks the same and does the almost the same thing should be merged in one mutable component (e.g.: an <ul> and <ol> components);

Trying to merge what doesn't need to, can increase complexity of the resulting component.

Check old components to see if they could be separated in more components;

Can be a waste of time. If the component is working, why separate prematurely? Nothing is gained by it and complexity is increased.

[Elfayer]

Hi guys!

Sorry for not being very talkative lately on the subject.
I'm currently in holidays and will take time to look into your answers (which seems very interesting) later this week or next week when I'm back to my office.

[pablohpsilva]

@aristidesfl

Like this (?):

---

Create components when needed

Why?

Vue.js is a component framework based. Not knowing when create components can lead to issues like:

• If the component is too big, it probably will be hard to (re)use and maintain;
• If the component is too small, your project gets flooded, harder to make components communicate;

How?

• Separate components candidates by its functionality;
• Complex components can be created. During the development of your application, if the complex component can be broken in more components, do it;
• Create component when there's a need for it. A component not well implemented nor designed should not be a component.
• In general, wait until the code grows to see if some can be reused. Once it can, design your component.

[Elfayer]

I would say, create components only when you need. Wait until the code needs to be reused. Or it grows too big. Like you said, they are not for free.

@aristidesfl That's the basic/first approach anyone would have I guess. Not a bad one, it just have couple of problems:

• You lose time since you could have done it right the first time.
• You might refactor this component multiple times before getting it right.
• You might have to rethink every parents/children since the inputs/outputs have to be the same for this new component everywhere it is used. You now know the uses of this new component you want to build, but I'd think more of it as OUT of the project: what it should do, how it should work, how do you want it to be used.

---

I would also propose to think of the whole application or product creation and development not as a finite activity but as a process.

In that sense upgrading versions of libraries, adding new features or refactoring your own code are that basically may never end (at least for years, which is an epoch in world of frontend).

From that prospective creating new components or refactoring the existing ones may be a subject of change along the way.

@shershen08 I agree with that.

First you create a large component in some part of the application, later you brake it down to several reusable smaller ones. Those small components evolve and later may be generalized into,again some bigger block (page?) say if it's only used in one place.

@shershen08 I think it's the same problem here, the approach isn't wrong, but I believe it's just a bad idea from an architecture point of view. You might have to rethink a lot around the component you are creating.

---

@pablohpsilva I agree with the Why? part. I'm not a fan of the last two points of How?:

• Create component when there's a need for it. A component not well implemented nor designed should not be a component.

@pablohpsilva On this one you're right on the last part, but to me the first sentence is a worst case scenario.

• In general, wait until the code grows to see if some can be reused. Once it can, design your component.

@pablohpsilva Same here, waiting makes it harder and longer because you might have to review the parents & children and even the internal logic of all portion of code you want to replace by this component. Every time this new component occurs.

---

Maybe there are different ways to think about it...

How?

• Always remember to build your components for your project needs, but you should also try to think of them being able to work out of it. If they can work out of your project, such as a library, it makes them a lot more robust and consistent;
• It's always better to build your components as early as possible since it allows you to build your communications (props & events) on existing and stable components.

Rules

• First, try to build obvious components as early as possible such as: modal, popover, toolbar, menu, header, etc. Overall, components you know for sure you will need later on. On your current page or globally;
• Secondly, on each new development, for a whole page or a portion of it, try to think before rushing in. If you know some parts of it should be a component, build it;
• Lastly, if you're not sure, then don't! Avoid polluting your project with "possibly useful later" components, they might just stand there forever, empty of smartness. Note it's better to break it down as soon as you realize it should have been, to avoid the complexity of compatibility with the rest of the project;

---

This is just my two neurons brain's ideas about it. Feel free to tell me I'm partially or entirely wrong!

Hope to read you soon ! ;)

[pablohpsilva]

@Elfayer I think this is good enough. Great job in my opinion!

What do you guys think? @aristidesfl @shailendher @uonick @DannyFeliz

[Elfayer]

Should we consider this valid?
Where should we add it?
At the very end?

[pablohpsilva]

Hello @Elfayer !
I was waiting on others opinion but I think its very good as it is.
Can you make a PR for it (and add your github/twitter at the end of the file)?

---

@xiaofuzi @wysxhlyy @sqrthree @kciter @shershen08 could you guys translate this new section for the community?

[linhe0x0]

@pablohpsilva Sorry, I missed this message until just now. I have created a PR #46 for this.