β look at project 1.0.1 Proxy is default (LegacyMode available), firing HypeActionEvents on HypeDocumentLoad and refactored variables
This release marks a move to a Proxy approach. Meaning, it drops support for IE as that interface is not supported on that Legacy Browser. If you really need to support IE you can still enable use:
HypeActionEvents.setDefault('LegacyMode', true);
If this mode is enabled, all variables that are not called contextually are generated in the window scope. For single Hype applications, that shouldn't be a problem and furthermore can be avoided by adding a context variable (customData.myVariable instead of myVariable. See above regarding context variables.
β look at project 1.0.2 Prioritize user functions over functions in hypeDocument, added events on data-scene-load-action, data-scene-unload-action, data-scene-prepare-action and data-layout-request-action
β look at project 1.0.3 Added event functions for ResizeObserver, IntersectionObserver and MutationObserver, changed to passive DOM events, added requestAnimationFrame events, added window and document events
There was a slight regression on the contextual variables since the introduction of the proxy approach in version 1.0.2 ($evt, $sym, $doc, $ctx and $elm where not property resolved), but this has been fixed as well. More examples and documentation soon.
Additional note: the custom behavior context is fired in an agnostic context, so it doesnβt contain an element (and $elm) and the event is a custom behavior context. That is duo to the way Hype handles this internally. The triggerAction interface exposure through custom behavior is at this point an added bonus, with said minor inconveniences like not being aware where it was fired. If you require that context to be populated, just use the data-EVENT-action on an element.
β look at project 1.0.5 Fixed typo that prevented collision events to be detected
Make sure to purge your Browser cache and restart Hype when using examples after I made an GitHub update!
β look at project 1.0.6 Added hypeDocument, element and event to the triggerAction context, added data-behavior-action
Add your actions on specific element using custom behavior triggers.
data-behavior-action listens to all behavior names data-behavior-test-action would only listen to the test behavior name*
* behavior names are lower cased and spaces/tabs are replaced with dash. Hence, a behavior like Hello World --- Test would become hello-world-test and the full action hook would be data-behavior-hello-world-test-action
Example using hypeDocument.triggerAction and Symbol Handler
Here is a simple switch button using hypeDocument.triggerAction and also showing how Hype Action Event triggers a function handler named like a symbol if found on HypeSymbolLoad and HypeSymbolUnload (proactive).
β look at project 1.0.7 Added data-timeline-complete-action, hypeDocument.triggerActionsByAttribute and minor refactoring
1.0.8 Bugfix on data-timeline-complete-action for particular timelines
You can now trigger actions when a timeline completes using data-timeline-complete-action for all timelines or if a specific timeline completes like test it would be data-timeline-complete-test-action
This example uses Hype Action Events, Hype Matter Helper and Hype Drag Gesture to offer drag and drop support with precise drop zones and snapping. Note that this drag'n'drop approach relies on the Matter engine offered by Tumult Hype to determine arbitrary shape intersections. Hence, the export will include the physics engine.
And the following selector defining the drop target
data-drop-selector
This example also uses a snapping mechanism, data-snap-target, but that is specific to this particular example and implemented in the document rather than being part of the gesture.
With this demo, I am actually not so sure if I do it in such a way in an actual production (hence, the title of experiment). I would probably rather have the entire sticky element be one symbol and use a progress function. In this example file, there is a lot of whitespace just to have room to scroll to drive progress.
The following data attributes can be used to control the behavior of the scroll progress handler:
data-sticky-start: This attribute allows you to set a custom start position for the element's sticky behavior. If this attribute is not set, the element will become sticky when it reaches the top of the page.
data-sticky-end:
This attribute allows you to set a custom end position for the element's sticky behavior. If this attribute is not set, the element will remain sticky until the user scrolls to the bottom of the page.
data-sticky-bounding:
This attribute allows you to set a bounding box for the element's sticky behavior. If this attribute is set, the element will become sticky when it reaches the top of the bounding box, and will remain sticky until the user scrolls to the bottom of the bounding box.
There is a little progress handler action in the example as well (bonus):
data-progress-start:
The top position (in pixels) of the scrollable area.
data-progress-end:
The bottom position (in pixels) of the scrollable area.
data-progress-timeline:
The name of the timeline to be played (defaults to main timeline)
This example is a refactored version of the custom continueAfterDrag functionality. It offers more options and settings than the regular version, built in to Hype.
minVelocity Set the min velocity. Use only in special cases as it can lead to infinite movement after drag
maxVelocity Often a good way to avoid to high values after a drag'n'slide gesture
friction defaults to 0.95 and slows down the velocity of the continued drag on each tick. This adds an organic feel to the movement.
forceInstance, symbolInstance (can be used to add symbolInstance or hypeDocument, is auto-detected inside of symbols in favor of the symbol)
timelineName is the name of the timeline and default to the Main Timeline of either the hypeDocument or the symbolInstance
borderMode defaults to none as seen in regular Hype, and the movement just stops at the end or beginning. Using bounce allows bouncing of the end and beginning. In such an event, there is an additional friction applied. Finally, there is the shift mode, and it allows overshoots at the end or beginning. As we are talking about a timeline, this means the timeline restarts in the current play head direction.
borderFriction defaults to a factor of 0.1 and is only applied if the borderMode is set to bounce. Setting this to 0.9 allows for much more bouncing.
threshold this defaults to 0.01 and is the threshold the velocity must be under to trigger an end for a slide action