Hacker News Reader

Comment by Kiro | Hacker News Reader

I'm interested in learning more about reusability. One problem I have with React is that I've made this component called Product and then I need another Product component but in a different context, for example in a listing with a thumbnail. Much like the carrot example. How do you approach this exactly? Shouldn't it be based on the same component somehow?

View on HN

I think reusability is something that comes with practice. And I'm starting to think that "write once, reuse forever (without modifications)" is just a pipe dream.

Lately I've been realizing how easy it is to fall into the "abstraction trap". It's exactly your situation: I have a Thing. I need a new Thing that's slightly different, but I don't want to copy all the code! That's not DRY! It's paralyzing.

So instead of duplicating code I spend time trying to tweak Thing, passing in parameters, adding special rendering cases, and finally it works as Thing and a smaller Thing2. But it's a mess, and it's not factored well, and it'll be a nightmare when Thing3 comes along.

Check out this article from the other day: http://programmingisterrible.com/post/139222674273/write-cod...

In line with his idea of copy-pasting code, I think that's the way to go: copy all the code from Product, paste it into ProductThumbnail, and make it work. THEN refactor it, and pull out reusable bits... or compose the two somehow... etc.

I think the flow you write should always be the way you work with code. First make sure it works, then look how to improve it, what parts are expressing similar behavior, what parts are different etc. If I remember correctly this is also what Robert Martin advises in Clean Code [1]. And it makes sense, worrying too much over what the abstractions are going to be is only going to slow you down.

I normally go even a bit further (certainly on the frontend) and leave duplication until I wrote something 3 or 4 times (or until it has stayed there for a little while). This ensures that when I do write my abstracted component I'm actually making sure it is something that can, at least within that app, be re-used.

I do re-use React components between different projects but am also using the same Bootstrap theme so this makes a lot of components really easy to re-use.

[1]: https://www.goodreads.com/book/show/3735293-clean-code

I think the vague answer is 'use mixins', but they are generally unsatisfying. One hopes that using ES6 classes to define react components this way would allow proper inheritance, but the whole ES6 thing is a mess that breaks a bunch of other things (notably autobinding this). Upshot is my code remains repetitive.

Where possible you can use composability, extracting common function into a subcomponent, but this doesn't always make for neater code.

Ugh no. Please don't use mixins or inheritance. Composition is the way to go.

https://en.wikipedia.org/wiki/Composition_over_inheritance

Do you have any example React code using composition?

Same way you compose functions or HTML elements.

Functions:

    add(1,multiply(2,3))

HTML:

    <div>foo <span>bar</span> </div>

React:

    <Container> <Header>foo</Header> <p>content</p> </Container>

To be pedantic, that is not quite composition - I've made this exact mistake before too. Composition is where you have a function f o g (o being the traditional mathematical notation for composition), where (f o g)(a) = b satisfies g(f(a)) = b.

Composition is a useful tool, and so is writing functions like this, but they are two different ideas.

>but the whole ES6 thing is a mess that breaks a bunch of other things (notably autobinding this).

That's trivial to fix...

How?

Use one of the community-built subclasses of React.Component that provide auto-binding, like https://github.com/philpl/react-compat-component, or a utility function that's a one-line call like https://github.com/cassiozen/React-autobind.

If it's a class based component (ES6), it could inherit from the other.

But you could also extract the code logic in a product module, and reuse it in both components, which can even be pure functions.

This is not limited to ES6+, class/inherits/super are syntactic sugar for existing prototypical OOP idioms.

It's not limited to ES6, but it's not needed with the ES5 way of declaring React components, as mixins are supported there.

Actually you don't need to use React.createClass to use mixins, there is https://www.npmjs.com/package/react-mixin which implements them via decorators. Either I wouldn't consider inheritance and mixins interchangeable.

Reply on news.ycombinator.com