Class ComponentMethods<TProps, TState>

These methods will have access to the components state and props via this.state and this.props respectively.

Call the useMethods hook inside your function component to instantiate the class.

Type Parameters

  • TProps extends object = {}
  • TState extends TStateData | null = null

Constructors

Properties

props: TProps
state: TState extends TStateData ? TCleanState<TState<TState>> : null
_hmrPreserveKeys: (string & {} | (keyof ComponentMethods<TProps, TState>))[] = []

Specify custom class members to be copied over whenever the class is reinstantiated during hot module replacement.

Oore handles HMR by recreating the class instance with the updated code whenever there is a file change. Your component is then rerendered so that event handlers now point to the new functions.

For this to work well, your component's state needs to be preserved, so it is copied over from the old instance, to the newly created one. This includes state, props by default, but you can extend it to include more properties if there are values your component expects to be persistent.

In most case, any values you wish to preserve should be created React.useRef.

// In useHooks method:
this.inputId = useRef(inputId);
// And access anywhere with:
this.inputId.current;

If you use a ref in this way, React will preserve it for you, and there will be no need to use _hmrPreserveKeys.

_hmrPreserveKeys is only relevant in development and has not effect in production environment. Accordingly, you should only update this array when environment is development, so that it can be tree-shaken during production builds.

in addition to state, props, and hooks.

MyComponentMethods extends ComponentMethods {
// Some class member definitions...

constructor() {
if (process.env.NODE_ENV === 'development') {
this._hmrPreserveKeys.push('inputId', 'unsubscribeCallback');
}
}

// Method definitions...
}
With the above example, whenever HMR occurs, `this.inputId` and `this.unsubscribeCallback`
will maintain there existing values, while everything else will be recreated. Meanwhile,
because the code is written in an environment condition, it should be easy to strip it from the
production build to avoid shipping dead code
_onHmrUpdate?: <TInstance extends BaseClasses.ComponentMethods<TProps, TState>>(
    oldInstance: TInstance,
) => void

Handle complex update logic whenever your component instance is updated through HMR. The function is called on the new instance, and it receives the old instance as the only argument. So you can access data from the old instance, and reinitialize any processes on the new instance as needed.

_onHmrUpdate is only relevant in development and has not effect in production environment. Accordingly, you should only assign this function when environment is development, so that it can be tree-shaken during production builds.

MyComponentMethods extends ComponentMethods {
// Some class member definitions...

constructor() {
if (process.env.NODE_ENV === 'development') {
this._onHmrUpdate = () => {
// Your custom hmr logic here.
};
}
}

// Method definitions...