113 | );
114 | }
115 | }
116 | ```
117 |
118 | See the `path` prop passed to the `SVGPath` component? It's a function that defines how the path changes based on the
119 | spring values by returning a string.
120 |
121 | The `path` prop function is passed a single argument that describes the current state of all the springs. You can
122 | define as many parameters as you want off the back of it. I defined `tr` and `tl` to represent the rightmost and
123 | leftmost points of the SVG definition.
124 |
125 | ## Tips
126 |
127 | ### It's a pain getting the SVG path
128 |
129 | Tell me about it. The SVG spec is pretty straightforward but just play around with your `path` prop until it draws
130 | what you're expecting.
131 |
132 | I found it useful to return a constant string (ignoring the `delta` param) until I need which point I wanted to change.
133 |
134 | Would be great to have tools to help us with this in the future. Bear with us.
135 |
136 | ### It's still too low level
137 |
138 | I know what you mean. I like the power we have with this API, but I'm thinking of ways which are slightly more how
139 | designers think.
140 |
141 | ## Contributing
142 |
143 | - [Contributing](docs/contributing/index.md)
144 | - [Versions: Release Names vs Version Numbers](docs/contributing/versions/index.md)
145 |
--------------------------------------------------------------------------------
/bower.json:
--------------------------------------------------------------------------------
1 | {
2 | "name": "react-morphine",
3 | "version": "0.1.3",
4 | "homepage": "https://github.com/mmmoli/react-morphine",
5 | "authors": [
6 | "Michele Memoli (http://100shapes.com)"
7 | ],
8 | "description": "Relieving the pain of morphing UIs",
9 | "main": [
10 | "build/react-morphine.min.js",
11 | "build/react-morphine.map"
12 | ],
13 | "dependencies": {
14 | "react": ">=0.13.2 || ^0.14"
15 | },
16 | "keywords": [
17 | "react",
18 | "react-motion",
19 | "svg",
20 | "morph",
21 | "component",
22 | "react-component",
23 | "spring",
24 | "tween",
25 | "motion",
26 | "animation",
27 | "transition",
28 | "ui"
29 | ],
30 | "license": "MIT",
31 | "ignore": [
32 | "**/.*",
33 | "node_modules",
34 | "coverage",
35 | "example",
36 | "bower_components",
37 | "test",
38 | "tests",
39 | "src",
40 | "package.json",
41 | "webpack.config.js",
42 | "webpack.prod.config.js"
43 | ]
44 | }
45 |
--------------------------------------------------------------------------------
/contributing.md:
--------------------------------------------------------------------------------
1 | # Contributing
2 |
3 |
4 | ## Contents
5 |
6 |
7 | - [Contributing](docs/contributing/index.md)
8 | - [Versions: Release Names vs Version Numbers](docs/contributing/versions/index.md)
9 |
--------------------------------------------------------------------------------
/docs/contributing/index.md:
--------------------------------------------------------------------------------
1 | # Contributing
2 |
3 |
4 | ## Contents
5 |
6 | - [Reporting bugs](#reporting-bugs)
7 | - [Example](#example)
8 | - [Getting Started](#getting-started)
9 | - [Clone the repo](#clone-the-repo)
10 | - [If there's no issue, please create one](#if-theres-no-issue-please-create-one)
11 | - [Let us Know you're working on the issue](#let-us-know-youre-working-on-the-issue)
12 | - [Create a feature branch:](#create-a-feature-branch)
13 | - [Make your changes and commit:](#make-your-changes-and-commit)
14 | - [Create a Pull Request](#create-a-pull-request)
15 | - [PR Merge Exception](#pr-merge-exception)
16 | - [PR Hints](#pr-hints)
17 | - [For large changes spanning many commits / PRs](#for-large-changes-spanning-many-commits--prs)
18 |
19 |
20 | - [Versions: Release Names vs Version Numbers](versions/index.md)
21 |
22 | ## Reporting bugs
23 |
24 | Bug reports should contain the following information:
25 |
26 | * Summary: A brief description.
27 | * Steps to reproduce: How did you encounter the bug? Instructions to reproduce it.
28 | * Expected behavior: How did you expect it to behave?
29 | * Actual behavior: How did it actually behave?
30 | * Screenshot or animated gif: If possible, attach visual documentation of the bug.
31 | * References: Links to any related tickets or information sources.
32 |
33 | ### Example
34 |
35 | Here's a [real issue](https://github.com/woothemes/woocommerce/issues/8563#issue-94518347) to demonstrate.
36 |
37 |
38 | ## Getting Started
39 |
40 | ### Clone the repo
41 |
42 | * Click the GitHub fork button to create your own fork
43 | * Clone your fork of the repo to your dev system
44 |
45 | ```
46 | git clone git@github.com:/prod-module-boilerplate.git
47 | ```
48 |
49 | ### If there's no issue, please create one
50 |
51 |
52 | ### Let us Know you're working on the issue
53 |
54 | If you're actively working on an issue, please comment in the issue thread stating that you're working on a fix, or (if you're an official contributor) assign it to yourself.
55 |
56 | This way, others will know they shouldn't try to work on a fix at the same time.
57 |
58 |
59 | ### Create a feature branch:
60 |
61 | ```
62 | git checkout -b
63 | ```
64 |
65 | ### Make your changes and commit:
66 |
67 | * Make sure you comply with the [.editorconfig](http://editorconfig.org/)
68 |
69 | ```
70 | git commit -m '[Issue #] '
71 | ```
72 |
73 | ### Create a Pull Request
74 |
75 | Please don't merge your own changes. Create a pull request so others can review the changes.
76 |
77 | **Push changes:**
78 |
79 | ```
80 | git push origin
81 | ```
82 |
83 | * Open your repository fork on GitHub
84 | * You should see a button to create a pull request - Press it
85 | * Consider mentioning a contributor in your pull request comments to alert them that it's available for review
86 | * **Wait for the reviewer to approve and merge the request**
87 |
88 | ### PR Merge Exception
89 |
90 | * Minor documentation grammar/spelling fixes (code example changes should be reviewed)
91 |
92 |
93 | ### PR Hints
94 |
95 | Reference the issue number in your commit message e.g.:
96 |
97 | ```
98 | $ git commit -m '[#5] Make sure to follow the PR process for contributions'
99 | ```
100 |
101 | #### For large changes spanning many commits / PRs
102 |
103 | * Create a meta-issue with a bullet list using the `* [ ] item` markdown syntax.
104 | * Create issues for each bullet point
105 | * Link to the meta-issue from each bullet point issue
106 | * Check off the bullet list as items get completed
107 |
108 | Linking from the bullet point issues to the meta issue will create a list of issues with status indicators in the issue comments stream, which will give us a quick visual reference to see what's done and what still needs doing.
109 |
--------------------------------------------------------------------------------
/docs/contributing/versions/index.md:
--------------------------------------------------------------------------------
1 | # Versions: Release Names vs Version Numbers
2 |
3 |
4 | ## Contents
5 |
6 | - [What?](#what)
7 | - [Why?](#why)
8 | - [Details](#details)
9 | - [Release Names (AKA code names)](#release-names-aka-code-names)
10 | - [MVP](#mvp)
11 | - [Version Numbers](#version-numbers)
12 | - [Breaking.Feature.Fix](#breakingfeaturefix)
13 | - [Breaking](#breaking)
14 | - [Feature](#feature)
15 | - [Fix](#fix)
16 | - [Examples](#examples)
17 |
18 |
19 |
20 | ## What?
21 |
22 | Version numbers are **only** there to communicate the nature of a change: **Breaking.Feature.Fix**.
23 |
24 | Human names are there to communicate, "Hey everybody, we have a new release! Here are the new features!"
25 |
26 | ## Why?
27 |
28 | Our releases and versions are separate concepts because the need to communicate new stable release information and the need to inform developers about the nature of changes (breaking, new features, or fixes/security patches) are two separarete concerns which advance on separate timetables.
29 |
30 | The conflating of version numbers and public releases has led to a big problem in the software development community. Developers tend to break semantic version numbering, for example, resisting the need to advance the breaking (major) version number because they're not yet ready to release their mvp (which many developers think of as 1.0).
31 |
32 | In other words, we need two separate ways of tracking changes:
33 |
34 | * One for people & public announcements (names).
35 | * One for resolving version conflict problems (numbers).
36 |
37 | ## Details
38 |
39 | ### Release Names (AKA code names)
40 |
41 | Our major releases have code-names instead of version numbers. The current release is identified by the "latest" tag. The first version is "mvp". After that we pick a theme, and work through the alphabet from A to Z.
42 |
43 | When talking about release versions, we don't say "version Arty" we say "the newest version was released today, code named 'Arty'". After that, we just refer to it as "Arty" or "latest version". More recognizable codename examples include "Windows Vista" or "OS X Yosemite".
44 |
45 |
46 | #### MVP
47 |
48 | MVP stands for "Minimum **Valuable** Product" (a better version of the common "Minimum Viable Product"). The minimum number of features to make the product valuable to users.
49 |
50 | 
51 |
52 |
53 | ### Version Numbers
54 |
55 | [Semver](http://semver.org), except the version roles have the semantic names, "Breaking.Feature.Fix" instead of "Major.Minor.Patch".
56 |
57 |
58 | #### Breaking.Feature.Fix
59 |
60 | We don't decide what the version will be. The API changes decide. Version numbers are for computers, not people. Release names are for people.
61 |
62 | ##### Breaking
63 |
64 | Any breaking change, no matter how small increments the Breaking version number. Incrementing the Breaking version number has absolutely no relationship with issuing a release.
65 |
66 | ##### Feature
67 |
68 | When any new feature is added. This could be as small as a new public property, or as large as a new module contract being exposed.
69 |
70 | ##### Fix
71 |
72 | When a documented feature does not behave as documented, or when a security issue is discovered and fixed without altering documented behavior.
73 |
74 |
75 |
76 | ## Examples
77 |
78 | If it's time to write a blog post to inform the community about new features or important changes, we find the version we want to publicize, tag it "latest", give it a human-readable name, (i.e. "MVP" or "Art Nouveau" in the case of the [JSHomes API](https://github.com/jshomes/jshomes-platform-api/blob/master/README.md#jshomes-api-)).
79 |
80 | That human readable release name **does not replace semver**. "MVP" might correspond to `v1.6.23` or `v2.2.5` -- the point is, **the numbered version has nothing to do with the named release**.
81 |
82 | The numbered version is there so npm and developers can tell whether or not a new version is a breaking change, an added feature change, or a bug / security fix.
83 |
84 |
85 |
--------------------------------------------------------------------------------
/docs/demo.gif:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/mmmoli/react-morphine/6a5b7a6e1cc1b801eba67de99ed52da9b5fa18c3/docs/demo.gif
--------------------------------------------------------------------------------
/example/Card.css:
--------------------------------------------------------------------------------
1 | body {
2 | background-color: #FFD605;
3 | margin: 0;
4 | padding: 0;
5 | }
6 |
7 | #root {
8 | display: flex;
9 | justify-content: center;
10 | align-items: center;
11 | height: 100vh;
12 | width: 100vw;
13 | }
14 |
15 | .Card {
16 | display: flex;
17 | position: relative;
18 | background-color: #215CFF;
19 | border-radius: 5px;
20 | width: 350px;
21 | height: 70vh;
22 |
23 | box-shadow: 2px 2px 5px rgba(0, 0, 0, 0.1);
24 | overflow: hidden;
25 | }
26 |
27 | .Card svg {
28 | overflow: hidden;
29 | border-radius: 5px;
30 | position: absolute;
31 | top: -1px; /* fixes rendering issue in FF */
32 | z-index: 10;
33 | width: 100%;
34 | height: 100%;
35 | }
36 |
37 | .Card svg path {
38 | fill: #0038CC;
39 | }
--------------------------------------------------------------------------------
/example/Card.js:
--------------------------------------------------------------------------------
1 | import React, {Component} from 'react';
2 | import {spring, presets} from 'react-motion';
3 |
4 | import './Card.css';
5 | import SVGPath from '../source/SVGPath';
6 |
7 | const DEFAULT = {
8 | tr: 20,
9 | tl: 120
10 | };
11 |
12 | const SECONDARY = {
13 | tr: 210,
14 | tl: 240
15 | };
16 |
17 | class Card extends Component {
18 |
19 | constructor(props) {
20 | super(props);
21 | this.state = {
22 | isHovering: false
23 | };
24 | }
25 |
26 | onEnter() {
27 | this.setState({
28 | isHovering: true
29 | });
30 | }
31 |
32 | onLeave() {
33 | this.setState({
34 | isHovering: false
35 | });
36 | }
37 |
38 | render() {
39 | const {isHovering} = this.state;
40 |
41 | const destination = isHovering ? SECONDARY : DEFAULT;
42 |
43 | return (
44 |