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.

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

Renewal of Awesome Hono #4

Open
yudai-nkt opened this issue Apr 26, 2024 · 0 comments
Open

Renewal of Awesome Hono #4

yudai-nkt opened this issue Apr 26, 2024 · 0 comments

Comments

@yudai-nkt
Copy link
Owner

Below is a random note and will be updated as I remember something I was initially missing.

tl;dr I want to make full use of Hono and Cloudflare's capability.

In light of the concept below, I'd like to leverage Hono's newer features:

This website itself (snip) showcases how you can build a small application with Hono.

New features of Hono I'd like to leverage

  • static generation
    • Hono v4 has introduced SSG and it goes well with Cloudflare Pages' generous unlimited free tier of static assets
  • client component
    • This enables client-side interaction such as sorting/filtering entry tables. Given this comment in Hono's discussion it might be easier to use HonoX:

      It's hard to make hydrate mechanize client-side interaction with server-rendered pages.

  • built-in styling solution
    • I'm a fan of CSS Modules rather than CSS-in-JS or Tailwind, but hono/css would be a good choice for this specific project.

Dissatisfaction I'm having with current Awesome Hono

  • Depoly after new submission
    • Awesome products are currently listed in /public, which necessitates deployment when a new submission is made. I want to trigger new deployments only when HTML is changed.

data persistence

In order to resolve the problem described above, data persistence layer is required instead of the current static assets.

Considerations to be made

Given all the information above, here is the list of what I should take into account:

required

  • All HTML should be served as a static assets
    • Current / and /submission should remain the same and /:categoryId will be something like /categories?id=xxx (TBD)
  • New submission should not trigger a deployment
    • Entries should be retrieved at runtime
  • Submissions should be visible in the repository
    • that's how typical awesome-xxx works
    • much easier to track the submission history

preffered

To be updated

@yudai-nkt yudai-nkt pinned this issue Apr 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant