How can I help?

[ericdmoore]

I have been thinking about this for some time now.

Let me make a sample project, and while I do that, perhaps you can let me know how I can help?

from a Documentation Front there are:

• Examples/Examples/Examples to be shown
• how to connect to a content API
• how to add authorization to some pages?

from a technical perspective:

• Do you think your pre-render/build step could port easily to a CI service?
• So that the CI service gets pinged from content sources?
• What are your thoughts on adding a graphql normalization layer similar to gatsby?
• I think a graphql layer might add some awesome interop to having an API to hold my content (headless CMS) and then hyperstatic might have a sister project of an editor that could POST new content into my connected content API

Anyway, if you can't tell I think this is a great project! Let me make a sample site, and then we can see if there is any spot you would like help on.

find me on HA Slack or Spectrum

[loteoo]

Thanks for this! If I can get help on this project, it would definitively push me to work on it a lot further. I have a lot of ideas for hyperstatic and I'd really love external opinions and help on all of them. Definitively open to other ideas as well.

Examples/Examples/Examples to be shown

Definitively! I'm planning on having some docs on this repo and showing them on the demo site as well.

how to connect to a content API

Right now it's just by using a fetch Effect, but that might change later. I had the idea of using a custom hyperstatic Effect that:

• In development mode, fetches external APIs
• While pre-rendering, fetches external APIs, sends the data to the rendering script, which saves that data in a ready-to-use JSON file. (possible via puppeteer's exposeFunction)
• While running the built site: Uses the pre-rendered JSON files instead of the real API.

This would allow more stable sites, because right now you still rely on the external APIs even if your site is static.

I added this in v0.2:

import { StaticFetch } from 'hyperstatic'

export const Init = (state) => [
  state,
  StaticFetch({
    url: 'https://some-json-api.com/items',
    action: HandleData,
    error: HandleError
  })
]

Before rendering the site, HandleData hits the real API everytime. After rendering the site, HandleData receives pre-rendered data that was saved on built time (static json files with hashed names).

A StaticQuery Effect was also added:

ex:

import { StaticQuery} from 'hyperstatic'
export const Init = (state) => [
  state,
  StaticGraphQLQuery({
    url: 'https://my-graphql-server/graphql'
    query: `
      query {
        pizzas {
          name
          price
        }
      }
    `,
    action: HandleData,
    error: HandleError
  })
]

how to add authorization to some pages?

Nothing is implemented in hyperstatic to help with this right now, but the routes.js object signature could change in the future to allow something like Guards (like in angular, for example).

Ex:

import { adminOnly } from './guards/adminOnly'

export default {
  '/': import('./pages/Home'),
  '/public': import('./pages/PublicPage'),
  '/private': {
    component: import('./pages/PrivatePage'),
    guard: adminOnly
  }
}

Do you think your pre-render/build step could port easily to a CI service?

I think it already does pretty well? (On Netlify, at least, it works great).

So that the CI service gets pinged from content sources?

I think it would work the same way as it does with Gatsby. I think, you just need to be able to run a build command on some server. I don't think the limitations have to do with this project, but more with the infrastructure the developers are using. Maybe i'm missing something?

The project does have 2 hard dependencies thought: Parcel (code-splitting) and Puppeteer (Pre-rendering). I'm personally fine with this, but I could see how it could bother some other developers. Maybe there are some limitations I'm not seeing? What do you think?

What are your thoughts on adding a graphql normalization layer similar to gatsby?

I also think it would be great. I do think it should be "opt-in" thought. I think having a "tree-shakeable" GraphQL Effect would solve this. Again, I might be missing something thought. I had missunderstood the question. Right now, i'm going with the direction of this up to the user. Vanilla javascript + hyperapp API. I think normalizing the data layer would add a lot of complexity to the codebase and increase the learning curve. I prefer leaving this part open-ended. I think it's better if GraphQL is left as "opt-in".

Feel free to hit me up on slack as well, I'm only posting here to keep ideas open and get some feedback in!

Thanks!

[ericdmoore]

AMAZING! I have something to keep me spinning for a bit :)

[hlibco]

Hey @loteoo thanks for working on this project, it's great! I'm wondering if supporting routing files *.tsx is something on the radar or you'd appreciate some help with.

[talentlessguy]

@hlibco isn't TSX managed by the bundler? Parcel supports TSX and for JSX in Hyperapp you need to install a custom pragma, for example hyperapp-jsx-pragma or @hyperlight/jsx