DEV Community: tkow

Declarative and inferable types way in React Redux

tkow — Sat, 04 Mar 2023 13:25:01 +0000

Motivation

Recently I decided to replace partial redux asynchronous logics using thunk actions to useSWR.

Nowadays, we drives into frequently switching state management libraries as modern frontend development grows up. The speed's surprising and it's still going to be more sophisticated.

As it is, writing code declarative as long as possible is significant important to reduce costs to switch libraries.

This article describes how your code gets declarative when you use react-redux.

Where your code should be declarative

We often use @reduxjs/toolkit to manage redux, but you can use vanilla redux and react-redux, too. What's important in this situation is redux dispatchers behaves as if simple javascript functions because the former are redundant form compared to the latter. The dispatch looks enough declarative thanks to action type as long as dispatcher pattern stay main stream, but someday paradigm shift may come that you don't use any libraries have dispatcher pattern.
So, you should write dispatch as less as possible.

As my opinion, useSelector is enough declarative when your selector input can be replaceable by switching the selector function. The definition's desirable to be out of scope from React component and input it to useSelector as function reference.

Utility

As first, we ready utility type to map redux actions to normal javascript functions like followed by code. Add your redux state type for RootState Type to the code.

import { useSelector as _useSelector, useDispatch as _useDispatch } from 'react-redux'

import { ThunkDispatch, Action, bindActionCreators, ThunkAction, ActionCreatorsMapObject } from '@reduxjs/toolkit'

export const useSelector = <M>(state: (state: RootState) => M, equalityFn?: ((left: M, right: M) => boolean)): M => _useSelector<RootState, M>(
  state, equalityFn
)

export const useDispatch = <IAction extends Action>(): ThunkDispatch<RootState, any, IAction> => {
  return _useDispatch<ThunkDispatch<RootState, any, IAction>>()
}

type ThunkActionCreator<ReturnType, State, ExtraThunkArg, BasicAction extends Action> = (...args: any[]) => ThunkAction<ReturnType, State, ExtraThunkArg, BasicAction>

type BoundActionCreators<ActionCreators> = {
  [key in keyof ActionCreators]:
  ActionCreators[key] extends ThunkActionCreator<infer R, RootState, any, Action> ?
  (...args: Parameters<ActionCreators[key]>) => R :
  ActionCreators[key]
}

export const useBindActionCreators = <
  A extends Action,
  ActionCreators extends ActionCreatorsMapObject<A | ThunkActionCreator<any, RootState, any, Action>>
>(actionCreators: ActionCreators): BoundActionCreators<ActionCreators> => {
  const dispatch = _useDispatch<ThunkDispatch<RootState, any, A>>()
  return useMemo(() => {
    return bindActionCreators(actionCreators, dispatch)
  }, [actionCreators, dispatch]) as BoundActionCreators<ActionCreators>
}

These utility functions maps redux states and dispatchers to react requires props by useSelectors and useBindActionCreators. I recommend you should use bindActionCreators in React components because dispatch's desired as less as possible as it have been already described.

Examples

As first, see the examples you may notice it　has room for improvement. Given that, the file of path ex/react-redux includes above utility functions to infer types and the file of path user/actions includes thunk action's named fetchUser which fetches login user data and simple action's named setUser. Fetching data has id and name, and user state type is same.

import { useSelector, useDispatch, useState } from 'ex/react-redux'
import * as userActions from 'user/actions'

function NameInputExample () {
  const userName = useSelector((state) => state.userName)
  const dispatch = useDispatch()

  const onChange = (input) => {
    dispatch(userActions.setUserName(input.target.value))
  }

  const [initialized, setInitialized] = useState()

  useEffect(()=> {
    fetchUser().then(() => setInitialized(true) )
  }, [fetchUser])

  if(!initialized) return null

  return <input type="text" name="user_name" value={userName} onChange={onChange} />
}

It's reasonably simple, but you may notice it's not handy to replace onChange handler if you wants to switch logics to use libraries use no dispatcher pattern. The sample has only one function but, if you have many handlers which you use dispatch and
write directly the definition in the component, you must remove them all.

To avoid it, take the example rewritten.

import { useEffect } from 'react'
import { useSelector, useBindActionCreators } from 'ex/react-redux'
import * as userActions from 'user/actions'

const userNameSelector = (state) => state.userName

