4 ms·

I personally moved all my projects away from mixins a while ago when I first heard they were deprecated. At first I was frustrated because of JS churn but this

by n0us 10y ago

I personally moved all my projects away from mixins a while ago when I first heard they were deprecated. At first I was frustrated because of JS churn but this certainly was the right move. For anyone who is apprehensive, the shift in thinking from using mixins to HOCs was not so difficult even if it's initially puzzling. Quick edit: forgot to mention that this shift made my code way easier to understand in some places and thus the initial investment saves dev time in the long run.

auvrw 10y ago
from the article > Let’s make it clear that mixins are not technically deprecated. If you use React.createClass(), you may keep using them. We only say that they didn’t work well for us, and so we won’t recommend using them in the future.
- rimunroe 10y ago
  I think around React 0.14, they announced that React's support for es6 class syntax wouldn't support mixins, and you'd only be able to get them by using the old .createClass method. I think they pointed out that they didn't see this as a big issue because mixins were a pattern they wanted to get away from anyway and saw better solutions to.
- deleted 10y ago
  [deleted]
thatswrong0 10y ago
I'm a fan of HOCs as well. My only problem with them is that I'm also a fan of shallow testing, and HOCs don't play nicely with shallow testing. I'm waiting on something like this (https://github.com/airbnb/enzyme/issues/250 https://github.com/airbnb/enzyme/issues/250) to get implemented
- coderzach 10y ago
  Why not just mock the HOC to be the identity fn? `(Component) => Component`
  - eiriklv 10y ago
    This is my preferred approach as well - and it (anecdotally) works great, since you can then just manually inject any props/spies as needed like any other "dumb" component. Edit: But he might be pointing to the testing of the actual HOCs/component decorating functions.
- mg74 10y ago
  Export every component like this: export class MyComponent extends React.Component { ... } export default SomeHOC(MyComponent) And in your test simply import the non-hoc version: import { MyComponent } from './mycomponent' Now the HOC won't get in the way of your testing.
amelius 10y ago
> I personally moved all my projects away from mixins a while ago when I first heard they were deprecated. Mixins were actually one of the things that turned me away from React in the first place. Perhaps a good time to reconsider :) (Are there any other known anti-patterns left in React?)
- danabramov 10y ago
  >Are there any other known anti-patterns left in React? String refs and `findDOMNode()`. Both are anti-patterns but not deprecated yet. Both replaced by callback refs.
  - adregan 10y ago
    Could you expand on string refs as an anti-pattern?
    - johncip 10y ago
      I'd like an answer to this as well. I've only ever needed string refs, and the callback refs are noisy. I can see where the React team may not want to support both, but are string refs actually bad in some way?
      - danabramov 10y ago
        String refs are bad in quite a few ways: 1. String refs are not composable. A wrapping component can’t “snoop” on a ref to a child if it already has an existing string ref. On the other hand, callback refs don’t have a single owner, so you can always compose them. 2. String refs don’t work with static analysis like Flow. Flow can’t guess the magic that framework does to make the string ref “appear” on `this.refs`, as well as its type (which could be different). Callback refs are friendlier to static analysis. 3. The owner for a string ref is determined by the currently executing component. This means that with a common “render callback” pattern (e.g. `<DataTable renderRow={this.renderRow} />`), the wrong component will own the ref (it will end up on `DataTable` instead of your component defining `renderRow`). 4. String refs force React to keep track of currently executing component. This is problematic because it makes `react` module stateful, and thus causes weird errors when `react` module is duplicated in the bundle. This is why we want to move away from them in favor of callback refs that solve all those problems.

by n0us 10y ago

auvrw 10y ago

from the article > Let’s make it clear that mixins are not technically deprecated. If you use React.createClass(), you may keep using them. We only say that they didn’t work well for us, and so we won’t recommend using them in the future.

rimunroe 10y ago
I think around React 0.14, they announced that React's support for es6 class syntax wouldn't support mixins, and you'd only be able to get them by using the old .createClass method. I think they pointed out that they didn't see this as a big issue because mixins were a pattern they wanted to get away from anyway and saw better solutions to.
deleted 10y ago
[deleted]

thatswrong0 10y ago

I'm a fan of HOCs as well. My only problem with them is that I'm also a fan of shallow testing, and HOCs don't play nicely with shallow testing. I'm waiting on something like this (https://github.com/airbnb/enzyme/issues/250 https://github.com/airbnb/enzyme/issues/250) to get implemented

coderzach 10y ago
Why not just mock the HOC to be the identity fn? `(Component) => Component`
- eiriklv 10y ago
  This is my preferred approach as well - and it (anecdotally) works great, since you can then just manually inject any props/spies as needed like any other "dumb" component. Edit: But he might be pointing to the testing of the actual HOCs/component decorating functions.
mg74 10y ago
Export every component like this: export class MyComponent extends React.Component { ... } export default SomeHOC(MyComponent) And in your test simply import the non-hoc version: import { MyComponent } from './mycomponent' Now the HOC won't get in the way of your testing.

amelius 10y ago

> I personally moved all my projects away from mixins a while ago when I first heard they were deprecated. Mixins were actually one of the things that turned me away from React in the first place. Perhaps a good time to reconsider :) (Are there any other known anti-patterns left in React?)

danabramov 10y ago
>Are there any other known anti-patterns left in React? String refs and `findDOMNode()`. Both are anti-patterns but not deprecated yet. Both replaced by callback refs.
- adregan 10y ago
  Could you expand on string refs as an anti-pattern?
  - johncip 10y ago
    I'd like an answer to this as well. I've only ever needed string refs, and the callback refs are noisy. I can see where the React team may not want to support both, but are string refs actually bad in some way?
    - danabramov 10y ago
      String refs are bad in quite a few ways: 1. String refs are not composable. A wrapping component can’t “snoop” on a ref to a child if it already has an existing string ref. On the other hand, callback refs don’t have a single owner, so you can always compose them. 2. String refs don’t work with static analysis like Flow. Flow can’t guess the magic that framework does to make the string ref “appear” on `this.refs`, as well as its type (which could be different). Callback refs are friendlier to static analysis. 3. The owner for a string ref is determined by the currently executing component. This means that with a common “render callback” pattern (e.g. `<DataTable renderRow={this.renderRow} />`), the wrong component will own the ref (it will end up on `DataTable` instead of your component defining `renderRow`). 4. String refs force React to keep track of currently executing component. This is problematic because it makes `react` module stateful, and thus causes weird errors when `react` module is duplicated in the bundle. This is why we want to move away from them in favor of callback refs that solve all those problems.