lederer / react-showtime Goto Github PK

Motion can be a problem for some users. A media query can determine if the user prefers reduced motion. Should we disable all transitions if that's the case? Or should that be left to the consumer?

Reference:
https://www.joshwcomeau.com/react/prefers-reduced-motion/

Consider a "bounce" keyword for easing that's a canned cubic-bezier.

Tricky bit is it would need to automatically apply different (inverted) versions to showEasing and hideEasing.

We should create a GitHub Actions workflow to publish releases to npm under the Azavea account. Releases will be semantically versioned and tagged on main.

We should also create a release template that details how to version and tag a release so that it will correctly trigger this workflow.

When a user has prefers-reduced-motion enabled, we should honor it by disabling all react-showtime transitions.

Potentially add an overridePrefersReducedMotion boolean prop to override it?

When live editing an example on the demo site, introducing a source code error renders a large error message component that obscures the entire editor, making further edits impractical.

Can probably be addressed by figuring out a different position or layout for the <LiveError> component.

• Start a new release branch:

$ git flow release start X.Y.Z

• Bump version in package.json to X.Y.Z:

$ yarn version --no-git-tag-version --new-version X.Y.Z

• Rotate CHANGELOG.md (following Keep a Changelog principles)
• Ensure outstanding changes are committed:

$ git status # Is the git staging area clean?
$ git add package.json CHANGELOG.md
$ git commit -m "X.Y.Z"

• Publish the release branch:

$ git flow release publish X.Y.Z

• Finish and publish the release branch:
  • When prompted, keep default commit messages
  • Use X.Y.Z as the tag message

$ git flow release finish -p X.Y.Z

Would it make sense to make use of will-change?

• Start a new release branch:

$ git flow release start X.Y.Z

• Bump version in package.json to X.Y.Z:

$ yarn version X.Y.Z

• Rotate CHANGELOG.md (following Keep a Changelog principles)
• Ensure outstanding changes are committed:

$ git status # Is the git staging area clean?
$ git add package.json CHANGELOG.md
$ git commit -m "X.Y.Z"

• Publish the release branch:

$ git flow release publish X.Y.Z

• Finish and publish the release branch:
  • When prompted, keep default commit messages
  • Use X.Y.Z as the tag message

$ git flow release finish -p X.Y.Z

TypeScript types can be added separately to a JavaScript project like react-showtime so as to not require anything to be rewritten or change anything about the development workflow (purely supplementary). We should do that since it will only help with adoption!

Types can be generated from the JavaScript itself and they can even be checked against the JS implementation to make sure they're in sync.

• Start a new release branch:

$ git flow release start X.Y.Z

• Bump version in package.json to X.Y.Z:

$ yarn version X.Y.Z

• Rotate CHANGELOG.md (following Keep a Changelog principles)
• Ensure outstanding changes are committed:

$ git status # Is the git staging area clean?
$ git add package.json CHANGELOG.md
$ git commit -m "X.Y.Z"

• Publish the release branch:

$ git flow release publish X.Y.Z

• Finish and publish the release branch:
  • When prompted, keep default commit messages
  • Use X.Y.Z as the tag message

$ git flow release finish -p X.Y.Z

This may not be worth the additional API complexity and ambiguity, but it might be convenient to support show/hide{Value, Duration, Delay, Easing} within per-property transitions.

Eg:

transition: {
  height: 0,
  opacity: {
    value: 0,
    showDelay: 100,
    showDuration: 150,
    hideDelay: 25,
    hideDuration: 125
  }
}

The same outcome is already possible by defining a distinct showTransition and hideTransition, but that can be a bit annoying when both have exactly the same properties and only the per-property values and/or timings are different.

OTOH promoting multiple ways of doing the same thing has its own drawbacks.

Another drawback: We'd have to ignore per-property show* if erroneously supplied within a hideTransition, and vice versa.

But it's worth considering. I've found myself wanting to express transitions this way at times.

• Start a new release branch:

$ git flow release start X.Y.Z

• Bump version in package.json to X.Y.Z:

$ yarn version X.Y.Z

