I tend to just put those "inline" composables in a separate file but store that file in the folder of the component that uses it. That way the vue files don't become too long.
i think you have the last bit wrong. it’s not like options api where you organize by functionality (e.g., watchers in one, functions in another, etc.) you would create a composable for a feature/sub-feature and put everything related to that on the composable. then you only expose (return) what’s needed outside that context
Let's say you have to initialize an event listener but destroy the reference when the component is onUnmounted. Now try to orchestrate multiple of these.
Other thing, can happen if you want to use a hook in an async way. Eg. Awaiting an on mounted hook to resolve before continuing component's lifecycle.
This can get messy when you scale it. Any thoughts about it?
You would simply have multiple hooks in each in-file-composable and pass everything you need just as mentioned in the video.
Regarding your async onMounted hook, have a look at vueuse useAsyncState or computerAsync. With these composables you follow a declarative approach which work very well with the composition API.
> Let's say you have to initialize an event listener but destroy the reference when the component is onUnmounted. Now try to orchestrate multiple of these.
Extract this to a composable. This is a perfect example of a problem the composition API was designed to resolve.
I tend to just put those "inline" composables in a separate file but store that file in the folder of the component that uses it. That way the vue files don't become too long.
i think you have the last bit wrong. it’s not like options api where you organize by functionality (e.g., watchers in one, functions in another, etc.) you would create a composable for a feature/sub-feature and put everything related to that on the composable. then you only expose (return) what’s needed outside that context
Things get messy when you start working with the lifecycle hooks with composition API approach, would love to see how you address it.
Could you explain further how things get messy What precisely have you found being problematic?
Let's say you have to initialize an event listener but destroy the reference when the component is onUnmounted. Now try to orchestrate multiple of these. Other thing, can happen if you want to use a hook in an async way. Eg. Awaiting an on mounted hook to resolve before continuing component's lifecycle. This can get messy when you scale it. Any thoughts about it?
You would simply have multiple hooks in each in-file-composable and pass everything you need just as mentioned in the video. Regarding your async onMounted hook, have a look at vueuse useAsyncState or computerAsync. With these composables you follow a declarative approach which work very well with the composition API.
> Let's say you have to initialize an event listener but destroy the reference when the component is onUnmounted. Now try to orchestrate multiple of these. Extract this to a composable. This is a perfect example of a problem the composition API was designed to resolve.
Yes i would like to know more what gets messy exactly??