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

chore: migrate clayui.com to next #5780

Open
wants to merge 137 commits into
base: master
Choose a base branch
from

Conversation

matuzalemsteles
Copy link
Member

https://clay-clayui-com.vercel.app

Well this is a POC that implements the design that I presented a few years ago but still incomplete from clayui.com with the idea of also bringing better documentation for taglibs and improving the existing documentation for React, HTML, CSS and tokens... many of these details were not implemented because it requires a little more work, mainly due to the way we organize the documentation files, which deviates a little from Next.js pattern.

But the idea here is to demonstrate how we can simplify the current implementation today of clayui.com by migrating from gatsby with next.js. There are some things that we would need to implement due to the way we deal with organizing files for documentation. I also didn't go ahead with the integration with LXC because I would need to decide first how we would organize the documents and this affects the route structure but in the end this would be a dynamic route making a call to LXC this would be simpler than in Gatsby which we need organize the data before creating the page.

Another detail is that we can get rid of the thousands of plugins that exist in gatsby that we had to create, which created high complexity for new developers if they want to change or add new things. Next.js also has a better build time because it is incremental, which is a huge benefit for those of us working on documentation.

ISR

ISR is a feature not necessarily from Next.js and Vercel but something that is implemented as a feature and is easy to use, this means that even if we have dynamic routes with LXC they can become static routes and as soon as some content changes we can trigger a revalidation of this page in the background dynamically without the need for a build. There are also other ways of revalidating the page cache such as time, we can define a time if we want to make things simpler, that would be an option.

File System

Well, Next.js creates routes based on the file system within the app folder, this is a rule for not only creating routes but also for features such as route streaming, error catching, loading... how we organize documents of the components in each package this would maybe change a little, I'm not sure if it would be possible to do it the same way we do in Gatsby this would change some webpack configs I think this is possible but I don't know how the document routes would work, I would need to investigate this more in depth.

MDX

All documents are treated as MDX files so we would move all md files to mdx, we already use mdx files on the current site this wouldn't be a problem.

Currently the Sidebar is created manually, we would need to implement the mechanism to obtain this dynamically so as not to need to add it manually or we can keep it manual so we can organize it the way we want as it is in the DEMO.

Platform

Well, using Next.js also means that we would have to use Vercel unfortunately if we want to avoid problems with builds or surprises... one point is that Vercel's costs seem to be better than Netlify.

Design

This Design is something I worked on some time ago and presented in a document about restructuring the documentation with the intention of improving the Table API, taglibs and component documents.

An important point about this was the idea of building a Table API with more information and also allowing developers to better explore what we expect from the data in a prop.

Another important part is that I am dealing with the website design in a different way with the isolation of the website's CSS to the Clay CSS, this prevents the website's CSS from impacting the document or things related to Clay, we have already had problems with this in clayui .com and I realized that there are still some very subtle ones.

@matuzalemsteles matuzalemsteles requested a review from ethib137 March 8, 2024 18:49
@matuzalemsteles
Copy link
Member Author

Just an update on this, last week I found a library called mdxts that brings some resources for documentation that we could use here that solves some problems I found, so we can keep some things:

  • Organization of current documents can be kept in packages
  • We don't need to maintain the manual sidebar
  • We can improve the code block experience by inferring component types
  • We don't need to create the Table API from scratch

@matuzalemsteles
Copy link
Member Author

Well, I sent the commit that implements the use of mdxts to load dynamic documents using the document structure we have today, but it required some changes. It also adds the dynamic Sidebar without having to make manual changes, and an initial implementation to render the Table API still needs adjustments to load the different types of components, which is still causing a bug.

With this change, we no longer need to create a separate file to create the examples of the components to render in the document; the table of contents is also generated automatically.

At this point, I am only updating the documents for the clay-core package, but I will work on updating the other documents and loading the documents from the other packages. After that, I will be able to work better on the Table API.

