preface

I finished the first version of the structured Framework in the company today, and then I went back to the structured- React-Hook library THAT I had written, and I was struggling with the name, and I was thinking, How does this way of defining the React component differ from classComponent and functionComponent, until today I had an Epiphany and I realized, This is a way to define the React component with objects → objectComponent, which could be a new way to define the React component. This article will take a closer look at the differences between the way components are defined and objectComponent in the current React ecosystem, and will also point out what I think might be a conscious bias on the part of the React team.

The body of the

The official is not necessarily right

It is well known that in the years since React was released, the React team has waxed and waned in the way components are defined, from the earliest classComponents to the pure-function components proposed in the middle, and more recently, functions with state after hook releases.

But after so many years of practice, we know that both classComponent and functionComponent have their own problems. ClassComponent is too bulky, while functionComponent is more flexible and granular, However, the level of abstraction is low and the business expression is much less than classComponent.

Let’s look at the expressiveness of classComponent and functionComponent using the simplest Button example


class Button extends React.Component{
  constructor(props){
    super(props)
    this.state = {
      text:'button'
    }
  }
  onClick = () = >{
    this.setState({
      text:'Click the button'})}render(){
    return() {<button onClick={this.onClick}>{this.state.text}</button>}}}function Button(props){
  const [text, setText] = useState('button')
  const onClick = () = >{
    this.setState({
      text:'Click the button'})}return(
    <button onClick={onClick}>{text}</button>)}Copy the code

FunctionComponent stacks state, view, event handling logic, etc., into a function. This is a small example of what you might see if you were writing a more complex component than classComponent

const [a,setA] = useState
const [a,setA] = useState
const [a,setA] = useState
const [a,setA] = useState
const [a,setA] = useState
const [a,setA] = useState
const [a,setA] = useState
...

Copy the code

And that’s not to mention the functions within the functions, the various interactive events.

But isn’t classComponent a problem?

ClassComponent is only slightly better at managing state than functionComponent, and can distinguish between event handlers like onClick, but classComponent times are just as difficult.

class.{

renderA(){}
onClickA(){}
transform(){}
render(){}... }Copy the code

You can barely organize your function code in 200 + lines of classComponent. Often they become more chaotic and difficult to manage over time

So is there a better way? Sure, but before showing how objectComponent can improve these issues, let’s take a closer look at the root causes of classComponent and functionComponent’s inability to organize large code.

JavaScript type defects

If you understand that class is just syntactic sugar implemented by JavaScript with some magic, you won’t confuse it with classes mentioned in Java.

JavaScript is often referred to as a hybrid programming paradigm language, including structure-oriented, object-oriented, functional, and so on. You can almost partially emulate these programming paradigms in JavaScript.

Note the term, part of which I’ve mentioned in previous posts, that the so-called big front end is more of a mockery of its inability to completely replace neighboring technology areas. On mobile, no matter how much we trumpet and struggle, it’s still a native language, and on the server side, NodeJS has never really gone mainstream. Full stack is also a popular niche culture

Classes in JavaScript, there’s really nothing but classes, and JavaScript is a toy when it comes to type programming compared to Java, and if you look at the Java programming guide, And then trying to write the same efficiently organized code in JavaScript would be crazy.

This means that when you use classes to organize your JavaScript code, you run into the awkward dilemma of not being able to extend it.

What did React do to solve this problem?

Early mixins and later HOC

In fact, I think HOC is worse than mixin, but React implementation is a problem.

HOC is essentially a higher-order function that utilizes the bizarre feature of JavaScript class = function to implement a very bizarre extension. Top class…

Compared to inheritance, I find HOC really ingenious.

This kind of matryoshka logical extension has proved unworkable in practice. Because HOC turns an extension of one component into a two-component problem, requiring multiple sets of components without adding a layer of extension. That doesn’t stop the wild imagination of Chinese product managers.

React will propose HOC. I once thought it was because the product manager of FB was not helpful. We should send two Chinese product managers there, maybe they would understand.

Let’s just say the React team is addicted to functions. High-order classes don’t work. Hence the hook

