joanniclaborde
commented
10 years ago I looked at handlebars and express3-handlebars, and there's no way to intercept partials rendering. Instead of parsing hbs files ourselves, we should use handlebars block helpers, they get called automatically by handlebars, for templates and partials. The comments block at the top of each partial would still be ignored by Solidus. A name argument can optionally be used to identify the resource in the global context.
Simple example
page1.hbs:
{{!
{
"title": "Page 1"
}
}}
{{#resource http://site1.com}}
{{site1key}}
{{> page2}}
{{/resource}}page2.hbs:
{{!
{
"title": "Page 2"
}
}}
{{#resource http://site2.com name="site2"}}
{{site2key}}
{{/resource}}/page1.json:
{
"title": "Page 1",
"resources": {
"http://site1.com": {"site1key": true},
"site2": {"site2key": true}
}
}With nested resources
page1.hbs:
{{!
{
"title": "Page 1"
}
}}
{{#resource http://site1.com}}
{{#resource http://site2.com}}
{{site1key}}
{{site2key}}
{{/resource}}
{{/resource}}/page1.json:
{
"title": "Page 1",
"resources": {
"http://site1.com": {"site1key": true},
"http://site2.com": {"site2key": true}
}
}With a preprocessor
This new method doesn't work well with preprocessors. Nesting 3 or 4 resources, then a preprocessor helper, just looks weird. Instead, the helper could accept a preprocessor argument. That preprocessor would be responsible to load its required resources, and would only return the resulting generated context.
page1.hbs:
{{!
{
"title": "Page 1"
}
}}
{{#resource complex.js}}
{{complexkey}}
{{/resource}}complex.js
var resource1 = solidus.fetchResource("http://site1.com")
var resource2 = solidus.fetchResource("http://site2.com")
return {complexkey: resource1.something + resource2.something}/page1.json:
{
"title": "Page 1",
"resources": {
"complex.js": {"complexkey": 123}
}
}
pushred
Storyteller Editor allowed resources (and preprocessor functions) to be defined in partials, which enabled self-contained blocks that were portable, easily inserted into any page. IIRC, resources were fetched, preprocesser functions were run, and a template was rendered with the resulting context within each partial before it was inserted into the parent page. For any partials that relied on a preprocessor this could be quite slow, especially considering that a fresh V8 environment was instantiated for each preprocessor via therubyracer.
While Solidus views can be used both as pages and partials, any page configuration is ignored when views are inserted into pages as partials. If a partial has any dependencies on particular resources and anything else the context must be passed to the partial as an argument, scoped where appropriate.
For example, given this context:
A partial that renders photos from a Facebook album would need to be inserted like this:
There’s definitely some merit to this approach, it’s evident what context partials have, and resources can be configured for the page. The downside is that if looking at the partial in isolation any API resource dependencies aren’t clear unless perhaps they are configured there for use as a page or comments are left. The resource must be setup manually regardless and can’t be updated centrally.
Reusability
The more significant downside is that this limitation doesn’t allow for the self-contained blocks we had in Storyteller. This isn’t so much of an issue within a single site, but we miss out on an opportunity with significant potential for enabling rapid development: reusing blocks across sites. Coupled with the versioning and distribution that npm/Git provide, we could reuse such blocks in the same way we do JS and CSS libraries.
Such blocks are essentially a more performant, highly customizable alternative to using iframes for such reuse. HTTP requests are kept to a minimum since the blocks depend upon assets in the parent site’s asset bundles. This also means the site’s assets can adjust CSS and interact with JS APIs as needed — iframes in contrast require serverside customization controllable via URL parameters.
Eventually Web Components will provide a better alternative altogether, but that’s still distant and doesn’t address API dependencies other than accessing them clientside. We should keep where those efforts are going in mind for our own solution however. CSS-Tricks has a good rundown of the details.
Recursive Resources
Here’s what a middleground between Storyteller Editor and Solidus might look like: