Earlier quoted context omitted.
0.3 - 0.1 = 0.19999999999999998
Floating point error, present in every language that uses floats. This is in no way unique to JavaScript.
Talk is cheap, give an example in code.
React: Mixins Considered Harmful
131–140 of 205 posts
Re: React: Mixins Considered Harmful
#132Re: React: Mixins Considered Harmful
#133Earlier quoted context omitted.
>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.
Could you expand on string refs as an anti-pattern?
I wouldn't necessarily call them an anti-pattern, but they are at the very least not encouraged:
> Although string refs are not deprecated, they are considered legacy, and will likely be deprecated at some point in the future. Callback refs are preferred.[1]
I'm still using them in React Native, because I'm new and didn't realise there was an alternative until recently. To me there are three issues:
1. Magic. All you do is specify a string and somehow you end up with this.refs.. Admittedly not that hard to follow, but magic is generally bad.
2. It's hard to keep track of what refs actually exist, which makes naming collisions hard to notice. There's just some arbitrary string in some JSX. Using explicit properties means they can be tracked much more easily e.g. Flow.
3. Again related to Flow, if you're declaring your properties as you should be, then Flow will tell you if swapping a referenced component type (checkbox for switch etc.) is going to cause problems elsewhere in code.
EDIT: I suppose you could already be declaring your refs with Flow. However, if you're doing that you're already 90% the way to using dedicated properties. In which case you might as well eliminate the magic and just use your own properties, rather than properties on refs. This makes searching for usage/references much more obvious; people/IDEs generally don't think of strings being a reference to a variable.
[1] https://facebook.github.io/react/docs/more-about-refs.html
Re: React: Mixins Considered Harmful
#134Awesome post Dan, thanks for writing and sharing!
One thing caught my attention:
>At Facebook, we extensively use traits in Hack which are fairly similar to mixins. Nevertheless, we think that mixins are unnecessary and problematic in React codebases. Here’s why.
>Mixins introduce implicit dependencies
>Mixins cause name clashes
>Mixins cause snowballing complexity
When I read these three reasons, I actually felt identified with them even outside React, since these as pretty generic problems in "mixin-like" cases that I've seen, for example Ruby modules. So it got my attention the fact that you're (at Facebook) using Hack traits successfully. Why is that? Are any of those reasons you stated not true with Hack traits? (Maybe you don't have knowledge in Hack though, but any high level conceptual idea may help).
Again, awesome post!
Re: React: Mixins Considered Harmful
#135Earlier quoted context omitted.
Talk is cheap, give an example in code.
Python REPL: >>> 0.3 - 0.1 0.19999999999999998 Ruby REPL: 0.3 - 0.1 => 0.19999999999999998
https://repl.it/Cbqb
unless your Python compiler runs on some sort of JavaScript (-:
Re: React: Mixins Considered Harmful
#136Earlier quoted context omitted.
Python REPL: >>> 0.3 - 0.1 0.19999999999999998 Ruby REPL: 0.3 - 0.1 => 0.19999999999999998
https://repl.it/Cbqb unless your Python compiler runs on some sort of JavaScript (-:
And while you're at it, do you know of any other language that does this?
http://pasteboard.co/bbM0qneiQ.jpg
Re: React: Mixins Considered Harmful
#137Earlier quoted context omitted.
> You won’t find any place in React docs that claims internal state is harmful. But it is the first principle of Redux The state of your whole application is stored in an object tree within a single store. [1] Am I getting it wrong? > I plan to put up “Design Goals” document in the repo That would be great. The "why" is sometimes hard to understand. [1] http://redux.js.org/docs/introduction/ThreePrinciples.html
I think you are confusing React with Redux. They are two very different things. You can use them together but Redux is not the “default” way of using React. >But it is the first principle of Redux Redux is a very opinionated library and it is not related to React in any way. React does not officially endorse Redux. If (and that’s a big if!) React patterns don’t scale for you or if you personally prefer Redux to them,…
Dan,
First, thank you for all you do. Huge fan, and you're an asset to the community.
One question I have is around this quote:
> Learn React first and try to use it. If you have issues related to state or if you’re just curious, you can also learn Redux to compare their approaches.
I tried to go down this route with a new employee who I've positioned on a React project (mostly as means of exploration + learning in between other projects)
But as soon as I had to deal with fetching data from the server and pushing it back, I felt the need to jump into Redux. Yes, I could manage this in React, but as soon as I had two "pages" in my app, I feel it would become unwieldily note to use the Redux + Redux-Think (or Sagas) combo.
Am I wrong here, or am I just "comfortable" with Redux, and thus, not persuing the idea of trying to build a more featured app in pure React?
Re: React: Mixins Considered Harmful
#138Does that mean the LinkedStateMixin is going away?
Re: React: Mixins Considered Harmful
#139So there are a lot of features in React that are basically getting deprecated, like createClass in favor of ES6 components, mixins, etc. This is good that you guys are learning as you go, my question is will you ever release a version of React, possibly spin React off into a version which supports deprecated APIs and a version that doesn't and is therefore smaller, faster, and easier to maintain? Eventually you could drop support entirely for the deprecated feature. That would be the best response to this IMO.
Re: React: Mixins Considered Harmful
#140It's not clear to me why (in the pattern presented) the decorators don't return a subclass (which would preserve the dynamic and static properties and methods, etc). Instead you get hacks like `hoist-non-react-statics` to copy them over manually.
For context, the article advocates the following:
import GlobalClass from 'global-class'
const decorator = SuperClass =>
class extends GlobalClass {
render() {
return
}
}
const decorator = SuperClass =>
class extends SuperClass {
render() {
// const SuperClass = super.constructor // if you want to be less explicit...
return
}
}
Returning a different kind class entirely limits the utility of the pattern in general (IMO), and you lose the nice function-composition-like behaviour provided by `super.method`.