function NameInputExample () {
  const userName = useSelector(userNameSelector)
  const { setUserName, fetchUser } = useBindActionCreators(userActions)

  const onChange = (input) => {
    setUserName(input.target.value)
  }

  const [initialized, setInitialized] = useState()

  useEffect(()=> {
    fetchUser().then(() => setInitialized(true) )
  }, [fetchUser])

  if(!initialized) return null

  return <input type="text" name="user_name" value={userName} onChange={onChange} />
}

This code becomes declarative now about the selector and the handler logic. All you need only to replace return values

of useBindActionCreators to change setUserName logic and you don't need change login in component. This example is great enough, but it'll be more declarative because useSelector and useBindActionCreators still has derived from redux.

Advance Examples

From this section, I introduce some tips how to write declarative code. So, you can pick them if you like my ideas.

Similar react useState form

If your need state and the modifier are always pairs, its' convenient you imitate your custom hook on useState.

import { useSelector, useBindActionCreators } from 'ex/react-redux'
import * as user from 'user/actions'

const userNameSelector = (state) => state.userName

const useUserNameState = () => {
  const userName = useSelector(userNameSelector)
  const { setUserName } = useBindActionCreators(user)
  return [userName, setUserName]
}

const useInitialization = () => {
  const { fetchUser } = useBindActionCreators(user)
  const [initialized, setInitialized] = useState()
  useEffect(()=> {
    fetchUser().then(() => setInitialized(true) )
  }, [fetchUser])
  return initialized
}

function NameInputExample () {
  const [userName, setUserName] = useUserNameState()

  const onChange = (input) => {
    setUserName(input.target.value)
  }

  const initialized = useInitialization()

  if(!initialized) return null

  return <input type="text" name="user_name" value={userName} onChange={onChange} />
}

This advantage is easy to replace it useUserNameState to useState.

Similar MVVM form

I recommend to map values to your props via object like instance value. It may looks connect utility function in redux. Furthermore, if you are familiar to object-oriented programming, you notice the values in custom hooks are similar to private variables and exported some of them are getters, and the export methods are public methods.
If you understand this analogy, you can write clean code.

import { useSelector, useBindActionCreators } from 'ex/react-redux'
import * as user from 'user/actions'

const userNameSelector = (state) => state.userName

const useMapProps = () => {
  const userName = useSelector(userNameSelector)
  const {setUserName} = useBindActionCreators(user)
  return {
    userName, 
    setUserName
  }
}

function NameInputExample (props) {
  const {userName, setUserName, fetchUser } = useMapProps(props)

  const onChange = (input) => {
    setUserName(input.target.value)
  }

  const [initialized, setInitialized] = useState()

  useEffect(()=> {
    fetchUser().then(() => setInitialized(true) )
  }, [fetchUser])

  if(!initialized) return null

  return <input type="text" name="user_name" value={userName} onChange={onChange} />
}

This advantage is to capsulize not used values and statements in react component and easy to replace it to instance (including singleton) or any other. Its' very flexible.

About other model

Though it's of course possible you arbitrary how you map your values to your components. I don't recommend nest object mapping or separated state and handler scope. The former make hard to improve rendering performance because you need to compare references for that and they often become more complicated than immutable values.The reason of the latter is you often see that the handers depends on the state's values. Sometimes you are inevitable to mix side effects in your custom hooks or mess up codes for some reasons like deadline comes near. When you're in the situation, the patterns in this article can't be applied entirely in your projects. What is important is to understand how wide you will need to replace codes and how certain to the extent you need declarative codes.

Conclusion

You can use fully type inferences for useSelector and useDispatch with bindActionCreators introduced by this article.
I recommend to map redux logics to simple js functions as long as possible before starting to use them in a React Component if you use redux.

What's the best way migrates state to outside of component on React?

tkow — Thu, 13 Oct 2022 07:25:25 +0000

We often make ui with control show/hidden like below a slider of pseudo code.

// Omitting import 
export default function SliderShowButton(props: SliderShowButtonProps) {
  const [showSlider, setShowSlider] = useState(false)
  const toggleSlider = useCallback(() => {
    setShowSlider((state) => !state)
  }, [])

  return (
    <ButtonContainer>
      <SliderShowButtonStyle title="Font" value={'Font'} onClick={toggleSlider}>
        <Icon name="font" size={20} />
      </SliderShowButtonStyle>
      {showSlider && (
        <Slider value={props.value} onChangeSize={props.onChangeSize} />
      )}
    </ButtonContainer>
  )
}