• Rotate CHANGELOG.md (following Keep a Changelog principles)
• Ensure outstanding changes are committed:

$ git status # Is the git staging area clean?
$ git add package.json CHANGELOG.md
$ git commit -m "X.Y.Z"

• Publish the release branch:

$ git flow release publish X.Y.Z

• Finish and publish the release branch:
  • When prompted, keep default commit messages
  • Use X.Y.Z as the tag message

$ git flow release finish -p X.Y.Z

• Start a new release branch:

$ git flow release start X.Y.Z

• Bump version in package.json to X.Y.Z:

$ yarn version --no-git-tag-version --new-version X.Y.Z

• Rotate CHANGELOG.md (following Keep a Changelog principles)
• Ensure outstanding changes are committed:

$ git status # Is the git staging area clean?
$ git add package.json CHANGELOG.md
$ git commit -m "X.Y.Z"

• Publish the release branch:

$ git flow release publish X.Y.Z

• Finish and publish the release branch:
  • When prompted, keep default commit messages
  • Use X.Y.Z as the tag message

$ git flow release finish -p X.Y.Z

Consider supporting keyframes for multi-step animations. Would require using CSS animation instead of transition, at least when the keyframes setting is present.

The Attaching the ref section of the Readme refers to the hook ref, but doesn't mention anything about the component. Nonetheless, the child passed to the component must be capable of accepting a ref, along the same lines as described for the hook. The readme should make this clear.

Describe the bug
This library does not work with Gatsby as it uses the window object which is not available during gatsby builds.

