React hooks style api

[intellild]

import { useRecoilValue, useRecoilCallback } from "recoil"

useRecoilValue(atom); // error

const App = () => {
  useRecoilValue(atom) // works as a React hook

  useRecoilCallback(() => {
    useRecoilValue(atom) // works under recoil context, but no subscription, since there no need to update the callback itself
  })

  // current api
  useRecoilCallback(({get}) => () => {
    get(atom) // we have to pass the `get` everywhere if we want to reuse code
  })
}

const hooksStyleAPI = () => {
  useRecoilValue(atom)
}
//vs
const someReusedFunction = (callbackInterface) => () => {
  callbackInterface.get(atom)
}

similar for selector:

selector({
  key: "selector",
  get() {
    const callback = useRecoilTransaction(() => {
      // begins a transaction
    })

    const currentAPI = getRecoilCallback(({transact}) => () => {
      transact(() => {
        // so many nested closures
      })
    })
  }
})

[drarmstr]

It would be illegal usage of hooks, based on React's rules, to use hooks outside of rendering in a callback like that.

[intellild]

It would be illegal usage of hooks, based on React's rules, to use hooks outside of rendering in a callback like that.

@drarmstr
They become Recoil hooks when used within Recoil's context. We can change hooks implementation for different contexts.
Just like React switch between mountHooks and updateHooks

const recoilHandler = {
  useRecoilValue() {
    // ...
  },
  useRecoilCallback() {

  }
}

const reactHandler = {
  useRecoilValue() {
    // ...
  },
  useRecoilCallback(fn) {
    return (...args) => {
      handler = recoilHandler
      fn(...args)
      handler = reactHandler
    }
  }
}

let handler = reactHandler

export function useRecoilValue() {
  handler.useRecoilValue()
}

export function useRecoilCallback() {
  handler.useRecoilCallback()
}

[drarmstr]

It's still against naming conventions and lint rules.

[intellild]

Sounds reasonable. But we can still use another naming convention to avoid nested closures.
Also, I think the store object should be exposed

selector('some controller', () => {
  const store = getCurrentStore()
  const callback = getCallback(async () => {
    await fetch()
    store.set(/* ... */)
  })
})

I believe this would be much cleaner

[drarmstr]

There are nuances here. For example, we actually implemented an approach like this where we could get an object with an interface that matched the hooks. The issues came when we think about the semantics of subscriptions. Using the methods during rendering would add subscriptions for consistency and to avoid mysterious inconsistencies for users. That was actually convenient in some cases, but meant we had to track dynamic number of subscriptions. When working with the latest React API for subscriptions that are safe with concurrent rendering the hooks don't lend themselves for a dynamic count of subscriptions. There are similar complications with subscriptions for an exposed store as well. What use case are you trying to unblock with exposing the store directly?

[intellild]

Thanks. I understand the issue.
I think it wouldn't be problems if these apis only available in callbacks and selectors and no subscriptions available
It would be more convenient for library authors
For example:

import { getRecoilValue } from "recoil"
import { queryAtom } from "recoil-relay/apollo"

queryAtom({
  key: "my-query",
  query: "",
  getVariables() {
    return {
      foo: getRecoilValue(somAtom)
    }
  }
})

this could avoid many confusing nested closures

[intellild]

Things like getRecoilValue may not be a good idea for async scenarios, so I thought the store object should be exported.
Actually it doesn't need to be the real store object, but a interface
For example:

const callback = getCallback(callbackInterface => {
  return () => {
    // ...
  }
})

vs

const callback = getCallback(() => {
  const callbackInterface = getRecoilInterface();
})
const transationCallback = getTranstionCallback(() => {
  getTranstion()
})