Really Reactive React
Tags: webdev, javascript, reactivity, react
Published: 2024-03-02 10:13:19

ReactJS is now the most popular framework, despite many architectural blundes. Here are just a few of them:

- The component does not track external states on which it depends; it is updated only when the local one changes. This requires careful subscriptions/unsubscriptions and timely notifications of changes.
- The only way to change one parameter of a component is to completely re-render the external component, regenerating all the parameters for both it and *neighbors*. The same applies to adding/removing/moving a component.
- When moving a component between containers, it is completely recreated. Conversely, different instances of the same component may be inappropriately reused.
- Callbacks created on the fly lead to unnecessary rerenders, so they require careful memoization with a precise indication of the variables used inside them.
- To update values in closures, you still have to recreate callbacks, which leads to unnecessary rerenders.
- Hooks [cannot](https://reactjs.org/docs/hooks-rules.html) be used in conditions, loops and other places where the execution flow is dynamic, otherwise everything will break.
- Errors and wait indications occur outside the component. The component turns out to be not self-sufficient and fatally affects both the external component and, as a result, its neighbors.
- The component cannot be partially updated - only a full rerender. To overcome this, they either coat themselves with memoization or unnecessarily increase the granularity of the components.
- Lack of control of a stateful component often leads to the need to split each component into two: a controlled stateless and an uncontrolled stateful wrapper over it. Partial control is associated with difficulties and copy-paste.

Well, let's cure the patient, and at the same time show the ease of integration of the reactive library [$mol_wire](https://github.com/hyoo-ru/mam_mol/tree/master/wire) into a completely foreign architecture.

![](https://habrastorage.org/webt/us/ly/ea/uslyear0opiathg8whfifakmjue.jpeg)

Let's start from afar - write a synchronous function that loads JSON via a link. To do this, write an asynchronous function and convert it to synchronous:

```ts
export const getJSON = sync( async function getJSON( uri: string ){
	const resp = await fetch(uri)
	if( Math.floor( resp.status / 100 ) === 2 ) return resp.json()
	throw new Error( `${resp.status} ${resp.statusText}` )
} )
```

Now let's implement the API for GitHub, with debounce and caching. We will only support loading issue data by its number:

```ts
export class GitHub extends Object {
		
	// cache
	@mems static issue( value: number, reload?: "reload" ) {
			
		sleep(500) // debounce
			
		const uri = `https://api.github.com/repos/nin-jin/HabHub/issues/${value}`
		return getJSON( uri ) as {
			title: string
			html_url: string
		}
			
	}
	  
}
```

No matter how many times we access the data, the result will be returned from the cache, but if we still need to reload the data, we can pass an additional parameter to start the task of updating the cache. In any case, the request will not go immediately, but with a delay of half a second.

Now, finally, we move on to creating components. Contrary to the popular trend, we will not emulate objects through dirty functions with hooks, but will use class components. And in order not to repeat the same logic, let's create a base class for our components:

```ts
export abstract class Component<
	Props = { id: string },
	State = {},
	SnapShot = any
> extends React.Component<
	Partial<Props> & { id: string },
	State,
	SnapShot
> {
	
	// every component should have guid
	id!: string;
	
	// show id in debugger
	[Symbol.toStringTag] = this.props.id
	
	// override fields by props to configure
	constructor(props: Props & { id: string }) {
		super(props)
		Object.assign(this, props)
	}
	
	// composes inner components as vdom
	abstract compose(): any
	
	// memoized render which notify react on recalc
	@mem render() {
		log("render", "#" + this.id)
		Promise.resolve().then(() => this.forceUpdate())
		return this.compose()
	}
		
}
```

The main idea here is that each component should be completely self-sufficient, but at the same time controllable - any of its public fields can be overridden through props. All props are optional, except for the identifier, which we require to be set externally so that it is globally unique and semantic.

It is important to note that props are not tracked by the reactive system - this allows you to pass callbacks to them and this will not cause rerenders. The idea here is to separate the initialization (by pushing props) and the actual work (by pulling through callbacks provided in the props).

Initialization occurs when the class is constructed, and dynamic work occurs when the framework calls `render`. ReactJS is notorious for calling it too often. Here, thanks to memoization, we take over control from the framework over when rerenders will actually occur. When any dependency on which the rendering result depends changes, the reactive system will recalculate it and notify the framework about the need for rerender, then the framework will call `render` and will receive a fresh VDOM. In other cases, it will receive the VDOM from the cache and do nothing further.

This scheme of work will no longer allow the use of hooks in your logic, but with $mol_wire, hooks are like a dog’s fifth leg.

It's easier to understand how it works with specific examples, so let's create a simple component - a text input field:

```ts
export class InputString extends Component<InputString> {
		
