oc Ability to return rendered html template

We've stumbled across the following scenario:

We want to write an e2e test a component
This component is designed to be primarily rendered on the server (SEO, perceived page load etc)
Running tests against the ~preview endpoint isn't ideal - it's not a true test as it's not what would happen on production (additionally we'd have to write waitFor type code to compensate for the client side injection process)

One possible solution would be to extend the Registry API to accept a custom Accept header (similar to what we do for unrendered components i.e. Accept:application/vnd.oc.unrendered+json) to just return the rendered html string. Example:

Normal request:

curl http://my-components-registry.mydomain.com/hello-world

{
  "href": "https://my-components-registry.mydomain.com/hello-world",
  "version": "1.0.0",
  "requestVersion": "",
  "html": "<oc-component href=\"https://my-components-registry.mydomain.com/hello-world\" data-hash=\"cad2a9671257d5033d2abfd739b1660993021d02\" id=\"2890594349\" data-rendered=\"true\" data-version=\"1.0.13\">Hello John doe!</oc-component>",
  "type": "oc-component",
  "renderMode": "rendered"
}

New "rendered html" request:

curl http://my-components-registry.mydomain.com/hello-world -H Accept:application/vnd.oc.rendered+html

<oc-component href=\"https://my-components-registry.mydomain.com/hello-world\" data-hash=\"cad2a9671257d5033d2abfd739b1660993021d02\" id=\"2890594349\" data-rendered=\"true\" data-version=\"1.0.13\">Hello John doe!</oc-component>

Thoughts? 😇

Mar 15 '17 09:03 matthewdavidson

I can tell you that in our case, often, we handle this scenario by having some kind of "skeleton" page that already includes the component by making a request to the component on the server side. This is because in our case the <oc-component> tag is often not enough, so we wrap it into a <html> page and have some more css, js, or other stuff to emulate the context the component will be within.

Nevertheless, I would be ok with a PR for what you are purposing. Would you be able to?

Mar 15 '17 10:03 matteofigus

I see. I guess alternatively it would be "convenient" to support something like this in the cli itself. Consumers could provide a template html file that you use to include global stylesheets, dependencies, containers etc. Something like oc test --template=path/to/my/template.html in teh component directory.

Btw I guess this is in some way linked to #407.

I'll see how we get on with creating a simple test harness which would live locally to the component code.

Mar 15 '17 14:03 matthewdavidson

I like that. Perhaps if component's package.json would have a oc.files.test = [{ 'testname': 'test.html'}] with test.html being something like

<html>
...
{{renderedComponent}}
...and/or
<oc-component href="{{baseUrl}}my-component?parameter=12345"></oc-component>
<script src="{{baseUrl}}oc-client/client.js"></script>
...
</html>

Then we could use that on the UI too to be used as preview too. Like //registry.com/component/1.2.3/~preview/testname?parameter=1234

What do you think? /cc @nickbalestra @chriscartlidge @mattiaerre @pbazydlo

Mar 20 '17 14:03 matteofigus

@matthewdavidson I am always interested in testing strategies; when you say e2e why you do not just exercise your environment that is hosting the component? in this case, you will be also able to see how your component behaves in the context where it will be embedded. Having said that a way of server side rendering the component at the registry level is not a bad Idea at all. I am proposing a different approach (just a random idea really): what about:

//registry.com/awesome-component/8.1.5/~ssr?start=2016-02-22

// cc @matteofigus

Mar 22 '17 16:03 mattiaerre

oc oc copied to clipboard

Ability to return rendered html template

oc
oc copied to clipboard