Conceptually, components have state, but it's all managed by react, so you only ever write pure functions. Granted, depending on how you update state in event handlers and lifecycle methods, you will need to think about state a lot, but this is an unavoidable fact of UI programming.

> every component must be created by extending a base class

This is an implementation detail, instead of ES6 classes you can also use React.createClass(), which might as well be named React.createComponent(). These "classes" can't be inherited from.

Conceptually is nice. All react code I've seen or wrote of even the most trivial systems have components (and more then a few) that override lifecycle methods - which is by almost definition OO's polymorphism.

Buy even if you could write every component with the stateless style it doesn't change the fact that your framework/GUI-library is using OO extensively and in it's fundamental concepts, I think that makes it OO, you seem to disagree.

It's not "overriding" lifecycle methods, it's passing lifecycle methods to a component factory function.

Also, now in react (as of 0.14 with stateless function components) you can define components as pure functions that return a jsx dta structure to the render function. IE (coded by memory quickly syntax may be wonky): const test_component = () => { return <H1>Blah!</H1>; }

<test_component/>

React supports stateless components, it's literally just a plain JavaScript function.

From the React docs:

> In an ideal world, most of your components would be stateless functions... This is the recommended pattern, when possible.