First, we expect it's enough to control that clickable button that toggles show/hidden inside the component. However, we will often desire to toggle it in the other place. For example, we may want it's forced to be hidden slider at body click-event.

In this case, the above code will be needed rewritten, but many ways to do so and we often consider "what's the best?".
I'll suppose several ways in this article, but there're tradeoff and weak points in any of them. So, if you know more wonderful way, let me know it.

1. Up internal state to parent, and pass them to props

Simplest and convenient way to do so. And we recommend first if the component is reusable in many place.

Pros

intuitive
shared states' scope is obvious

Cons

control do as like not stable(show/hide logic is stable against button click but it makes it abstract), but this is avoidable by setting the default state and modifier(though it's a use subtle useless memory capacity if you don't use them)
If many components do so, scope of top parent has many trivial states and props relay.
you may need to rewrite all components using the slider to inject state (It is avoidable to duplicate and keep the old component or default logic like example)

Example

// Omitting import 

type SliderShowButtonProps = {
  value: number
  onChangeFontSize: (fontSize: number) => void
  showSlider?: boolean
  setShowSlider?: (flg: boolean) => void
}

export default function SliderShowButton(props: SliderShowButtonProps) {
  const _default = useState(false)
  const [ showSlider = _default[0], setShowSlider = _default[1] ] = [props.showSlider, props.setShowSlider]
  const toggleSlider = useCallback(() => {
    setShowSlider(!showSlider)
  }, [showSlider, setShowSlider])

  return (
    <ButtonContainer>
      <SliderShowButtonStyle title="Font" value={'Font'} onClick={toggleSlider}>
        <Icon name="font" size={20} />
      </SliderShowButtonStyle>
      {showSlider && (
        <Slider value={props.value} onChangeSize={props.onChangeSize} />
      )}
    </ButtonContainer>
  )
}

// parent
function Parent() {
  const [showSlider, setShowSlider] = useState(false)

  useEffect(() => {
    setShowSlider(false)
  }, [someHook])

  return (
    <ParentContainer>
      <SliderShowButton showSlider={showSlider} setShowSlider={setShowSlider} />
    </ParentContainer>
  )
}

2. Context

This is also recommended way, if you can understand where the context is used in all the components. And best way as I thought if you need to ready for the unexpected extension.

Pros

intuitive
reusable in wide scope not only parent
reduce passing props and state definitions from parent.

Cons

you should extract presentational components and insert provider　into each using slider component, otherwise unclearly share states.
shared states' scope is unclear little (you can avoid this by file structure)
you may need to add all components using the slider to inject Provider.

Example

// Omitting import 

type SliderContext = {
  showSlider: boolean
  setShowSlider: (flg: boolean) => void
}

const SliderContext = createContext<SliderContext({} as SliderContext)

type SliderShowButtonProps = {
  value: number
  onChangeFontSize: (fontSize: number) => void
  showSlider?: boolean
  setShowSlider?: (flg: boolean) => void
}

// you may keep to export as presentational component
function SliderShowButton(props: SliderShowButtonProps) {
  const [ showSlider, setShowSlider ] = [props.showSlider, props.setShowSlider]
  const toggleSlider = useCallback(() => {
    setShowSlider(!showSlider)
  }, [showSlider, setShowSlider])

  return (
    <ButtonContainer>
      <SliderShowButtonStyle title="Font" value={'Font'} onClick={toggleSlider}>
        <Icon name="font" size={20} />
      </SliderShowButtonStyle>
      {showSlider && (
        <Slider value={props.value} onChangeSize={props.onChangeSize} />
      )}
    </ButtonContainer>
  )
}

export function Provider({ children }: { children: ReactElement }) {
  const [showSlider, setShowSlider] = useState(false)
  return (
    <SliderContext.Provider value={{ showSlider, setShowSlider }} />
      {children}
    </SliderContext.Provider>
  )
}

export default function (
  props: Omit<FontButtonProps, 'showSlider' | 'setShowSlider'>,
) {
  const { showSlider, setShowSlider } = useContext<SliderContext>(SliderContext)
  return (
    <SliderShowButton
      {...props}
      showSlider={showSlider}
      setShowSlider={setShowSlider}
    />
  )
}

