For example, the capacitorStorage is asynchronous.

And sometimes people may write their own storage adapter since useStorageAsync and useStorage allows custom storage interface as an argument.

I feel that exposing a then function to the ref might be more intuitive where users could also await for it.

It can be both:

const accessToken = await useStorageAsync('access.token', '', SomeAsyncStorage)

or

const accessToken = useStorageAsync('access.token', '', SomeAsyncStorage)

accessToken.then(() => {
  // ...
})

Maybe

accessToken.ready.then()

Some libraries use this way.

So is there any update? Do we need to change to the new pattern?

@antfu @OrbisK Sorry to bother but I think this function is required for peoples since there are some issues discussion about this feature.

If wee need more changes, please leave some messages or a final decision so that I can modify the code.

Currently there has no any workaround to solve the async initialize issue without this PR.

I feel that exposing a then function to the ref might be more intuitive where users could also await for it.

It can be both:

const accessToken = await useStorageAsync('access.token', '', SomeAsyncStorage)

or

const accessToken = useStorageAsync('access.token', '', SomeAsyncStorage)

accessToken.then(() => {
  // ...
})

It feels like using useFetch

const { isFetching, error, data } = await useFetch(url)

@asika32764 Sorry for the late reply. Would you be open to exploring how we could support something like this?

I implemented the Promise to the return value. But I still keep onReady options if someone needs it.

const accessToken = useStorageAsync('access.token', '', SomeAsyncStorage, {
  onReady(value) {
    // ...
  }
})

accessToken.value // Origin way, may be empty if storage not prepared

const resolvedToken = await accessToken

resolvedToken.value // Resolved, still needs a .value to get value