vueuse / motion

🤹 Vue Composables putting your components in motion
https://motion.vueuse.org
MIT License
2.12k stars 75 forks source link

Roadmap DRAFT #169

Open cpreston321 opened 5 months ago

cpreston321 commented 5 months ago

Roadmap DRAFT

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

Short Term Goal

Long Term Goal


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

rylanharper commented 5 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))
    })
  }
})
BobbieGoede commented 4 months ago

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 commented 4 months ago

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 commented 4 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..

Correct. I think the goal is to keep current functionality the same as v-motion directive.

rylanharper commented 4 months ago

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 commented 4 months ago

Hey guys!

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

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

productdevbook commented 4 months ago

@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 commented 1 week ago

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