RFC: Hooks

[thysultan]

Similar to React Hooks. RFC discussion.

The differences being

1. The use of a single setter/getter stream instead of a tuple. So value = use(value) instead of [value, setValue] = use(value). This allows us to use live values to avoid the age old problem of stale data. That is value() would always return the current value.
2. The unification of hooks and effects into a single use API. i.e use(value) and use(value, callback) instead of useState and useEffect.
3. Support for unmount animations as can be archived with componentWillUnmount. Without which hooks wouldn't have full feature parity with lifecycle methods.
4. ...and passing [dependencies], props, state, context to the effect callback to effectively avoid being tied to closures.

An example of the aforementioned might look like the following:

import {h, use, render} from 'dyo'

function Counter (props, {refs, value = use(0)}, context) {
	try {
		return h('div', {ref: refs},
			h('button', {onClick: e => value(value + 1)}, '+'),
			h('button', {onClick: e => value(value - 1)}, '-'),
			h('h1', {}, value)
		)
	} finally {
		useAnimation(value)
	}
}

function useAnimation (value) {
	return use([value], ([value], props, {refs}, context) => {
		return () => {
			return refs.current.animate([], {}).finished
		}
	})
}

Point 3 arises the question of how do we handle the case when multiple effects try to register unmount animations: Do we 1. Register all the animations? or 2. Register the last animation?

[mcjazzyfunky]

@thysultan Really great that you are planning to add a hook API to Dyo. Thanks.

Just a comment to point 1:
You know, in the past, I've always been a fan of that setter/getter streams.
But frankly, now, I'm not really sure any longer, whether this really solves more problems that it causes trouble/confusion.

Please see the following example:

// React - everythings completely understandable here
function Counter(props) {
  const
    [count, setCount] = useState(0),
    { label, onChange } = props,
    prevLabel = usePrevious(label),
    prevOnChange = usePrevious(onChange),
    prevProps = usePrevious(props),
    prevCount = usePrevious(count)
    ...
}

function usePrevious(value) {
  const ref = useRef()

  useEffect(() => {
    ref.current = value
  })

  return ref.current
}

// Dyo - things are a bit confusing here, I think...
function Counter(props) {
  const
    count = use(0)
    { label, onChange } = props,
    prevLabel = usePrevious(label),
    prevOnChange = usePrevious(onChange), // onChange is a function
    prevProps = usePrevious(props),       
    prevCount = usePrevious(count)        // count is a function
    ...

  // Some confusing things
  // * "count" is a function - is "prevCount" is a number or a getter function?
  //   You cannot guess the type of a value by its name any longer.
  // * How can "usePrevious" know that "onChange" is a function
  //   which shall be treated as a value while "count" is a function
  //   which shall be treated as a getter function? Means, "usePrevious" is
  //   not as easy to write and not as easy understandable as in React...
  //   Of course you can just use: prevCount = usePrevious(count()) ... but still confusing...
}
 

[thysultan]

@mcjazzyfunky From the example i can't pin point in what context this would be a problem. Can you elaborate? i.e how are you using the values, and how is this different from React.

As an aside if for example use(use(0)) returned the passed value. Could rewriting usePrevious return to return use(ref.current)() establish the guarantee that it always returns a value regardless of the type?

In addition, assuming the tuple approach [value, setter]. How would you avoid stale data given the move towards a more async world with suspense et-al, and how would you pass this onto effects(regarding point 4).

As it stands dependencies are single live values so ([a, b, c], props, state, context) doesn't feel too off compared to ([[a, setA], [b, setB], [c, setC]], props, state, context), or is the premise of passing the dependencies as arguments to the callback not the right direction?

My reasoning was that this would widen the breath of compostability afforded to effects in addition to the aforementioned note about closures in point 4.

[mcjazzyfunky]

@thysultan Like I've said I'm just "not really sure" ... maybe my concerns are a bit overstated.
Just saying if you have a variable "count" at a certain point within the render function then with React you normally know the type of that variable without having to look at the previous code or using some IDE tooltips ... in Dyo you would not know whether it is a number, a getter or a getter-setter-hybrid.
But this is not a showstopper of course (libs like "knockout" or "flyd" use a similar syntax and nobody has problems with it there).

But what's really a bit odd in my opinion is the following: Let's say again at a certain point in the render function you have that variable"count". If it comes from "use" it's a stream if it comes from "props" it's a number. Should the source of data really be THAT important (different types depending whether it comes from state, from props or from context)? If the data source is state than you do NOT have that "stale data" problem and you can pass the data stream easily to async functions. But if the data source is "props" or context then your STILL have that "state data" problem and cannot pass the data that easily to async functions, am I wrong? (maybe some "useStream(...)" hook could be a solution).

But really no need for a larger discussion just because of that "value vs getter/setter-stream" thing ... if you use "getter/setter-streams", I'm fine with that of course 😃

Regarding that depenency callback argument at point 4: Type inference support will not be much fun in TypeScript/Flow with that "use" function, wil it?