To Reproduce
Steps to reproduce (if the above description doesn't cover it):

1. Use the useShowtime hook in a project
2. Run a gatsby build
3. See error

Expected behavior
Build should work.

Screenshots

 ERROR #95312 

"window" is not available during server side rendering.

See our docs page for more info on this error: https://gatsby.dev/debug-html


  549 |
  550 | function useEventListener(eventName, handler) {
> 551 |   var element = arguments.length > 2 && arguments[2] !== undefined ? arguments[2] : window;
      | ^
  552 |   // This allows the effect below to always get latest handler ...
  553 |   // ... without needing to pass it in effect deps array ...
  554 |   // ... and potentially cause effect to re-run every render.


  WebpackError: ReferenceError: window is not defined
  
  - index.es.js:551 
    [my-gatsby-site]/[react-showtime]/dist/index.es.js:551:1
  
  - index.es.js:677 
    [my-gatsby-site]/[react-showtime]/dist/index.es.js:677:1
  
  - Nav.jsx:29 
    my-gatsby-site/src/components/Nav/Nav.jsx:29:42
  
  - extends.js:11 
    [my-gatsby-site]/[@babel]/runtime/helpers/extends.js:11:1
  
  - extends.js:14 
    [my-gatsby-site]/[@babel]/runtime/helpers/extends.js:14:1
  
  - extends.js:20 
    [my-gatsby-site]/[@babel]/runtime/helpers/extends.js:20:1
  
  - inheritsLoose.js:3 
    [my-gatsby-site]/[@babel]/runtime/helpers/inheritsLoose.js:3:1
  
  - static-entry.js:299 
    my-gatsby-site/.cache/static-entry.js:299:22
  
  - utils.js:37 
    [my-gatsby-site]/[@gatsbyjs]/reach-router/lib/utils.js:37:1
  

not finished Caching JavaScript and CSS webpack compilation - 12.443s
not finished Caching HTML renderer compilation - 0.360s

npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] deploy: `gatsby build --prefix-paths && gh-pages -d public`
npm ERR! Exit status 1```
**Desktop (please complete the following information):**
 - OS: PopOS
 - Browser chrome - latest

Is your feature request related to a problem? Please describe.
There is currently no straightforward way to specify a show transition with no hide transition, or vice versa.

Describe the solution you'd like
Passing in a showTransition without a hideTransition (or vice versa) and without a transition should do it.

Describe alternatives you've considered
Alternatively, or in addition, it might make sense to support a "none" keyword for showTransition and hideTransition.

Additional context
An example use case is if you need a transition for the initial appearance of something (eg, a status update), then need to replace it later with something new that has its own show transition (eg, a new status update). In these cases it might make sense to remove the first item instantly instead of using a hide transition, so the new item can being its initial show transition forthwith.

Is your feature request related to a problem? Please describe.
The current hook API returns a ref that the consumer must attach to the element. If the consumer also has their own ref, they need to merge the refs manually, which can be unwieldy.

Describe the solution you'd like
An alternative approach is to require that the consumer create their own ref and pass it into the hook.

// defaults
const ref = useRef();
const [isMounted, show, hide] = useShowtime(ref);

// with settings
const ref = useRef();
const [isMounted, show, hide] = useShowtime(ref, "rise");

See https://twitter.com/buildsghost/status/1338951882052567041 for some discussion.

Additional context
Unclear if we should do this. We need to evaluate pros and cons.

Set up a Netlify site and create a netlify.toml config to deploy the example subdirectory.

Additionally, we should establish a CHANGELOG to track releases for this library.

Related to resolution for azavea/operations#491.

For those used to composing CSS, it can be cumbersome to compose object literals. We should consider accepting properly formed CSS strings for transition, showTransition, hideTransition, as an alternative to CSS object literals. The primary purpose is the same: to express the hidden CSS state of the item.

Some intertwining considerations:

• Would it still be possible to provide per-property timings when passing a string instead of an object? How?
• What happens if they include transition as one of the CSS properties in the string? Ignore it? Defer to it?
• Should we also allow the string expression of the CSS transition property via a distinct setting (eg, CSSTransitionProperty), so they can author their own timings via a string rather than having it automatically assembled from our various symmetric, asymmetric, and per-property timing settings?

Overall this seems like too much complexity and ambiguity. But the pull of authoring CSS as… CSS, can be quite strong for those proficient in it.

• Start a new release branch:

$ git flow release start X.Y.Z

• Bump version in package.json to X.Y.Z:

$ yarn version X.Y.Z

• Rotate CHANGELOG.md (following Keep a Changelog principles)
• Ensure outstanding changes are committed:

$ git status # Is the git staging area clean?
$ git add package.json CHANGELOG.md
$ git commit -m "X.Y.Z"

• Publish the release branch:

$ git flow release publish X.Y.Z

• Finish and publish the release branch:
  • When prompted, keep default commit messages
  • Use X.Y.Z as the tag message

$ git flow release finish -p X.Y.Z

Since this project is intended as a general-purpose tool, it may receive some interest from community contributors. We should consider following GitHub's recommendation to add a CONTRIBUTING.md file to provide guidance for how external contributors can contribute to this project.

GitHub also recommends adding a CODE_OF_CONDUCT.md file to set expectations for respectful, constructive engagement and repository moderation. This practice also in line with recent positive trends in the OSS community as a whole. We should consider if there are commonly used codes of conduct that align well with our values and ability to moderate potential conflicts. The Contributor Covenant may be a good starting place, and has seen widespread adoption.

• Start a new release branch:

$ git flow release start X.Y.Z

• Bump version in package.json to X.Y.Z:

$ yarn version X.Y.Z

• Rotate CHANGELOG.md (following Keep a Changelog principles)
• Ensure outstanding changes are committed:

$ git status # Is the git staging area clean?
$ git add package.json CHANGELOG.md
$ git commit -m "X.Y.Z"

• Publish the release branch:

$ git flow release publish X.Y.Z

• Finish and publish the release branch:
  • When prompted, keep default commit messages
  • Use X.Y.Z as the tag message

$ git flow release finish -p X.Y.Z

instant is easier to remember and quicker to type than startWithTransition. Semantics are more ambiguous but I suspect the tradeoffs are worth it.

Same for hidden vs startHidden… I think?

• Start a new release branch:

$ git flow release start X.Y.Z

• Bump version in package.json to X.Y.Z:

$ yarn version X.Y.Z

• Rotate CHANGELOG.md (following Keep a Changelog principles)
• Ensure outstanding changes are committed:

$ git status # Is the git staging area clean?
$ git add package.json CHANGELOG.md
$ git commit -m "X.Y.Z"

• Publish the release branch:

$ git flow release publish X.Y.Z

• Finish and publish the release branch:
  • When prompted, keep default commit messages
  • Use X.Y.Z as the tag message

$ git flow release finish -p X.Y.Z

Look into adding onHidden and onShowing callbacks to the hook.

Consider additional callbacks for both hook and component. Eg onWillShow, onWillHide.

The demo site refuses to load Google Analytics:

Refused to load the script 'https://www.googletagmanager.com/gtag/js?id=UA-970854-41' because it violates the following Content Security Policy directive: "script-src 'self' 'unsafe-eval' 'unsafe-inline'". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.

This may be helpful: https://developers.google.com/tag-manager/web/csp

Consider adding blur to the list of included transitions

• Bump dependencies, including…
  • npx browserslist@latest --update-db
  • React Live, which appears to have a new version release
• Consider a note in the readme about transfer from azavea to lederer and commitment to keep it public with the current license through at least Feb 2027.
• Release 0.3.0 (TS support; dependency bumps)
  • Minor release because TS support adds functionality but is backward compatible

• Start a new release branch:

$ git flow release start X.Y.Z

• Bump version in package.json to X.Y.Z:

$ yarn version X.Y.Z

• Rotate CHANGELOG.md (following Keep a Changelog principles)
• Ensure outstanding changes are committed:

$ git status # Is the git staging area clean?
$ git add package.json CHANGELOG.md
$ git commit -m "X.Y.Z"

• Publish the release branch:

$ git flow release publish X.Y.Z

• Finish and publish the release branch:
  • When prompted, keep default commit messages
  • Use X.Y.Z as the tag message

$ git flow release finish -p X.Y.Z

We need to decide on which domain we should use for the marketing / demo page for this library. We could just use a Netlify subdomain, we may want to establish it as an azavea.com subdomain, or we may want to purchase a domain. This is probably more of a marketing / branding question than a technical one.

In the short term, a netlify.com subdomain will get us up and running.

Consider accepting functions for duration and delay, including per-property. They would each receive the effective/inherited { duration, delay } values that would otherwise be used, so they could return a value based on them.

This way, slideFade's show transition could, say, delay the fade to the midpoint of the overall duration but have it complete at the same time, regardless of what custom duration or showDuration gets passed in.

If a custom delay or easing is provided with the slideFade transition, they will be ignored during the hide transition.

This is because slideFade includes its own hideDelay and hideEasing which, being more specific, override delay and easing.

The suggested workaround is to pass hideDelay and hideEasing. They will be honored.

Note this only affects the hide transition, not show. And duration is honored during hide, just not delay and easing.

No plans to fix this for now, because:

1. delay and easing are not expected to be commonly used.
2. There is an easy workaround.
3. Forcing custom symmetric timings to override canned asymmetric timings may open its own can of worms.

Safari Mac/iOS sometimes exhibits strange easing behavior when delay is 0. Eg, the bounce behavior in the Extravaganza example on the demo site becomes more of a thud.

Setting delay to something greater than 0 seems to fix it. Thus the default delay is a nominal 16ms (about 1 frame at 60fps).

Beware of changing delay (or show/hideDelay) to 0 without testing across browsers.

Create a dependabot.yml file to automatically bump npm dependencies with daily frequency. We may need to do this for / and /example separately.

Add bug and enhancement templates so those options are prominent when creating an issue.

• Start a new release branch:

$ git flow release start X.Y.Z

• Bump version in package.json to X.Y.Z:

$ yarn version X.Y.Z

• Rotate CHANGELOG.md (following Keep a Changelog principles)
• Ensure outstanding changes are committed:

$ git status # Is the git staging area clean?
$ git add package.json CHANGELOG.md
$ git commit -m "X.Y.Z"

• Publish the release branch:

$ git flow release publish X.Y.Z

• Finish and publish the release branch:
  • When prompted, keep default commit messages
  • Use X.Y.Z as the tag message

$ git flow release finish -p X.Y.Z