Open cpreston321 opened 10 months ago
@cpreston321 This is really great news! Are you still planning to keep the v-motion
presets? This is one of the most useful parts of this library like adding in quick fade type animations..
The main aspect I really like about this library is how flexible the useMotion
composible is for more complex animations.. However the major bug of this entire package functionality wise is this issue. Essentially elements that are in the immediate viewport do not acknowledge the motion properties for whatever reason. The current workaround is to use the useMotion
composable within an onMounted
hook.
The following example is for a consecutive spring animation used within a motionItems
v-for loop:
// Media DOM refs
const motionItems = ref(null)
// Animation
const animate = (i) => ({
initial: {
y: 30,
opacity: 0
},
visibleOnce: {
y: 0,
opacity: 1,
transition: {
type: 'spring',
delay: 75 * i
}
}
})
// Init animation w/ useMotion
onMounted(() => {
const items = motionItems.value
if (items) {
items.forEach((item, i) => {
useMotion(item, animate(i))
})
}
})
Regarding automation and npm releases, I think adding/publishing a @vueuse/motion-edge
or @vueuse/motion-nightly
package automatically based on the last commit on main
would be useful. This can be used to confirm issues have been resolved and if users want to use merged changes that haven't been published yet (though don't mind the release being potentially unstable).
Also adding issue template for bugs and feature requests could make issue triage easier. (I'll see when I have time to open a PR for this)
Regarding automation and npm releases, I think adding/publishing a
@vueuse/motion-edge
or@vueuse/motion-nightly
package automatically based on the last commit onmain
would be useful. This can be used to confirm issues have been resolved and if users want to use merged changes that haven't been published yet (though don't mind the release being potentially unstable).
I like @vueuse/motion-nightly
a lot of other pkgs follow this namespace.
Also adding issue template for bugs and feature requests could make issue triage easier. (I'll see when I have time to open a PR for this)
Agreed ๐ฏ I've been following Nuxt's issue template of most of my projects but we can come up with something similar.
@cpreston321 This is really great news! Are you still planning to keep the
v-motion
presets? This is one of the most useful parts of this library like adding in quick fade type animations..
Correct. I think the goal is to keep current functionality the same as v-motion
directive.
I can also help with a documentation site if needed. I am a designer and front-end dev primarily using Vue/Nuxt. You check my portfolio on my profile if needed:)
Although I am not sure what new information needs to be on the documentation ๐ค
Hey guys!
Any chance to use motionone
instead of popmotion
in the new major?
@productdevbook https://github.com/oku-ui/motion
@sadeghbarati thank you.
Motionone documentation and npm packages have been officially delivered to us. What can we do in the same place? I am open to collaborations if you have ideas.
Another reason we should consider restructuring the repo (besides the benefits of splitting deps) is so we can use https://github.com/nuxt/module-builder to build the Nuxt module. The module builder will generate the correct types for Nuxt based on type exports which we are currently missing (e.g. runtime config types).
@cpreston321 @BobbieGoede I think the next step should be to migrate to https://motion.dev/.
Benefits:
Hey @BobbieGoede just checking the status of this ๐ค
Not sure how I feel about the migrating to Motion One, although the benefits are definitely a thing to consider (the Web Animations API and small bundlesize are great). However, there are some third party libraries that are currently integrated with @vueuse/motion
such as hero-motion, which is a phenomenal addition to create more Framer-motion UI components. Ideally, something like hero-motion could be integrated into this package, along with other planned updates.
I'd recommend to keep this repo separate from Motion One and possibly integrate a new API or add shared layout animations like in hero-motion.
Also no need to rush a major update, this repo does its job atm and the updates that have happened this year are very appreciated by all of us I am sure!
@rylanharper
We're not in a hurry to replace popmotion
anytime soon (unless there's high demand for it) but it will happen in the long term as it's no longer maintained. This doesn't necessarily need to be a breaking change, it may be possible to keep our API unchanged while migrating, otherwise this would need to happen in a new major version.
In the short(er than long) term I'll be focusing on the following: SSR/Nuxt support, reducing bundle size, stabilizing <Motion />
and <MotionGroup />
components, and general maintenance (docs, issues, ci). No time estimations or anything as it's all during off-hours ๐
@BobbieGoede Thanks for the update! This all sounds awesome. Yes, no rush on anything - this is a phenomenal package!
We've changed the release process and also added a nightly release channel https://github.com/vueuse/motion#nightly-release-channel (https://www.npmjs.com/package/vueuse-motion-nightly). So we should be able to publish changes easier/faster now!
Roadmap DRAFT
Short Term Goal
build:vite
,build:nuxt
and etc... (could be improved from the current implementation)v-motion
with<Motion />
component@ts-expect-error - Typescript 5 fix later
Long Term Goal
@vueuse/motion
If you have additional items you would like to see please feel free to give your ideas ๐ก below.