This is another of those updates that comes with a bit of a health warning.
You should probably only read on if you are interested in front-end programming, React in particular.
Here is a link to the package that I will be referring to:
-
[github] reaction An alternative implementation of React.
To begin with, I quickly want to define what mixins are.
This definition differs a little from React's, for reasons that will become apparent.
A mixin is a function that can be assigned to a class by some means in order to become a method.
Typically mixins are assigned en masse, in fact in some languages such as Dart a mixin refers to a collection of these functions rather than just one.
Dart also has a mechanism to enable dependencies between mixins to be enforced.
There is no such mechanism in JavaScript, however, indeed mixins are not language features, and this is often cited as a drawback.
Nonetheless, the judicious use of mixins can be a considerable organisational boon.
I certainly make judicious use of them, see here, for example.
React's mixins differ slightly from the above.
They are assigned specifically to class instances rather than generally to the classes themselves.
This is going to be slower, for a start, moreover it used to be the case that mixins could not be avoided.
Either you used a mixin to define a method in certain cases, or you had to make do without.
So why did React implement mixins in this way?
Take a look at part of Reaction's React.createElement() function here.
You can see that the underlying ReactFunctionElement class is instantiated and then passed the function referenced in the JSX.
The function itself is not invoked immediately, however.
This happens only when the underlying element is mounted.
It appears that React adopted a similar pattern in order to support either calling the React.createClass() function or extending the Component class.
In both cases a corresponding underlying element class is instantiated and passed a suitable reference, see here for the equivalent in Reaction.
It was this dichotomy that seemed to have resulted in the need for React's mixins, which bind functions to instances of these underlying element classes as ooposed to, say, instances of subclasses of the Component class.
Now you could argue that all of the above is a bit unconvincing.
After all, in has been possible to define methods in subclasses of the Component class for years.
My excuse is I could not get Reaction to work all those years ago without the aforementioned dichotomy and that React's mixins ratified it at the time.
Anyway, recently I have been working on the Open Mathematics site again, which uses Reaction, and have gotten increasingly fed up with React's mixins.
So I wondered whether it would be possible to do away with them, as React had done.
The obvious solution was to merge the Component class and the underlying ReactComponentElement class into one and then instantiate just the subclasses of the former, see here.
And this worked!
It worked because it is not the instantiation of the subclass of the Component class that is deferred until mounting, it is always instantiated immediately, but only the invocation of its render() method.
So now you can extend the Component class and define methods in your subclass, just like React.
Reaction still does not support diffing, and therefore remains quite a different experience to React, but still.
Here are links to two other packages related to Reaction:
-
[github] inference A dispatcher in a similar vein to Redux.
-
[github] reaction-with-style Programmatic styles for Reaction.
I think that between them they now constitute a viable alternative to the combination of React, Redux and Styled components, although I remain a big fan of the latter.
