Add an sample-project or example folder which someone can view on Github and maybe download, or copy from cloned repo.

Or, for more convenience for a user, add commands to make it locally.

For example:

Setup skeleton project with the .js and public files but all empty. This would create content in the current directory. Let the user make the directory themselves.

npx hydrogen create-skeleton

Setup project using the content examples in README.md. Maybe flesh the examples out more to showcase advanced functionality.
npx hydrogen create-sample

• Add line for help. npx hydrogen -h or --help
• Add explicit lines for running the dev server. I am not figuring it out. npx dev ?
• Offer an alternative server. e.g. provide instructions to navigate to dist directory and start an http server with node.

Add to install instructions.

Link to the Yarn page which has install instructions on it.

And then a command npm install -g npx to install npx. Or the yarn equivalent if yarn will install npx.

Give both routes for devs - the yarn route and the npm route

Once you create a sample hosted site or some developers make some sites, link to them in your README.md as a showcase.

Is your feature request related to a problem? Please describe.
I would like to use files separately.
I don't like Single Files Components when I work with a team.
I need the designer and the layout artist work without knowing that we are using hydrogen o whatever framework.

Describe the solution you'd like
I want to import an html file an render it into hydrogen:
Ex:
const pageIndex = fs.readFileSync('./pages/index.html').toString()
const page = ({ data }) => pageIndex // 🤔 I don't know how to mix with string literals

Additional context
I need file separately because designers and layout artists can works individual without any dependency on each other.

Separate instructions into Installation and Usage sections. I usually have docs/installation.md and docs/usage.md which I link to on Docs section of README.md to keep it light.

You can have configuration of package.json in Installation, website / project layout in a Web Dev or Static Site Development section and move the build commands to a Build or Run section.

Cache template data

The goal of Hydrogen is to be as flexible as possible to all users, I figured the best way to make it even more flexible is to add build hooks which would allow users to do just about anything they can think:

Here are a list of Hooks that I want to expose via a file called hydrogen.hooks.js

exports.beforeDistRemoved = async (ctx) => {
};

exports.afterDistRemoved = async (ctx) => {
};

exports.beforeBuild = async (ctx) => {
};

exports.afterBuild = async (ctx) => {
};

exports.beforeEachPage = async (ctx) => {
};

exports.afterEachPage = async (ctx) => {
};

exports.beforeServiceWorkerGenerated = async (ctx) => {
};

exports.afterServiceWorkerGenerated = async (ctx) => {
};

I want to look into rebuilding Hydrogen for better modularity between the core "services", now that Hydrogen is gaining more and more traction each day, more features and ideas are coming into the pipeline. Making the project more modular can aid its rapid growth.

The main parts of Hydrogen are to:

1. Fetch page and layout templates
2. Merge page and layout templates
3. Execute Data, Head and Routes API
4. Save output to there corresponding HTML files

The Routes API has the potential to be at the core of Hydrogen due to its low-level nature of dynamically defining routes and selecting a template to pipe the data to. Essentially it would aggregate the data and dispatch to the template generator

hydrogen.routes.js

module.exports = async () => [
  {
    path: '/',
    data: {},
    template: '/templates/homepage.js'
  },
  {
    path: '/docs/creating-a-project',
    data: {},
    template: '/templates/doc.js'
  }
]

Hydrogen generates a structure very similar to the one above internally during the getPages() phase

In theory, if the Routes API gets built out, we can just define a pages structure and read from the structure and give that data to the Routes API in order for Hydrogen to build the routes to HTML

Add instructions (or functionality if it doesn't exist yet) to link in the JS between pages. e.g. How to link to page a.html or b/c.html from within index.html.

jekyll uses a page system for the link function, so you have to just know the path to the .md file in the project and it will figure out the HTML path for you.

In sample project, public, create src to contain thejs, css directories.
Or assets.

In the docs the header api is commonly used to insert script tags, this is not great, script tags should come last on the page

One working solution is of course to just write script tags into the layout or page template, but an alternative would be to have a footer api, which is exactly the same as the header api, which you can place at the end of your page instead. This would be more in line with the usage in the docs

Is your feature request related to a problem? Please describe.

I really like what hydrogen does. I'm looking to build a simple static site without client side rendering and there just aren't options that will take a list of paths, data, and a template and render it to an HTML file.

Hydrogen is the closest things I've seen, the only thing it lacks is the ability to explicitly define the template to use... instead it falls back to _index.js in the folder of the routes defined in hydrogen.routes.js.

While this solution works, it doesn't allow the user to use two different templates within the same folder of their site structure.

Such as having both /contact and /about.

Describe the solution you'd like
Reading over how getPages.ts works, I believe it should be doable to allow users to explicitly define the template to use.

Something such as would work well:

  {
    path: "/blogs/setting-up-a-service-worker",
    data: {
      post: 2
    }
   template: "/path/to/template/"
  }

This would allow the user to define their entire site in the hydrogen.routes.js file and then just worry about templates.

###Summary

Currently, Hydrogen does not delete the dist folder, therefore, it might be a good idea to add a property to hydrogen.config.js so that the dist folder is deleted before each build

Solution

module.exports = {
  build: {
    deleteFolder: true,
  },
}