[Zolmeister]

My experience with getter-setter functions (working with Mithril.js years ago) was poor.
I ran into 'variable naming confusion', where (like @mcjazzyfunky) mixing of getter-setters with regular variables leads to hard-to-follow code.
Special-naming (e.g. var -> varProp) solves it, but looks ugly

1. based on the above, I disagree with this move
2. My (toy) examples so far do not use parameters for useEffect, therefore the extra first parameter (from merging with useState) is useless (I'd predict mostly null)
3. no comment
4. seems harmless (doubt I'll use them)

I'd like to note that useEffect should not run server-side (#86)

[thysultan]

Regarding that dependency callback argument at point 4: Type inference support will not be much fun in TypeScript/Flow with that "use" function, will it?

You could type define it as:

interface Use<T, Props = {}, State = {}, Context = {}> {
    (value: T, callback?: (Value<T>[], Props, State, Context): (void | (): Promise<any>))
}

My (toy) examples so far do not use parameters for useEffect, therefore the extra first parameter (from merging with useState) is useless (I'd predict mostly null)

@Zolmeister Yes, React uses the second argument to signal dependencies, where implicitly it is an empty array(no dependencies). In contrast this forces you to explicitly mention dependencies if there are any, which is either a pro(is explicit) or con(is explicit?) depending on what you want to do.

I'd like to note that useEffect should not run server-side.

I agree.

[Zolmeister]

I can also see benefits to re-ordering the arguments for useEffect (e.g. lodash/fp)

Instead of merging useEffect/useState, how about useState/useMemo?

Edit: ah, I take it back useMemo returns a value, not a tuple. I'm starting to see the value of having separate methods here (akin to map, filter, reduce, but for hooks)

[thysultan]

I agree overloading use might not be a good idea considering there maybe more use* hooks in the future like useBoundary in addition/akin to useContext specifically for errors handling etc.

Basic Hooks

• useState
• useEffect
• useContext

Additional Hooks

• useReducer (Do we need this?)
• useCallback (Do we need this initially?)
• useMemo (Do we need this initially?)
• useRef (Do we need this considering we can just use any object i.e ref = {})
• useImperativeMethods (Borderline useEffects, can we merge into useEffect)
• useLayoutEffect (Borderline useEffects, can we merge into useEffect)

[Zolmeister]

• useReducer probably not
• useCallback probably not
• useMemo, definitely need this
  • Everything that you would previously have put into a constructor, you should put here (to avoid expensive calculations)
• useRef probably not, useState({current: null}) seems equivalent
• no preference
• no preference

[thysultan]

I think we can ship the following primary and secondary hooks:

Primary

• useState
• useMemo
• useEffect
• useLayout
• useContext
• useBoundary

Secondary

• useRef
• useReducer
• useCallback

It's debatable whether we should include useCallback, it does though have uses that cannot be mimicked with useMemo.

All of the above are implemented in the hooks branch.

[mcjazzyfunky]

@thysultan What about useImperativeHandle (fka useImperativeMethods)? Somewhere above you've mentioned: "[...] can we merge into useEffect [...]".
In React you need forwardRef (which is not available in Dyo) if you want to use useImperativeHandle.

[thysultan]

I was mistaken as to it's purpose, that said useImperativeHandle looks niche. Is there any general use case for it beyond decorating refs ref.current handle?

...The function served by forwardRef is the default behaviour as of the hooks branch, exposing a forwardRef API would be for the most part sugar we can avoid. The same is true for React.lazy in contrast to Dyo's first-class support for thenables and consequently dynamic imports.

[mcjazzyfunky]

I think focus() is a common example for useImperativeHandle (see https://reactjs.org/docs/hooks-reference.html#useimperativehandle).
Another example may be a usual DateField component which opens a calendar sheet to select the date by mouse click. Whether the calendar sheet is shown or hidden is normally handled completely by the DateField component itself. Nevertheless there are use cases where you want to close the calendar sheet from outside. For this use cases it may be useful if the DateField component has a imperative method close() which can be called from outside.
Another example may be a table component that allows to select rows. Which rows are selected is handled completely internally. Nevertheless in some cases you want to unselect all rows from outside. In this case a imperative method unselectAllRows() may be useful.

[thysultan]

Interesting.

I think useRef is versatile enough as a primitive(at least in Dyo) that you can do this with the function initialiser pattern.

For example:

// Dyo
function FancyInput(props) {
  const ref = useRef(props => {
  	props.ref.current = {focus: () => ref.current.focus()}
  })

  return <input ref={ref} ... />
}

In React this would be the equivalent of.

// React
function FancyInput(props, ref) {
  const inputRef = useRef();
  useImperativeHandle(ref, () => ({
    focus: () => {
      inputRef.current.focus();
    }
  }));
  return <input ref={inputRef} ... />;
}
FancyInput = forwardRef(FancyInput);

Is there anything i'm missing?