Functional programming is a pit

Functions are first-class citizens in JavaScript, but as we all know, they’re functions in the guise of objects, and objects are first-class citizens. Over the years, I’ve been brainwashed by functional programming, and now I think functional programming has failed to find a breakthrough in other languages, and finally found its spring in JavaScript, a child with no parents.

We are not going to discuss the origin of JavaScript and functional programming here, but I just want to point out that if functional programming can be widely used in industrial software development, it also needs to look for opportunities in the front end.

Do you expect functional Node to do Java?

JavaScript has long given the answer, its own is the best

We used to call JavaScript a toy in the early days, but over the years I’ve come to realize that JavaScript has moved beyond functional and type-based object orientation.

JavaScript has more power than either of these programming paradigms. How else do you emulate them?

JavaScript has the ability to define and manipulate objects naturally, and this object can be serialized directly → JSON.

Powerful dynamics allow you to flexibly adjust the scope of an object, even a part of the scope of the object itself

const object = {
  method(){
    console.log(this)}}const other = {}
object.method.call({})
Copy the code

At first the old-timers called it taboo, while the mainstream thought JavaScript’s This was the root of all evil. But in the framers’ eyes, the ability to control scope is not the root of all evil, but rather the ultimate treasure.

Because JavaScript is a feature that allows components to come to life. Let front-end components have a strong ability to expand. The ultimate extension of this ability is customization

Traditional components are not customizable, and often you can only extend them appropriately through apis to suit the vision of the component definer.

But customization is never preset. For customization, you can understand that it is an idea that Party A’s father thinks of at any time. I just asked if you could.

And the trick is to use objects to define components, ObjectComponent. In React, it looks like this.

const Button = createComponent({
  name:'Button'.initState: {text:'button'
  },
  controller: {onClick(){
      this.rc.setState({
        text:'You clicked the button.'})}},view: {render(){
      return() {<button onClick={this.controller.onClick}>{this.state.text}</button>}}}})Copy the code

When an object is a component, and a component is an object, a lot of things get simpler.

Dynamically creating components

If you’ve ever developed dynamically rendered component containers, you’ve probably used createElement. This usually requires you to define a classComponent or functionComponent first, but we know that the logic inside a component cannot be changed or extracted. In addition to passing props, the props definition is a static process, because you need to write code in advance for the props that are passed in. This process is non-dynamic, so components are created dynamically, not customized.

But if the component itself is an object, that means we don’t need to go through props and write static consumption code for it, you can just do it.

const Button = {
  name:'Button'.initState: {text:'button'
  },
  controller: {onClick(){
      this.rc.setState({
        text:'You clicked the button.'})}},view: {render(){
      return() {<button onClick={this.controller.onClick}>{this.state.text}</button>}}}}const NewButton = createComponent(Button, {name:'NewButton'.initState: {text:'New button'}})

Copy the code

You can even modify the view part of the component without having to worry about affecting the props view as the object component is a separate object instance based on the object.

const Button = {
  name:'Button'.initState: {text:'button'
  },
  controller: {onClick(){
      this.rc.setState({
        text:'You clicked the button.'})}},view: {render(){
      return() {<button onClick={this.controller.onClick}>{this.state.text}</button>}}}}const TwoButton = createComponent(Button, {name:'TwoButton'.initState: {text:'Two buttons'},view: {render(){
    <div>
      <button onClick={this.controller.onClick}>{this.state.text}</button>
      <button onClick={this.controller.onClick}>{this.state.text}</button>
    </div>}}})Copy the code

Is there any other gameplay? I think there is, and it should be rich, because JavaScript objects are so flexible, and you can try to manipulate components the way you manipulate objects, so use your imagination.

If you want to try this definition, fine

yarn add structured-react-hook
Copy the code

then

import {createComponent} from 'structured-react-hook'
Copy the code

If you want to follow this project, you can go to github.com/kinop112365… Under the Star

The createComponent details were not updated in the library documentation, but I did update the original instance in the README

For others, you can follow me and we will update our team’s exploration in this aspect from time to time. I think there will be more interesting things to share with you! 😁