What if: class components?
See original GitHub issueAbout class components (https://github.com/jorgebucaran/superfine/issues/134), I was thinking, what if we could do something like this?
import { h, Super, patch } from "superfine"
class Hi extends Super {
state = { say: "Hi" }
render = () => (
<h1>{this.say}</h1>
)
}
patch(null, <Hi />, document.body)
Just throwing crazy ideas out there?
Issue Analytics
- State:
- Created 5 years ago
- Comments:55 (52 by maintainers)
Top Results From Across the Web
Is There Any Reason to Still Use React Class Components?
Component class inherited from the React library (hence why it's called a Class Component).
Read more >React Class Components - W3Schools
Components are independent and reusable bits of code. They serve the same purpose as JavaScript functions, but work in isolation and return HTML...
Read more >When to use a Class Component over a Function Component ...
Class components need to extend the component from “React.Component” and create a render function that returns the required element.
Read more >Components and Props - React
Components let you split the UI into independent, reusable pieces, and think about each piece in isolation. This page provides an introduction to...
Read more >React Class Component vs Functional Component - Telerik
This article will explain the differences between class and functional components and how to choose between them. If you're a React ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
@jorgebucaran I’m actually still with (past?) you on this one - classes/constructors are not the best approach to stateful components.
React is increasingly moving away from instance life-cycle methods (for various reasons) towards static class life-cycle methods, or in other words, a bunch of functions that don’t have anything to do with the component instance and only with the component type.
This is why I started talking about a service-oriented approach - so like:
In other words, move away from components as instances, to components as some sort of service interface responsible for each of the life-cycle phases of component state - everything becomes a pure function, and, especially, the render-function becomes a pure function of the state.
I haven’t thought through this, but as long as we’re just kicking around ideas, method-props would probably allow you to write event-handlers that are pure functions as well - which would be a big step up from P/React where you always need to create and initialize instance-properties in the constructor to hold event-handlers, to avoid generating new function-instances for every component…
By the way, this RealWorld app doesn’t really seem to have any custom controls with accidental state, so I’m not sure it’s that helpful in the context of what I’m talking about.
Interesting real-world cases of accidental state I’ve run into so far include: a drop-down date-picker (collapsed/expanded state, month navigation state), any sort of property-sheet (with input states that don’t apply to the model until you press “save”) and a photoshop-style cropper. (keep the entire cropper state internally while dragging the corners and doesn’t apply that state until you stop dragging.)
It seems like most people don’t run into these cases, but for some reason I run into them all the time 😉