Roadmap DRAFT

[cpreston321]

Roadmap DRAFT

[!NOTE] This is still a work in-progress, some items may change.

Short Term Goal

• [ ] CI
  • [x] Promote NPM releases using automation (Nightly releases)
  • [ ] Improve overall CI scripts (parallel automation) e.g build:vite, build:nuxt and etc... (could be improved from the current implementation)
• [ ] Improve
  • [ ] SSR / Nuxt Support
  • [ ] Better tree-shaking
  • [ ] Documentation by using something like Nuxt UI Pro for simple integration
    • ui.nuxt.com
• [ ] Replace v-motion with <Motion /> component

  •   <script setup>
       	const motionRef = ref()
      </script>
      <template>
      	<Motion
      	   :ref="motionRef"
      	   :enter="{ ... }"
      	   :leave="{ ... }"
      	>
              <div />
      	</Motion>
      </template>
    

• [ ] Fix all typescript 5 errors marked within the code @ts-expect-error - Typescript 5 fix later
• [ ] !! Work on outstanding bugs currently

Long Term Goal

• [ ] Re-structure repo for less deps required by overall package
• [ ] Working towards a more stable v2 --> v3
• [ ] Ask for additional hands to help support maintaining @vueuse/motion

---

If you have additional items you would like to see please feel free to give your ideas 💡 below.

[rylanharper]

@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))
    })
  }
})

[BobbieGoede]

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)

[cpreston321]

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).

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]

@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.

[rylanharper]

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 🤔

[sadeghbarati]

Hey guys!

Any chance to use motionone instead of popmotion in the new major?

@productdevbook https://github.com/oku-ui/motion

[productdevbook]

@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.

[BobbieGoede]

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).

[enkot]

@cpreston321 @BobbieGoede I think the next step should be to migrate to https://motion.dev/.

Benefits:

1. Uses performant Web Animations API.
2. Great built-in API for scroll, inView and timeline animations (https://gesture.vueuse.org/ can be deprecated).
3. Small bundlesize (<4kb gzipped).

[rylanharper]

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!

[BobbieGoede]

@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 😅

[rylanharper]

@BobbieGoede Thanks for the update! This all sounds awesome. Yes, no rush on anything - this is a phenomenal package!