amphora-html 6.0.1-dev.0 → 7.0.0

package/docs/README.md

@@ -1,31 +0,0 @@
-# Clay Documentation
-
-On this directory, we have the pre-release documentation written using markdown. This file has the `.md` extension and as we mentioned before, these are pre-release if you haven't added a documentation version yet.
-
-## Markdown options
-
-These files have the following structure at the beginning of the file:
-
-```
----
-id: idOftheFile
-title: Title of your file
-sidebar_label: Title of the sidebar
----
-
-My new content here..
-```
-
-The previous example has a couple of the most important part to identify the content that you wish to add to your documentation. Here is a more detailed explanation on the [Markdown feature](https://docusaurus.io/docs/en/doc-markdown) that you can use.
-
-## Test documentation page
-
-We have a local server that we use to test your current docs content. Here are the steps on how to set the [local server](https://github.com/clay/amphora-html/tree/master/website#run-the-local-server). Normally you will have access on your browser with a url like this:
-
-`http://localhost:3000/amphora-html/docs/idOfTheDocs`
-
-But if you already have a [version](https://github.com/clay/amphora-html/tree/master/website#versioning-the-code) on your docs you will need to add `next` on your url
-
-`http://localhost:3000/amphora-html/docs/next/idOfTheDocs`
-
-[Here](https://docusaurus.io/docs/en/versioning) are more insights about what to do when you already have documentation with version.

package/docs/integration.md

@@ -1,93 +0,0 @@
----
-id: integration
-title: Integration
-sidebar_label: Integration
----
-
----
-## Basic Configuration
-
-First, ensure that you have a compatible version of Amphora installed (v3.x or greater) and require `amphora-html` from wherever you are running Amphora.
-
-```javascript
-const amphoraHtml = require('amphora-html');
-```
-
-Second, register a `rootPath` with the renderer. This will allow the renderer to reference your components directory and static assets directory properly. Usually this is the root of your project, but that may not be the case for your implementation.
-
-```javascript
-// Register a root path for Amphora HTML
-amphoraHtml.addRootPath(path.dirname(path.resolve('./package.json')));
-```
----
-## Handlebars Helpers
-
-If your templates require any custom [Handlebars Helpers](http://handlebarsjs.com/block_helpers.html) you can register them with the renderer's Handlebars instance. Simply pass in an object whose keys are the names of your helpers and whose values are the helper themselves. Like so:
-
-```javascript
-// My helpers
-const helpers = {
-  // set up handlebars helpers that rely on internal services
-  'nameOfHelper': () => {
-    // helper that does something you need.
-    return 'foobar';
-  }
-};
-
-// Register helpers
-amphoraHtml.addHelpers(helpers);
-```
----
-## Amphora HTML Plugins
-
-Amphora HTML plugins let you read and modify both the data sent to Handlebars and the HTML returned by Handlebars. An Amphora HTML plugin is an object with a `render` function that returns a modified `data` object and/or a `postRender` function that returns the rendered HTML string:
-
-```javascript
-
-module.exports.render = (ref, data, locals) => {
-  // you have the option to mutate `data` here
-  // do **not** attempt to mutate `locals`
-
-  // return `data` or a promise for `data`
-  return data;
-};
-
-module.exports.postRender = (ref, html, locals) => {
-  // you have the option to mutate `html` here
-  // do **not** attempt to mutate `locals`
-
-  // return `html` or a promise for `html`
-  return html;
-};
-```
-
-You can add Amphora HTML plugins like this:
-
-```javascript
-amphoraHtml.addPlugins([
-  { render: plugin1 },
-  { postRender: plugin2 }
-]);
-```
-
-One use case for Amphora HTML plugins is to skip rendering of certain components depending on query parameters, which are available in `locals.query`. Amphora HTML plugins do not run when rendering for edit mode.
-
----
-## Register Amphora HTML with your Amphora Instance
-
-Now that you have registered any helpers and plugins and have provided a root path which Amphora HTML can work from, you can register your renderer with Amphora. Registering consists of providing a `renderers` object whose keys are the extension of an HTTP request and whose values are the renderer. You can also specify a `default` property whose value is the extension that Amphora should default to when rendering. This is handy for rendering routes who don't end in extensions, such as `mycoolsite.com/about/`.
-
-```javascript
-return amphora({
-  app: app,
-  renderers: {
-    html: amphoraHtml,
-    default: 'html'
-  },
-  providers: ['apikey', amphoraProvider],
-  sessionStore: redisStore,
-  plugins: [
-    amphoraSearch
-  ]
-});
-```

package/docs/intro.md

@@ -1,21 +0,0 @@
----
-id: intro
-title: Amphora HTML
-sidebar_label: Amphora HTML
----
-
----
-The HTML renderer for Clay components that use [Handlebars](http://handlebarsjs.com/) templates.
-
----
-## Why?
-
-HTML rendering was controlled entirely by [Amphora](https://github.com/nymag/amphora) in __v2.x__, which meant that Amphora was responsible for a lot of heavy lifting. Furthermore, rendering was handled by a module called [Multiplex Templates](https://www.npmjs.com/package/multiplex-templates) which did some :crystal_ball: dark magic :sparkles: to synchronously render component templates. This required some affordances from Amphora which added to the weight of the middleware. By separating renderers out into separate modules which can be plugged into Amphora __>v2.x__ we can create renderers for specific requirements (XML, Amp, etc.) _and_ the rendering process can be moved to separate machines to create more maintainable systems.
-
----
-
-## Installation
-
----
-
-`$ npm install --save amphora-html`

package/docs/style.md

@@ -1,47 +0,0 @@
----
-id: style
-title: Styleguides
-sidebar_label: Styleguides
----
-
----
-
-
-On `amphora-html` using the `data` and `meta` object that are instances of the components and site respectively. This site will expose the component variations on the state, then it will set these variations into a structure. Finally, [Kiln](https://docs.clayplatform.com/clay-kiln) will need then render the `HTML`. 
-
----
-
-## Get component variations
-
-Using the site name, `amphora-html` builds the specific style path that we need to have all the required stylesheets: 
-`styleguides/siteName/components` 
-
-If the name of the site is not available, the `siteName` property will be replaced for `_default` and the list of the variation of the components will be returned.
-
-If a component variation exists, we will receive a combination of the name of the component and the name of the variation separated by an underscore like this example: `componentName_variationName`
-
-Furthermore, if the component variation is no set we will have the name of the component as a default style.
-
-For more information on how to get the variations, you can check the [styleguide.js](https://github.com/clay/amphora-html/blob/master/lib/styleguide.js) file on the `amphora-html` repository.
-
----
-
-## Set component default variations
-
-After getting the list of the variations exposed on the state (or set on the data object that we receive), we can go through each component defining its default styleguide. The following are the conditions that we have to define in order to determine which is the variation that we will add:
-
-- The component has a variation set, but it doesn't exist in the site's styleguide or the default styleguide; render the component with the default variation.
-
-- The component has no variation set; render the component with the default variation.
-
-- Finally, if the other conditions don't match to the current component, it means that we have a component variation defined and we are using it.
-
-For more information on how to set the variations, you can check the [styleguide.js](https://github.com/clay/amphora-html/blob/master/lib/styleguide.js) file on the `amphora-html` repository.
-
----
-
-## Compose data
-
-After we got and set the variations on the components, we are going to compose the data into the structure that [Kiln](https://docs.clayplatform.com/clay-kiln/) needs; we got to this step after we finished getting all the variations of the components that are in the `data` object that we mentioned before and use it on [Kiln](https://docs.clayplatform.com/clay-kiln/).
-
-For more information on how the kiln structure is formed and send; you can check the [render.js](https://github.com/clay/amphora-html/blob/master/lib/render.js) file on the `amphora-html` repository.

package/lib/log.test.js

@@ -1,42 +0,0 @@
-'use strict';
-
-const dirname = __dirname.split('/').pop(),
-  filename = __filename.split('/').pop().split('.').shift(),
-  lib = require('./' + filename),
-  clayLog = require('clay-log'),
-  fakeLog = {};
-
-describe(dirname, () => {
-  describe(filename, () => {
-    describe('init', () => {
-      const fn = lib['init'];
-
-      test('initializes a logger when non-exists', () => {
-        fn();
-        expect(clayLog.init.mock.calls.length).toBe(1);
-      });
-
-      test('returns if a log instance is set', () => {
-        lib.setLogger(fakeLog);
-        fn();
-        expect(clayLog.init.mock.calls.length).toBe(0);
-      });
-    });
-
-    describe('setup', () => {
-      const fn = lib['setup'];
-
-      test('calls clayLog.meta with a default when provided no meta', () => {
-        fn();
-        expect(clayLog.meta.mock.calls.length).toBe(1);
-        expect(clayLog.meta.mock.calls[0][0]).toEqual({});
-      });
-
-      test('passed meta through to clayLog.meta', () => {
-        fn({hello: 'world'});
-        expect(clayLog.meta.mock.calls.length).toBe(1);
-        expect(clayLog.meta.mock.calls[0][0]).toEqual({hello: 'world'});
-      });
-    });
-  });
-});