Best Practices for Extending/Subclassing Components?


(Mikayel) #23

I don’t know who made the decision to deprecate React.createClass in version 16 and why.
How you can switch to the new class syntax that is not well supported for JSX you need to bind all methods in constructor, and it dose not support inheritance.
Because of that I have to change more the 300 components.
I you continue to make this kind of decisions, a lot of developers will start looking for better framework :frowning:


(Gunnar Forsgren) #24

Helped me, but a minuscule typo remark; the 2nd ‘render’ in there is likely meant to be ‘return’


(Gunnar Forsgren) #25

It indeed sounds like enemy agents infiltrated a React architecture team to destroy the power of React ?


(Mikayel) #26

It is just “Silicon Valley” irresponsible style, just do it because it is trendy, without thinking about existing code…
Look at VueJs, it is getting more popularity because they didn’t change syntax even when they change from V1 to V2.


(Dan Abramov) #27

createClass still works fine and will continue for the foreseeable future. I’m afraid you were misinformed. There is no need to manually convert any code.

The only change is it moved to a different package. There is an automated script that does the conversion so you don’t need to do anything by hand.

Please read the blog post that explains how to use it:

At Facebook, we converted thousands of components automatically. So can you.


(Mikayel) #28

Thanks Dan, I am familiar with your mentioned blog post.
“create-react-class” is not a long term solution, it is a temporary fix.
See the sentence from mentioned blog post “For your existing createClass components, we recommend that you migrate them to JavaScript classes.”

Maybe at Facebook you can afford 2 different types of syntax. Yes, you can afford the best developers, but in small startups it is not an option.
It will add learning time for beginners (finding docs for old syntax is not easy anymore…). Maintaining 2 different types of syntax will add extra time and then adding new functionalities will cost more…
The only option for me was to migrate all 500+ components to JavaScript classes, and I did…

When you use “CLASS” it assumes OOP, but it is not working with React’s compositional nature.
No inheritance support, not working well with JSX (you need to bind all methods in constructor)…

One of the reasons I have moved from Angular to React is V1 to V2 syntax change.

I relay like React, when you are doing big changes please think about small guys as well…


(Dan Abramov) #29

We migrated thousands of components automatically. I’m not sure if you realized this (sorry if I’m restating the obvious), but the codemod mentioned in the blog post will convert components to new syntax ahromatically whenever it is possible. There are cases where it isn’t (e.g. if you use mixins) but those should be possible to gradually remove.

It is confusing to our developers too, but getting away from createClass was inevitable. There are many reasons why it is inferior: it doesn’t work with static typing (e.g. TypeScript) which is becoming more and more popular, it adds extra bundle size (which is an issue for everyone who targets countries with 2G connections), and it slows down initial rendering. We did not do it lightly but the choice was between doing it, or gradually becoming irrelevant.

I’m not quite sure what you mean, but if you enable class properties transform (currently stage 2) you don’t need to bind anything. Declare event handlers like this:

handleClick = (e) => {
}

Then they will be autobound. Again, the benefit of doing it manually is that it only happens where necessary, and so less time is spent on application startup.

Your assumption that we don’t (and previous comments in the thread about “Silicon Valley style”) are hurting me personally. You might not realize this but we spent months of effort on issues that don’t matter to us that much, but matter to the community. Yes, sometimes we make tough choices like this, but we always ensure there is a viable migration path, and for this particular case the old code continues to work for the foreseeable future. If you follow the repo closely I hope you’ll see how much of our effort goes into ensuring backwards compatibility, making these migration paths work well for the community, and so on.


(Mikayel) #30

I am relay sorry Dan. I never want to hurt anyone and especially you personally :frowning: I have learned a lot from you and your codes. And I am very thankful about that!
After this discussion I am totally agree that you do care about react community, and I can see that moving to JavaScript Classes is painful but right decision.

I was more conservative and selfish, because we have big client that is using very old and unknown browser (Cisco StadiumVision DMP) for their 2000+ screens, and it is working only with old react and createClass :frowning: