Skip to content

Website Draft using Next.js, MDX, and TailwindCSS #2

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

Draft
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

Ethan-Arrowood
Copy link

This PR contains my current draft code for the Undici site redesign. It is built on Next.js, MDX, and TailwindCSS. It has a solution for the versioned docs issue, and includes some documentation to get folks started with it if they are interested.

As I expressed in a previous thread, I have limited capacity to work on this project right now. I'm very interested in exploring a crowd-funding model to support this development. I'm not entirely sure how that'd work, but open to any and all ideas. Otherwise, my contributions will continue to come infrequently and when I have the time.

@mertcanaltin
Copy link
Member

Can I work on this

@Ethan-Arrowood
Copy link
Author

Sure, you can send PRs to the ethan-site-draft branch and I will review

@AugustinMauroy
Copy link
Member

What do you thinks about having all page in tsx and catch segment when need markdown so use mdx-remote for parsing. and put markdown file inside content directory ?

@AugustinMauroy
Copy link
Member

On design +1 for giest.
And i recomand to use @tailwindcss/typography for content it's easy to use but for codox we will need something "more complex"

@ovflowd
Copy link
Member

ovflowd commented May 13, 2024

What do you thinks about having all page in tsx and catch segment when need markdown so use mdx-remote for parsing. and put markdown file inside content directory ?

This is unnecessary for Undici (maybe); it's probably a simple website, but I might be wrong. I do have this feeling we could "monorepo" the current Node.js website and export our current routing engines/etc to be used by other websites from the Node.js project 🤷

Copy link

vercel bot commented May 13, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
undici-website ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jul 19, 2024 4:47am

@mertcanaltin
Copy link
Member

@Ethan-Arrowood

Screenshot 2024-05-13 at 16 03 48

I centered the route items in the navbar

@AugustinMauroy
Copy link
Member

Here's a review of the design now that I've got a preview.

  • For the green we could use the tailwind css config from nodejs.org
  • But I think using another colour wouldn't be a bad idea to separate node runtime from undici http client. For example "teal" which is close to the current blue (docsify).

also for the icon I suggest using svg lucide icon can do the job otherwise on nodejs.org there are component icon that you can copy paste

@millette
Copy link

I was going to suggest starlight (based on Astro) but it looks like things have move forward with nextjs.

@ovflowd
Copy link
Member

ovflowd commented May 25, 2024

I was going to suggest starlight (based on Astro) but it looks like things have move forward with nextjs.

Doesn't look mature enough. It is only a 1-year-old project. The issue of using pre-defined "site generators" (or all-in-one solutions for making documentation websites) is that you're constrained to their framework/ecosystem. This is pretty much true for every case; using a foundational framework like Next.js or Astro allows the maintainers more control over it when it is a long-term project. Starlight could maybe work, as could Nextra or any other documentation builder out there 🤷, but usually, these projects quickly can become unmaintained and have short lifespans.

@anfibiacreativa
Copy link
Member

I was going to suggest starlight (based on Astro) but it looks like things have move forward with nextjs.

Doesn't look mature enough. It is only a 1-year-old project. The issue of using pre-defined "site generators" (or all-in-one solutions for making documentation websites) is that you're constrained to their framework/ecosystem. This is pretty much true for every case; using a foundational framework like Next.js or Astro allows the maintainers more control over it when it is a long-term project.

I have been using starlight for over 2 years in my own website. Although what you say is true, I'm not sure a migration -would it ever be abandoned- would result in more effort than any other framework maintenance or maintaining a custom navigation and site config(which is what starlight provides). I am a bit more concerned about the unsafe-eval CSP needed to enable the search Wasm module (that I have disabled in my site).

Is there a plan to create a backlog with issues to distribute work, created from this? #1

@ovflowd
Copy link
Member

ovflowd commented Jun 3, 2024

I have been using starlight for over 2 years in my own website.

Interesting, and my bad. For some reason their git repo shows as being 1 year old.

@ovflowd
Copy link
Member

ovflowd commented Jun 3, 2024

I'm not sure a migration -would it ever be abandoned- would result in more effort than any other framework maintenance or maintaining a custom navigation and site config(which is what starlight provides).

The main issue is maintainability. How many Node.js contributors have ever worked with such tech stack (Astro and Starlight) so by using it we limit tenfold contributions, including from newcomers.

Hence for large open source projects adopting React and possibly Next.js is a great combination due to its wast ecosystem, community and adoption.

@anfibiacreativa
Copy link
Member

I have been using starlight for over 2 years in my own website.

Interesting, and my bad. For some reason their git repo shows as being 1 year old.

To be honest, now I think about it, I integrated it later on, though I was using Astro all along. It may be that I'm confused. What was cool is that migrating from a regular .mdx implementation to the starlight powered one, was really straight forward. I see what you mean, though.

Co-authored-by: Augustin Mauroy <[email protected]>
@Ethan-Arrowood
Copy link
Author

Got around to making some changes tonight. Here is a summary:

  • Added Tailwind plugins @tailwindcss/typography and @tailwindcss/forms
  • I added some more styles to form the site a bit better and began tinkering with the <Sidebar />
  • Each top-level page is responsible for its own <main> tag. This enables different pages to have different layouts.
    • For example, the /docs page now displays:
      Screenshot 2024-07-18 at 22 23 53
    • And the home (/) page:
      Screenshot 2024-07-18 at 22 24 39
  • The <Sidebar /> component will ideally be a reusable sub-navigation for the documentation, benchmarks, and examples pages.
    • It should also be where the user can control the documentation version (remember this is tied to the URL)

I'm not sure where I want this PR to get to before we merge it and iterate. Ideally, I'd like to get the Sidebar navigation working (at least for some fake docs).

🚀

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

Successfully merging this pull request may close these issues.

6 participants