Is there a way to use one core, reusable hype library and then use smaller, more lean resources that use it?

1

I am thinking of a server scenario, where I may have literally hundreds of hype files. in this scenario, I would only want to repeat what is needed (keep it DRY) and hydrate the unique parts to each hype file.

in this scenario I imagine that the main_hyperesources would contain the repeatable data, and then the individual resources folder would contain the folder for each item, and inside that folder javascript resource and .html resource that refers to it.

possibly like this?

public/main_hyperesources/individual_resources

-- where main_hyeresources has the required hype generated libraries

--- first_hype_file.html
---first_hype_file.hyperesources

---next_hype_file.html
---next_hype_file.hyperesources

and where each of those hyperesources points to main_hyeresources for the basis and then handles each of their individual needs.

any ideas? has this been created already?

**also, not sure how to categorize the question. doesn't quite fit in with data extension, doesn't quite fit in with javascript. hope this can still be answered and if someone has a suggestion of where this should be posted, please let me know and I will update the post **

2

Built in methods… use a CDN version for the runtimes (found in advanced exports).
Looking at the request from an editor perspective… this would be hard to achieve as there is no easy way to override the origins of resources in the editor. Once exported or previewed you can use the Hype Event …

Hype Resourceload

You could load a list of resources that should be overridden from a shared JavaScript include containing something like this:

function HypeResourceLoad(hypeDocument, element, event) {
	var file = event.url.split('/').pop();
	switch (file) {
		case "whatever.png":
		case "other.png":
		case "example.png":
		case "testing.png":
			return "https://my.shared.url/main_hyperesources/"+file;
			break;
	}
}

if("HYPE_eventListeners" in window === false) { window.HYPE_eventListeners = Array(); }
window.HYPE_eventListeners.push({type: "HypeResourceLoad", callback: HypeResourceLoad});

You would still want to have some sort of representation in Hype because these files would be needed for the editor preview that can't be easily changed… but they would be used once published.

2 Likes
3

To be a bit more "high-level" about it, at some level you need knowledge on which resources are individual and which ones are shared across different documents.

@MaxZieb's answer basically puts all of that knowledge in the code for the switch statement with the HypeResourceLoad callback. Export scripts have a similar non-runtime way to change resource locations, but probably is a bit harder to use.

Because having this knowledge can be a pain (requires constant updating and code modifications), I think what most folks do in this scenario is put all of their resources into a single merged folder. This means:

  • You have to make sure that unique resources are uniquely named across your documents
  • For user caching benefits, you need to make sure that shared resources are named the same across your documents
  • You will need to manually edit the resources folder name in the .html exports to match to the single shared folder
3 Likes