	// statefull!
	@mem value( next = "" ) {
		return next;
	}
		
	change( event: ChangeEvent<HTMLInputElement> ) {
		this.value( event.target.value )
		this.forceUpdate() // prevent caret jumping
	}
	
	compose() {
		return (
			<input
				id={ this.id }
				className="inputString"
				value={ this.value() }
				onInput={ action(this).change }
			/>
		)
	}
		
}
```

Here we have declared a state in which the entered text is stored by default, and the action causes the update of this state to be called upon input. At the end of the action, we force ReactJS to instantly pick up our changes, otherwise the caret will fly away at the end of the input field. In other cases this is not necessary. Well, when passing the action to VDOM, we wrapped it in a wrapper that simply turns a synchronous method into an asynchronous one.

Now let's use this component in the number input field, in which we will raise the text of the status input field:

```ts
export class InputNumber extends Component<InputNumber> {
	
	// self state
	@mem numb( next = 0 ) {
		return next;
	}

	dec() {
		this.numb(this.numb() - 1);
	}

	inc() {
		this.numb(this.numb() + 1);
	}
	
	// lifted string state as delegate to number state!
	@mem str( str?: string ) {
		
		const next = str?.valueOf && Number(str)
		if( Object.is( next, NaN ) ) return str ?? ""

		const res = this.numb( next )
		if( next === res ) return str ?? String( res ?? "" )

		return String( res ?? "" )
	}

	compose() {
		return (
			<div
				id={this.id}
				className="inputNumber"
				>
			
				<Button
					id={ `${this.id}-decrease` }
					action={ ()=> this.dec() }
					title={ ()=> "➖" }
				/>

				<InputString
					id={ `${this.id}-input` }
					value={ next => this.str( next ) } // hack to lift state up
				/>

				<Button
					id={ `${this.id}-increase` }
					action={ ()=> this.inc() }
					title={ ()=> "➕" }
				/>
						
			</div>
		)
	}
		
}
```

Please note that we have overridden the `value` property of the text input field, so now it will store its state not in itself, but in our `str` property, which is actually a cached delegate to the `numb` property. Its logic is a little convoluted so that when an invalid number is entered, we do not lose user input due to its replacement with a *normalized* value.

You can notice that the VDOM we generated does not depend on any reactive states, which means it will be calculated only once during the first render, and will not be updated again. But despite this, the text field will respond correctly to changes in the `numb` properties. and as a consequence `str`.

The `Button` components are also used here. which have overridden methods called to get the name of the button and to perform an action when clicked. But more about buttons later, but for now let’s use all our developments to implement an advanced `Counter`, which not only switches the number with buttons, but also downloads data from the server:

```ts
export class Counter extends Component<Counter> {
	
	@mem numb( value = 48 ) {
		return value
	}

	issue( reload?: "reload" ) {
		return GitHub.issue( this.numb(), reload )
	}

	title() {
		return this.issue().title;
	}

	link() {
		return this.issue().html_url;
	}

	compose() {
		return (
			<div
				id={ this.id }
				className="counter"
				>
				
				<InputNumber
					id={ `${this.id}-numb` }
					numb={ next => this.numb( next ) } // hack to lift state up
				/>

				<Safe
					id={ `${this.id}-output-safe` }
					task={ () => (
						
						<a
							id={ `${this.id}-link` }
							className="counter-link"
							href={ this.link() }
							>
							{ this.title() }
						</a>
						
					) }
				/>

				<Button
					id={ `${this.id}-reload` }
					action={ () => this.issue("reload") }
					title={ () => "Reload" }
				/>
						
			</div>
		)
	}
		
}
```

As it is not difficult to notice, we have raised the state of the text input field even higher - now it operates with the number *issue*. Using this number, we load the data via the GitHub API and display it side by side, wrapped in a special component `Safe`, whose task is to handle exceptions in the code passed to it: when waiting, show the corresponding indicator, and in case of an error, show the error text. It is implemented simply - with the usual `try-catch`:

```ts
export abstract class Safe extends Component<Safe> {
		