The site preview is broken because I need to better configure the build in Vercel and it is having some problems because the build root is the site folder but it needs visibility of the files outside of it. But it is working fine in dev when testing locally.

@ethib137
Copy link
Member

ethib137 commented Aug 9, 2024

Thanks @matuzalemsteles ! How can I test this. When I run yarn dev from the www folder I'm not able to access any of the component docs. For instance http://localhost:3000/docs/components returns a 404.

@matuzalemsteles
Copy link
Member Author

How can I test this. When I run yarn dev from the www folder I'm not able to access any of the component docs. For instance http://localhost:3000/docs/components returns a 404.

@ethib137 oh the link is broken sorry, I have to add a redirect. You can access http://localhost:3000/docs/introduction/how-to-use-clay and then continue browsing.

@ethib137
Copy link
Member

Thanks @matuzalemsteles this is looking good. One thing I noticed is the interactive component preview took quite a bit longer to load then it does currently. I thought maybe that's just cause it's on a dev server so I tried, yarn build and yarn start to see if it was faster. Currently both of those commands are failing for me though. If they are working on your side, let me know and I'll share the error messages.

@matuzalemsteles
Copy link
Member Author

matuzalemsteles commented Aug 12, 2024

One thing I noticed is the interactive component preview took quite a bit longer to load then it does currently.

@ethib137 Unfortunately this comes from Codesandbox. We use the sandpack that allows us to create component views with the editor and the user can open it in a Codesandbox environment. I tried to use some of the features they have to speed up the loading time but it's not working because it's still experimental. I'm thinking about going back to our old editor without this Codesandbox support. I also found this very slow, and it gets slower because we have to add the component dependencies.

Currently both of those commands are failing for me though. If they are working on your side, let me know and I'll share the error messages.

Oh yeah, this is still failing due to external dependencies, I'm looking into that as well.

@matuzalemsteles
Copy link
Member Author

@ethib137 the build is now working fine on Vercel. https://clay-clayui-com.vercel.app/docs

@ethib137
Copy link
Member

@ethib137 Unfortunately this comes from Codesandbox. We use the sandpack that allows us to create component views with the editor and the user can open it in a Codesandbox environment. I tried to use some of the features they have to speed up the loading time but it's not working because it's still experimental. I'm thinking about going back to our old editor without this Codesandbox support. I also found this very slow, and it gets slower because we have to add the component dependencies.

hmm... that makes it a tough choice. The open in codesandbox functionality is really quite nice, but the load time is quite annoying.

@matuzalemsteles
Copy link
Member Author

hmm... that makes it a tough choice. The open in codesandbox functionality is really quite nice, but the load time is quite annoying.

Yes, I tried using the url bundler which they say is much faster but unfortunately it doesn't work for our use cases. https://sandpack.codesandbox.io/docs/advanced-usage/bundlers

@matuzalemsteles
Copy link
Member Author

I have submitted the latest changes to the documentation that adds the Table API to all components. I need to make some adjustments to the Table API design for some use cases.

Well, there is still an issue in the build that is being affected by memory leaks due to the plugin and the way I configured it to work in our use case. I would have to rethink this so that it can load all types of components without overloading.

I am now working on adjusting the site design to work on mobile as well and adding the integration with LXC. Then I will come back to this again from the Table API build with mdxts and we will be practically ready to migrate. I will also leave it for last to resolve the file conflicts.

@matuzalemsteles
Copy link
Member Author

Well, the integration with LXC has been done, now I will go back to fix the bug in the mdxts plugin that is having memory leak and overload problems that are preventing the site from being built. To test locally, it is necessary to comment out some lines of the packages to reduce the overload

createSource('../packages/clay-badge/src/**/*.tsx', packagesOptions),
.

I will also fix the conflicts after that we will be ready to migrate the site, tomorrow I will make some adjustments to the content as well. I hope we can complete the migration by Thursday or Friday.

@ethib137
Copy link
Member

Nice Work @matuzalemsteles ! Thanks for the updates!

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.

2 participants