Ok I have a bunch of components that all have the same logic but have different css classes. So I wanted to create a sort of factory function that takes the names of the classes as its argument and returns a component. Here is a very simplified example:

const buttonFactory = (classes) => (props) => {
  // ... some logic here
  return <button className={classes} {...buttonProps} />

export default buttonFactory

Then elsewhere I can create a button as such:

import buttonFactory from "./factory"

const BigButton = buttonFactory('text-2xl');

export default BigButton;

Now this works fine (so far) but when I look up component factory on google I see something completely different. It's not exactly a higher order component either. So my question is actually twofold: Is there a name for this? Is there something wrong with it, like will it cause serious performance issues?

  • It's just the usual factory function (creator helper, an "ad hoc constructor"), the fact that it returns a react component is irrelevant. (BTW, if you're looking for a classic pattern, note that, while this pattern is common, the original Go4 book does not include it - although it does include a couple of other factory patterns (specifically, not to be confused with Factory Method)). Jan 11 at 8:04

3 Answers 3


"when I look up component factory on Google"

This is your problem. "Component" (as well as "pattern") is a extremely generic term, which (even when restricted to the context of software engineering) can have dozens of different meanings. "component factory" is still not specific enough.

Software development is not always "web programming", and there are way more "components" than just "HTML and Javascript UI elements". I recommend to read Spolsky's Five Worlds essay to extend your point of view a little bit.

The solution is to add keywords to your search which clarify the context. For example, I tried to google "component factory reactjs", and got lots of examples for the kind of factory function in your question. And yes, I think "factory function" is fully valid name for it. It may not be 100% identical to the factory method implementation from the original GoF book, but still equal "enough" on the conceptual level to justify the usage of the same name.

  • react component factory does not really help either. The issue is mainly that there are other patterns for react that are sort of similar but also considerably different.
    – kaan_a
    Jan 11 at 11:28
  • @kaan_a: well, I don't know what criteria you apply for "considerably different", but this is the first link I got from Google using the keywords from my answer, and it looks pretty similar to your case. If it is not, try to ask a more precise question.
    – Doc Brown
    Jan 11 at 11:35
  • 2
    @kaan_a: "The issue is mainly that there are other patterns for react" - may be so, but navigating through that is up to your googling skills, and your ability to sift through obtained information. Doc Brown gave you an example of how you could refine the search - it's up to you to try different variations of that, or try something different following the same principle. You can use the same strategy to find information for other problems you'll encounter in the future, so it's a valuable skill to develop. Jan 11 at 14:33

The first question which comes to my mind is:

Does it really matter what pattern it is?

What was your first thought?

So I wanted to create a sort of factory function that takes the names of the classes as its argument and returns a component.

Does it, what you wanted it to do? Yes.

Is it easy to understand? Yes.

Is it easy to change? Yes.

Does it help with DRY? Yes.

So you wrote a piece of code which your codebase will benefit from. And it does so independently whether or not it is an already classified "pattern". So why are you worrying, that you maybe implemented no factory or did implement the pattern wrongly? Patterns are like tools: It is nice to have them at hand when you need them, but it isn't always bad, if you don't use them.

On the other hand: it doesn't hurt if you implement patterns without knowing how they are called. I think the big win of having "patterns" is, that you have terms for ways of how to solve some kind of problems and could talk to other software engineers about.

And imagine if you talk about the "factory" you built lately and another engineer explained to you it was rather a "builder" - what's the deal? The worst outcome is, that you learn what the difference is.

It's not exactly a higher order component either.

From what I know about react, I would say that you are right: it is no higher order component.

Is there something wrong with it, like will it cause serious performance issues?

From what you presented here I would say: No. Just nice and simple code.

Is there a name for this?

I would indeed say that it is a factory: It abstracts / encapsulates the creation of an object (here a react component). That's the "spirit" of a factory.


Maybe you are taking the pattern thing too strictly. The pattern description on wikipedia looks very close to your implementation. The key thing here is to use a common interface for the created component and in your case that is the button element.

It's worth saying that the origin of most patterns is in compiled languages (like C++, Java) and there it makes sense to apply them carefully since the purpose was to allow older application to create/work with new components delivered through a plugin, without rebuilding or redeploying the whole system.

  • 1
    You're right that patterns shouldn't be taken too strictly, but they do have defining features. Factory (a.k.a. factory function) and Factory Method are two distinct creational patterns. The first one is basically just a helper method for creating objects of a specific type (and is not described in the Go4 book), while the second one acts as a "virtual constructor", allowing the base class (or pluggable framework) to request creation of objects of unknown concrete type, possibly objects that don't exist yet (e.g., they could be provided in the future by a derivative or a plugin). Jan 11 at 8:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.