	task() {}
	
	compose() {
			
		try {
			return this.task()
		} catch( error ) {
				
			if( error instanceof Promise ) return (
				<span
					id={ `${this.id}-wait` }
					className="safe-wait"
					>
					💤
				</span>
			)
	
			if( error instanceof Error ) return (
				<span
					id={ `${this.id}-error` }
					className="safe-error"
					>
					{error.message}
				</span>
			)
	
			throw error
		}
			
	}
}
```

Finally, let’s implement a button, but not a simple one, but a smart one that can display the status of the task being performed:

```ts
export class Button extends Component<Button> {
		
	title() {
		return ""
	}
	
	action( event?: MouseEvent<HTMLButtonElement> ) {}
	
	@mem click( next?: MouseEvent<HTMLButtonElement> | null ) {
		if( next ) this.forceUpdate()
		return next;
	}
	
	@mem status() {
			
		const event = this.click()
		if( !event ) return
	
		this.action( event )
		this.click( null )
		
	}
	
	compose() {
		return (
				
			<button
				id={this.id}
				className="button"
				onClick={ action(this).click }
				>
					
				{ this.title() } {" "}
					
				<Safe
					id={ `${this.id}-safe` }
					task={ () => this.status() }
				/>
					
			</button>
				
		)
	}
		
}
```

Here, instead of immediately launching the action, we put the event in the reactive property `click`, on which the `status` property depends, which is already responsible for launching the event handler. And so that the handler is called immediately, and not in the next animation frame (which is important for some JS APIs like `clipboard`), `forceUpdate` is called. Himself `status` in normal situations it does not return anything, but in case of a wait or an error it shows the corresponding blocks thanks to `Safe`.

All the code for this example can be found in [sandbox](https://codesandbox.io/s/vigorous-lederberg-b53uc?file=/src/Counter.tsx):

![](https://i.imgur.com/cItcuRn.png)

Logs have also been added there so you can understand what is happening. For example, this is what the primary rendering looks like:

	render #counter 
	render #counter-numb 
	render #counter-numb-decrease 
	render #counter-numb-decrease-safe 
	render #counter-numb-input 
	render #counter-numb-increase 
	render #counter-numb-increase-safe 
	render #counter-title-safe 
	render #counter-reload 
	render #counter-reload-safe 
	
	fetch GitHub.issue(48) 
	render #counter-title-safe 
	render #counter-title-safe

Here `#counter-title-safe` was rendered 3 times because first it showed 💤 on *debounce*, then while waiting for the data to actually load, and at the end it showed the loaded data.

When you press `Reaload` again, nothing unnecessary is rendered - only the wait indicator on the button changes, since the data ultimately did not change:

```
render #counter-reload-safe

fetch GitHub.issue(48)
render #counter-reload-safe
render #counter-reload-safe
```

Well, when you quickly change the number, the text input field is updated and the heading that depends on it is displayed:

```
render #counter-numb-input
render #counter-title-safe

render #counter-numb-input
render #counter-title-safe

fetch GitHub.issue(4)
render #counter-title-safe
render #counter-title-safe
```

In total, what problems we solved:

- ✅ The component automatically tracks external states pointwise (not like with Redux).
- ✅ Component parameters are updated without rerendering the parent.
- ❌ Component movement is still controlled by ReactJS.
- ✅ Changing the callback does not lead to rerendering.
- ✅ Our analogue of hooks can be used anywhere in the code, even in loops and conditions.
- ❌ Error handling is still managed by ReactJS, so it requires manual work.
- ✅ For a partial update, you can create a component that accepts a closure.
- ✅ stateful components are fully controlled.

You can modify this example and design it as a library like [remol](https://github.com/zerkalica/remol) if you are ready to support it. Or implement similar integration for any other framework. In the meantime, we are undocking the first stage and flying even higher...