Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Ability to return rendered html template #406

Open
matthewdavidson opened this issue Mar 15, 2017 · 4 comments
Open

Ability to return rendered html template #406

matthewdavidson opened this issue Mar 15, 2017 · 4 comments
Labels
enhancement Registry's API

Comments

@matthewdavidson
Copy link
Contributor

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? 😇
@matteofigus
Copy link
Member

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?

@matthewdavidson
Copy link
Contributor Author

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.

@matteofigus
Copy link
Member

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

@mattiaerre
Copy link
Member

mattiaerre commented Mar 22, 2017 •
edited
Loading

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement Registry's API
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@matthewdavidson @matteofigus @mattiaerre