// parent
function Parent() {
  const [showSlider, setShowSlider] = useContext(SliderContext)
  useEffect(() => {
    setShowSlider(false)
  }, [someHook])
  return (
    <ParentContainer>
      <SliderShowButton />
    </ParentContainer>
  )
}

export default function () {
  return (<Provider><Parent /></Provider>)
}

3. Ref

Ref is intuitive, if callback is idempotent. If its' not, it's very confused so, use this pattern carefully. But, if interface is pretty concise, it's used like class instance and convenient in some cases.

Pros

arbitrary bring state and function outside scope
intuitive if you use it like class instance
in most cases, you need to revise just only slider component to keep compatibility

Cons

forwardedRef and ref may make your code dirty or more writing codes
control become more tough if ref method has side effect or depends on processing order
if other components have many refs, parent have many refs

Example

// Omitting import 

type SliderShowButtonProps = {
  value: number
  onChangeFontSize: (fontSize: number) => void

}

const SliderShowButton = forwardedRef(function (props: SliderShowButtonProps, ref) {
  const [ showSlider, setShowSlider ] = useState(false)
  const toggleSlider = useCallback(() => {
    setShowSlider((state) => !state)
  }, [])


  useImperativeHandle(ref, () => ({
    setShowSlider: setShowSlider
  }));


  return (
    <ButtonContainer>
      <SliderShowButtonStyle title="Font" value={'Font'} onClick={toggleSlider}>
        <Icon name="font" size={20} />
      </SliderShowButtonStyle>
      {showSlider && (
        <Slider value={props.value} onChangeSize={props.onChangeSize} />
      )}
    </ButtonContainer>
  )
}

export default SliderShowButton

// parent
function Parent() {
  const ref = useRef<{
    setShowSlider: (flg: boolean) => void
  }>
  useEffect(() => {
    ref.current.setShowSlider(false)
  }, [someHook])
  return (
    <ParentContainer>
      <SliderShowButton ref={ref} />
    </ParentContainer>
  )
}

export default function () {
  return (<Provider><Parent /></Provider>)
}

4. useEffect(Not recommended, should avoid this if possible)

Intuitively, you think useEffect can watch props and synchronize internal state with it as first. But, this is a bad idea. The reason is that the state can be synced to props
value but the opposite is allowed means two-way binding. Two-way binding causes many serious bug like infinite loop or chaos control of simultaneous events. In addition, useEffect function is called after mount component event, then setState trigger re-rendering so it results redundant process. Thus you should avoid this pattern as possible.

Pros

less code to keep compatibility

Cons

it may cause two-binding and dangerous and obscure bug
it render twice props change of outer side.
need to add passing props from parent

// Omitting import 

type SliderShowButtonProps = {
  value: number
  onChangeFontSize: (fontSize: number) => void
  showSlider?: boolean
}

export default function SliderShowButton(props: SliderShowButtonProps) {
  const _default = useState(false)
  const [ showSlider, setShowSlider ] = [props.showSlider, props.setShowSlider]
  const toggleSlider = useCallback(() => {
    setShowSlider(!showSlider)
  }, [showSlider, setShowSlider])

  useEffect(() => {
    if(props.showSlider !== showSlider) {
      setShowSlider(props.showSlider)
    }
  })

  return (
    <ButtonContainer>
      <SliderShowButtonStyle title="Font" value={'Font'} onClick={toggleSlider}>
        <Icon name="font" size={20} />
      </SliderShowButtonStyle>
      {showSlider && (
        <Slider value={props.value} onChangeSize={props.onChangeSize} />
      )}
    </ButtonContainer>
  )
}

// parent
function Parent() {
  const [showSlider, setShowSlider] = useState(false)

  useEffect(() => {
    setShowSlider(false)
  }, [someHook])

  return (
    <ParentContainer>
      <SliderShowButton showSlider={showSlider} />
    </ParentContainer>
  )
}

In the above example, you may think why you don't set showSlider and props.showSlider as deps. Even if you set them, if local showSlider change first and it doesn't sync props.showSlider as like the above example, it can't force to change local showSlider with same props.showSlider value because useEffect judge it's not changed value. So, effect function call every time which tends to bug. So this pattern should be avoided if possible.

5. Key prop(only available in specific case)

In special case if you want just only re-initialize
the component. Changing key prop another value.
See the detail of official doc. If slider always hidden in ancestor's events trigger and it's initialized state, we can use this.

Pros

less code to keep compatibility

Cons

its' not used if need effects depends on state.
not intuitive if anyone don't know the key prop feature.

Example

// parent
function Parent() {
  const [resetKey, setReset] = useState(uuid())

  useEffect(() => {
    setReset(uuid())
  }, [someHook])

  return (
    <ParentContainer>
      <SliderShowButton key={resetKey} />
    </ParentContainer>
  )
}

Conclusion

I recommend the 1st, 2nd, 3rd ways in order, and to avoid 4th way. If you need only to reset component 5th way is available. If you know other ways, I'm glad to let me know it. Thank you for reading!

Nodejs Cloud Functions args and response Type Generator from backend

tkow — Thu, 26 May 2022 12:56:49 +0000

What is this article

Introduction of my firebase-function-client-type-gen library.

Summary

If you use cloud functions for firebase, you create client using httpsOnCallable. This api accept args and response type as type parameters of typescript.

However, the synchronization of request and response parameters with backend normally is not supported. This library resolve this having constraint of firebase function definition way.

Explanation

My library extract Arg and Response type using their type alias name and the function name using Typescript compiler API, then import whole firebase functions definition object from your entry point of actual deployment.

Given if you have nested function definition object as your entry point, For example,

import * as functions from 'firebase-functions'

// You define two types in function definition file and they must be in a file include function declaration.
type RequestArgs = {
    id: string
}
type ResponseResult = {
    result: 'ok' | 'ng'
}

// You must export "only one const https onCall" in a file.
// If you export many httpsOnCall functions, it may happen unexpected result when mapping args and result types.'
const includeTest = functions
    .region('asia-northeast1')
    .runWith({
        memory: '1GB'
    })
    .https.onCall((data: RequestArgs, _): ResponseResult => {
        return {
            result: 'ok'
        }
    })

export const nameSpace = {
    includeTest
}

Some firebase API run code at top level scope, so they must be mocked. If you have other run code at top level scope, and if it cause error at runtime, they also must be mocked. Look at the followed by an example. I recommend proxyquire as injection mock to your code and using it at this example. Mock may be like that.

export const DUMMY_MOCKS = new Proxy<any>(
    () => DUMMY_MOCKS,
    {
        get(_, __): any {
            return DUMMY_MOCKS
        }
    }
)

export const MOCKS_BASE = {
    'firebase-functions': {
        region() {
            return DUMMY_MOCKS
        },
        config: () => {
            return {
            }
        },
        '@global': true,
        '@noCallThru': true
    },
    'firebase-admin': {
        apps: DUMMY_MOCKS,
        initializeApp: () => { return DUMMY_MOCKS },

        '@global': true,
        '@noCallThru': true
    },
}

export const MOCKS = new Proxy(MOCKS_BASE, {
    get(target, name) {
        const returnValue = target[name as keyof typeof MOCKS_BASE]
        return returnValue ?? DUMMY_MOCKS
    }
})

Then, locate your code generating command file.

import proxyquire from 'proxyquire'
import { MOCKS } from './mock'
import { outDefinitions } from 'firebase-function-client-type-gen'
import path from 'path'
import glob from 'glob'
import {EOL} from 'os'

const functionDefs = proxyquire('./functions/entrypoint.ts' ,Mocks)

// Get document, or throw exception on error
try {
  const sources = glob.sync(path.resolve(__dirname, './', 'functions/**/*.ts'))
  const result = outDefinitions(sources, namedFunctions, {
    symbolConfig: {
      args: 'RequestArgs',
      result: 'ResponseResult'
    }
  })
  console.log(result)
  console.log('named functions type generated' + EOL);
} catch (e) {
  console.error(e);
}

The symbolConfig can change your type alias name. Run this code using ts runtime environment like ts-node output should be followed by

export type FunctionDefinitions = {
    "includeTest": {
        args: { id: string; };
        result: { result: "ok" | "ng"; };
    };
};

export const functionsMap = {
    includeTest: "nameSpace-includeTest",
};

The output of course can be passed by fileWriter like fs.
You output it your application, then you can create automatic type-safe client if each functions have different regions.

import { getFunctions, httpsCallable, HttpsCallable } from 'firebase/functions'
import { getApp } from 'firebase/app'

type IFunctionDefnitions = {
    [key: string]: {
        args: any,
        result: any
    }
}

type HttpsCallableFuntions<FunctionDefnitions extends IFunctionDefnitions> = {
    [functionName in keyof FunctionDefnitions]: HttpsCallable<FunctionDefnitions[functionName]['args'], FunctionDefnitions[functionName]['result']>
}


type HttpsCallableFuntionIds<FunctionDefnitions> = {
    [functionName in keyof FunctionDefnitions]: string
}

export function initializeFunctions<FunctionDefnitions extends IFunctionDefnitions>(functionNameObject: HttpsCallableFuntionIds<FunctionDefnitions>, app = getApp(), region = 'us-east-1'): HttpsCallableFuntions<FunctionDefnitions> {
    const functions = getFunctions(app, region)
    const functionDefinitions = Object.entries(functionNameObject)
    return functionDefinitions.reduce((current, [functionName, functionId]) => {
        return {
            ...current,
            [functionName]: httpsCallable(functions, functionId)
        }
    }, {} as HttpsCallableFuntions<FunctionDefnitions>)
}

// At your entrypoint file, import generated types from your generated types file.
import { FunctionDefinitions, functionsMap } from './functions-types'
const client = initializeFunctions<FunctionDefinitions>(functionsMap)
// Fully type-safed api call functions.
client.callSomethingReuest({...args})

If you need to change region as basis as function, manually call const someCallable = httpsCallable(getFunction(getApp(), region), functionId) instead of initializeFunctions above.

That's all. Other features or some cautions are in Readme in my repository.

If you are interested in this library, feel free to ask me.

** Update **

I have picked regions from our client generator, so no longer needs to separate client function definitions.
Furthermore, we adapt simple type alias or interface pull reference types our output file.

Inner Hooks: New idea of React Hooks

tkow — Fri, 11 Feb 2022 10:53:10 +0000

Introduction

This post is about my idea recently came to my mind though it may be not completely original if I research all the way around.

It's not official concept from react dev teams or facebook. I'm　just a programmer from everywhere though a little experienced to some extent. So, my idea may not satisfy you but, I want to explain and discuss new concept about react hooks with everyone who is interested in it. I call it "Inner Hooks".

I experimentally make library following this concept. Here is my repository of it. And try it in playground if you want.

What is Inner Hooks

Inner Hooks idea makes just react-hooks available in a component's child scope by props passing.　Nothing more, nothing less.　My library realize by creating HOC.

Why I need this?

It'll be a rehash from my repository README document, but I explain the advantage. If you interested in this, please see also that.

At first, we should have written hooks before starting jsx description. For example, we couldn't write hooks between conditional rendered components like followed by an example because it violates rendering hooks rules about idempotent.

const Example = (props) => {
  const { initialized, data } = useFetchData();
  if (!initialized) return null;
  const options = useOptions();
  return <Component {...data} options={options} />;
};

This fact may annoy you if you come across excessive fat component. I show example you may feel so.

const Example = (props) => {
    const options = useOptions()
    const [optionValue, setOptionValue] = useState()
    const {initialized, data} = useFetchData()
    const someValue = ''
    const someChange = () => {}
    if (!initialized) return null
    return (
        <Component>
            <Child>
              <AnnoyedField
                value={someValue}
                onChange={someChange}
                class='test'
                otherProps
              />
              <AnnoyedField
                value={someValue}
                onChange={someChange}
                class='test'
                otherProps
              />
              <AnnoyedField
                value={someValue}
                onChange={someChange}
                class='test'
                otherProps
              />
              <AnnoyedField
                value={someValue}
                onChange={someChange}
                class='test'
                otherProps
              />
              <AnnoyedField
                value={someValue}
                onChange={someChange}
                class='test'
                otherProps
              />
              <AnnoyedField
                value={someValue}
                onChange={someChange}
                class='test'
                otherProps
              />
              <AnnoyedField
                value={someValue}
                onChange={someChange}
                class='test'
                otherProps
              />
              <Select
                value={optionValue}
                onChange={setOptionValue}
                options={options}
                otherProps
              />
              <AnnoyedField
                value={someValue}
                onChange={someChange}
                class='test'
                otherProps
              />
              <AnnoyedField
                value={someValue}
                onChange={someChange}
                class='test'
                otherProps
              />
            <Child/>
        </Component>
    )
}

It's written in declarative way, you still can read if you don't want. In real, the handler is possible arrow function and some amateur engineers may write long code directly without abstraction. If do so, it's tough to find scope of changing state effects or where state are derived from used in event handlers.

We once solved the problem using the container component to
inject concrete behaviors per loosely-coupled component like IOC(Inversion of Control) theory, but there is defect that to do this you need separate some children components from the parent. The alternative is react hooks can be mixed encapsulated logics and components in one component. But hooks can also have a weak point as having ever seen examples above.

Eventually, you'll find it might be better to separate hooks and presentational component like container layer as bigger it is though it can put them together to one component.

InnerHooks tackles this problem and realize it can completely encapsulate the business logic to one component in some cases.

For example, if you use Redux,

    <NumberInput
      innerHooks={() => {
        const num = useSelector(({num}) => { return num})
        const dispatch = useDispatch()
        return {
          value,
          onChange: (e) => {
            dispatch({type: 'mutateNum', payload: num})
          }
        }
      }}
    />

I realize that withInnerHooks api generate hoc add innerHooks prop are called in intermediate layer of hoc to inputed Component. The innerHooked returned value are merged with the other props specified from the component tag.

you write once this, you can use or move it another place everywhere with cut and paste. This is more convenient in some case than you obey strictly React's hooks rendering rules and declarative policy.

From my playground example, you can find they are loosely-coupled and separate independent logic

import "./styles.css";
import React, { useEffect } from "react";
import { useStateFactory, withInnerHooks } from "react-inner-hooks-extension";

function Child(props: any) {
  return (
    <div>
      <input type={props.type} onChange={props.onChange} value={props.value} />
    </div>
  );
}

function Text(props: any) {
  return <div>{props.value}</div>;
}

const NumberField = withInnerHooks(Child);
const StringField = withInnerHooks(Child);
const Timer = withInnerHooks(Text);

export default function App() {
  const [state, usePartialState, setState] = useStateFactory<{
    num: number;
    str: string;
    timer: number;
  }>({
    num: 1,
    str: "foo",
    timer: 0
  });

  return (
    <div className="App">
      <form
        onSubmit={(e) => {
          e.preventDefault();
          // dummy submit method
          const submit = console.log;
          submit(state);
          // RestState
          setState({
            num: 1,
            str: "foo",
            timer: 0
          });
        }}
      >
        <NumberField
          type="number"
          innerHooks={() => {
            const [value, setValue] = usePartialState("num");
            return {
              value,
              onChange: (e: any) => setValue(e.target.value)
            };
          }}
        />
        <StringField
          type="string"
          innerHooks={() => {
            const [value, setValue] = usePartialState("str");
            return {
              value,
              onChange: (e: any) => setValue(e.target.value)
            };
          }}
        />
        <input type="submit" value={"reset"} />
      </form>
      <Timer
        innerHooks={() => {
          const [value, setValue] = usePartialState("timer");
          // This is warned by linter but it can be used.
          useEffect(() => {
            const i = setInterval(() => {
              setValue((state: number) => state + 1);
            }, 1000);
            return () => {
              clearInterval(i);
            };
          }, []);
          return {
            value
          };
        }}
      />
      <div>current:{JSON.stringify(state)}</div>
    </div>
  );
}

In this example, each components enclose only the related logic in prop scope.

These can be written like as the container in declarative way . The difference is that you can determine how it behaves in
parent component scope.

const useHooksContainer = () => {
  const num = useSelector(({num}) => { return num})
  const dispatch = useDispatch()
  return {
    value,
    onChange: (e) => {
      dispatch({type: 'mutateNum', payload: num})
    }
  }
}

() => (
    <NumberInput
      innerHooks={useHooksContainer}
    />
)

Concern

Inner hooks look opposed to React declarative policy but though it can also be encapsulated and abstracted by custom hooks. And I think this feature should be equipped in React library itself or extend its render function as possible for more effective about performance and avoidance to repeat to write withInnerHooks hoc any where. If you use eslint with several react-hooks rules, this library violates some of them. So you may need to ignore them.

Wanted Your Opinions!

Please feel free to post your opinions in discussion. Thanks to read.

In Addition at 2022/02/17

Referencing this discussion, I could improve my library for our sake. Thank you for everyone who joins it!