There are many (much more) powerful solutions out there. Starting with React and VUE, and some do need a build pipeline. Then there is AlpineJS or PetiteVue, that can be used in any project if you are knowledgeable enough to integrate them.
The goal behind this, although it came together rather spontaneous, was to keep it:
↑ look at project
1.0.8 Visibility changes display none to block if needed, debounced HypeTriggerCustomBehavior, Added compatibility with Hype Global Behavior
↑ look at project
1.0.9 Added isCode and setting a function in customData will not trigger and 'equals' behavior anymore, Added setDefault and getDefault, added customDataUpdate (callback) as default possibility
1.1.0 Added hypeDocument.enableReactiveCustomData and the default customData
Example of combining it with local storage (clear the cache to make sure you're on the latest version)
example_local_storage.hype.zip (43,3 KB)
I was exploring borders and feedback bubbles on the data-content and data-visibility attributes in the IDE. This isn't part of Hype Reactive Code (yet). More a trial on providing feedback that disappears outside the IDE. It adds a little CSS to the project and gives you this:
Update: This is now part of the extension since version 1.1.1
Very cool Max, this would be ideal for those in the retail industry, where manufacturers control map prices and retailers need to adhere to prices unless, there are circumstances when they can tamper with the map price case being, where upon a click of a button the price could change but not for everyone.
It be cool to see if there was a strike though on the main price, and a new price is generated below with a different color via click of a button which could say "click for better price".
example_combining_reactive_content_with_data_magic.hype.zip (43,1 KB)
↑ look at project
1.1.1 Fixed null case and added reactive highlighting in IDE, Added data-scope and scope indicator at beginning of expressions with the arrow symbol (⇢), Added the ability to inline the scope in data-content before the arrow symbol (⇢)
1.1.2 Minor cleanups and fixes
1.1.3 Fixed another falsy type bug that forwarded undefined data-scopes to the default scope
I used some spare time to add some features and make it more robust. Also, from now on, there is some feedback in the IDE, but there is also a production version if you want the smaller code without any highlights and feedback in the IDE.
BTW you can change the scope symbol from ⇢ to something else using HypeReactive.setDefault("scopeSymbol", "@") (example changing it to an @-Symbol). Currently only a single character, but with the next release I am thinking to allow multi character scope Symbol indication and change the default to --> or —>. Just to make it more convenient and not rely on symbols not directly on the keyboard. Thoughts and feedback welcome? Has anybody tried using Hype Reactive Content yet? I used it in two projects already.
↑ look at project
1.1.4 Added support for an arbitrary scopeSymbol with arbitrary length, default is still ⇢
After playing around with arrows today. I think the control/command/space option is easy enough to learn. One can even add a shortcut in macOS Settings ⇢ keyboard ⇢ text to convert ---> into ⇢. So, I am keeping the arrow as it only consumes a single char and not 2-3 chars. But, setting custom chars and multi chars will be included going forward. So, having --> or –> is still an option if you like it more. If you prefer simple ASCII arrows, use either of these:
HypeReactive.setDefault("scopeSymbol", "-->")
HypeReactive.setDefault("scopeSymbol", "–>")
—-
The only annoying thing is that Hype still changes > symbols used in head HTML into > in the Hype IDE so beware of that and put code that contains the symbol in an external JS file. I hope this annoyance gets “fixed” one day.
↑ look at project
1.1.5 Added the _key getter in the proxy to return a simple object string path, This fixes custom behavior notifications for nested keys as a full pseudo key is returned
updating nested.child = "test" will now trigger the custom behaviors
nested.child equals "test"
nested.child was updated
instead of the old
child equals "test"
child was updated
Hence, the full path will be rendered as pseudo notation. Here are some examples of the edge cases when setting arrays indexes and keys with spaces like nested[0]['Hello World'] = "test" would lead to:
nested.0.Hello World equals "test"
nested.0.Hello World was updated
↑ look at project
1.1.6 Added bubble type listener for action and behavior as data-content-changed-action, data-content-changed-behavior, data-visibility-changed-action and data-visibility-changed-behavior. Added $elm and element to code execution even if not used in conjunction with Hype Action Events
In addition to the custom behavior listener approach, you can now listen to content or visibility changes based on setting a data attribute. These attributes are now supported data-content-changed-action, data-content-changed-behavior, data-visibility-changed-action and data-visibility-changed-behavior. The action version run the code if a change is registered on any DOM element below the declaration (hence, bubble type). The same is true for the behavior versions. These new listeners react to DOM changes vs. the already existing behavior listeners that react to data changes.
The other new thing is that code executed now supports $elm or element even without loading Hype Action Events.
Amazing work Max!
↑ look at project
1.1.8 Updated visibility handling in conjunction with scope in content processing
This commit addresses an issue with the way scope in content and visibility were handled.
Changes made:
Modified the function to handle the "starts with" pattern more accurately.
Updated the data-visibility function to improve visibility handling reflecting the scope of content correctly.
To illustrate what this is about:
data-content is a HTML attribute that is set to ⇢name, where the symbol ⇢ signifies that the value of this property should be extracted from the current scope. This attribute allows for dynamic content binding, where the value of name will be resolved based on the current scope context.
The data-scope attribute is used to define a scope for elements in HTML. This attribute can be placed on an ancestor element, allowing it to encompass and affect the behavior of nested elements within its scope. It can also be applied to elements "outside" of a symbol or group, providing a broader context for the contained elements.
In a recent commit, an update was made to the data-visibility attribute. This modification was necessary due to a bug that affected the correct resolution of the attribute's value to the intended scope. The bug has been addressed and fixed, ensuring that the data-visibility attribute now functions as intended in resolving its value within the scope it belongs to.
↑ look at project
1.1.9 Added processValueInScope to streamline the code Added data-effect to trigger code on reactive content changes Fixed a slight regression in the visibility handling Reworked the IDE highlighting to be more robust and include effect
Always dotted lines… Please let me know what you think.
data-effect
The data-effect attribute introduces dynamic behaviours based on changes in the reactive data model. It executes the JavaScript code contained in its value every time any data changes occur.
In contrast, the data-content attribute is used to dynamically control the content of the HTML element. The value of data-content is a JavaScript expression that is evaluated, and the result is set as the inner HTML of the element. When the reactive data changes, the expression is re-evaluated and the content of the element is updated.
data-visibility attribute is used to control the visibility of the HTML element based on the value of a JavaScript expression. If the expression evaluates to truthy, the element's visibility is set to visible; otherwise, it is set to hidden. This check is re-run whenever the reactive data changes.
In summary, while data-content and data-visibility attributes affect an element's content and visibility respectively, data-effect executes custom code, enabling more complex dynamic behaviours.
Possible conceptual uses for the data-effect attribute in the context of Tumult Hype, here are a few possibilities:
Dynamic Animation Triggering: data-effect can be used to trigger different animations based on user interactions or application state changes. For instance, clicking a button could initiate a bounce effect on an image, or achieving a particular score might trigger a celebratory confetti effect.
Element Transformations: Depending on the user's actions, data-effect can transform HTML elements. It could enlarge text, rotate an image, or morph one shape into another.
Interactive Storytelling: In an interactive story or game, data-effect could be used to apply effects that enhance the narrative, such as fading the screen to black at a suspenseful moment, or creating a shimmering effect on a magical item.
Conditional Styling: data-effect can also be used for conditional styling, altering the appearance of elements based on certain conditions. For instance, when a user hovers over a button, the element could change color, opacity, border, etc.
Progress Indications: For elements representing progress, like a loading bar or a quiz score meter, data-effect could be used to animate these elements. The fill could animate from left to right to visually represent progress over time.
Feedback Mechanisms: data-effect can be used to provide visual feedback for user actions. For instance, a successful form submission could trigger a green checkmark to appear.
State Transitions: You can use data-effect to visually depict changes in state. For example, a switch being toggled could animate from one position to another.
Hover Effects: data-effect can apply different hover effects on an element. This could involve scaling the element up or changing its color.
Interactive Infographics: In an infographic, data-effect can animate data visualizations. For example, bar graphs or pie charts can animate to represent changing data.
Image Galleries: In an image gallery, data-effect can create slide-in, fade, or 3D flip effects when transitioning between images.
1.2.0
1.2.1
The CSS visibility property recognizes two states: 'visible' and 'hidden'. An element with the visibility: visible; property is displayed fully, while the visibility: hidden; property renders the element invisible while preserving its space in the layout grid. In the context of hierarchical elements, a visible child element remains so, even if its parent element is set to hidden.
In reactive content platforms like Hype Reactive Content, nested element visibility can present challenges. If a child element is designated as visible, it remains so, even if its parent element is hidden. To address this, the data-visibility property expression is used. Through chained expressions, conditions such as showParent && showChild can be formulated, ensuring the child element is displayed only when conditions for both parent and child are met.
The CSS rule [style*="visibility: hidden"] .inheritVisibility { visibility: hidden !important; } can be employed for managing nested visibility. This rule targets elements with inline visibility: hidden declarations, causing child elements with the .inheritVisibility class to adopt the hidden state. This approach offers a CSS-based solution without necessitating JavaScript linkages and maintains uniform visibility behavior across nested structures.
This rule.propagateVisibility[style*="visibility: hidden"] [data-visibility] { visibility: hidden !important; } imposes a more definitive behavior. Any child element with the [data-visibility] attribute will be hidden if its parent has the visibility: hidden style, regardless of their original visibility setting. This means all matched child elements are forced to adhere, providing less individual control.
Interactive Tutorial:
manageVisibility.hype.zip (425,7 KB)
1.2.2
The CSS rule
[style*="visibility: hidden"] .inheritVisibility { visibility: hidden !important; }
targets child elements with the .inheritVisibility class, making them hidden when their parent has an inline visibility: hidden declaration. This approach gives more flexibility since only children with this specific class are affected.
In contrast, this new rule
.propagateVisibility[style*="visibility: hidden"] [data-visibility] { visibility: hidden !important; }
imposes a more definitive behavior. Any child element with the [data-visibility] attribute will be hidden if its parent has the visibility: hidden style, regardless of their original visibility setting. This means all matched child elements are forced to adhere, providing less individual control.
I updated the above example as well.
Both rules avoid the need for JavaScript but offer different levels of specificity: one giving more control to individual child elements and the other asserting a broader, more blanket approach.
Sweetening Up Reactivity in Hype's customData
Did you ever feel like things got a little messy when reassigning Hype's customData? Well, those days are behind us!
Previously, if you tried:
hypeDocument.customData = {
chocolate: "dark",
gummyBear: "red"
};
You'd inadvertently lose the reactivity magic.
The workaround was something like:
// The old technique
Object.assign(hypeDocument.customData, {chocolate: "milk", jellyBean: "blue"});
Here's the good news! I've sprinkled some improvements, so now you can update your customData like this without any hiccups:
hypeDocument.customData = {
candyCane: "peppermint",
lollipop: "cherry"
// ... and so on
};
Indeed, with a nifty getter/setter now in place for the customData property, it ensures that all reactive behaviors stay active, no matter how you shuffle things around.
Refilling customData (and managing state in Hype's documents) has never been this seamless!
Before I finalize these changes on GitHub, I'd love for you to test it out and share your thoughts. Let's make sure everything's spot-on for everyone. Dive into the code, try it out, and let me know your feedback if something breaks for you.
HypeReactiveContent-13.hype.zip (85,4 KB)