0.2.3 • Published 5 years ago

@movigo/list v0.2.3

Weekly downloads
3
License
MIT
Repository
github
Last release
5 years ago

:paperclip: Table of Contents

:hammer: Install

npm

You can install movigo list plugin with npm:

npm install @movigo/list --save

CDN

You can also load it using a \ using the unpkg CDN:

<script src="https://unpkg.com/@movigo/core"></script> <!-- Required dependency -->
<script src="https://unpkg.com/@movigo/list"></script>

:video_game: Usage

List plugin create a list function in the Movigo function chaining. You must select list elements with target function and call list function with the optional options parameter. List plugin create an animation for each list element.

const target = movigo.target('ul > li')

target.list({
    x: 200, // Initial relative x coordinate (default: 0)
    y: 200, // Initial relative y coordinate (default: 100)
    duration: .5, // Animation duration (default: .3)
    easing: 'linear' // Easing function (default: 'cubic-bezier(0.0, 0.0, 0.2, 1)')
}).animate()

:chart_with_upwards_trend: Development

:scroll: Rules

Commits

  • Use this commit message format (angular style):

    [<type>] <subject> <BLANK LINE> <body>

    where type must be one of the following:

    • feat: A new feature
    • fix: A bug fix
    • docs: Documentation only changes
    • style: Changes that do not affect the meaning of the code
    • refactor: A code change that neither fixes a bug nor adds a feature
    • test: Adding missing or correcting existing tests
    • chore: Changes to the build process or auxiliary tools and libraries such as documentation generation
    • update: Update of the library version or of the dependencies

and body must be should include the motivation for the change and contrast this with previous behavior (do not add body if the commit is trivial).

  • Use the imperative, present tense: "change" not "changed" nor "changes".
  • Don't capitalize first letter.
  • No dot (.) at the end.

Branches

  • There is a master branch, used only for release.
  • There is a dev branch, used to merge all sub dev branch.
  • Avoid long descriptive names for long-lived branches.
  • No CamelCase.
  • Use grouping tokens (words) at the beginning of your branch names (in a similar way to the type of commit).
  • Define and use short lead tokens to differentiate branches in a way that is meaningful to your workflow.
  • Use slashes to separate parts of your branch names.
  • Remove branch after merge if it is not important.

Examples:

git branch -b docs/README
git branch -b test/one-function
git branch -b feat/side-bar
git branch -b style/header

:page_facing_up: License

:telephone_receiver: Contacts

:boy: Developers

Cedoor

@movigo/core
@infinitebrahmanuniverse/nolb-_mov@everything-registry/sub-chunk-620
0.2.3

5 years ago

0.2.2

5 years ago

0.2.1

5 years ago

0.2.0

5 years ago

0.1.0

5 years ago