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

Add a linkchecker for the front end #963

Open
Julian opened this issue Feb 28, 2024 · 8 comments
Open

Add a linkchecker for the front end #963

Julian opened this issue Feb 28, 2024 · 8 comments
Labels
frontend-ux Improvements to usability in the UI internal Non-user-facing improvements

Comments

@Julian
Copy link
Member

Julian commented Feb 28, 2024

We should link check every link contained in the frontend UI with an automated link checker in order to catch broken links.

@Julian Julian added good first issue Good for newcomers help wanted Extra attention is needed internal Non-user-facing improvements frontend-ux Improvements to usability in the UI labels Feb 28, 2024
@JeelRajodiya
Copy link
Contributor

We can implement this using a GitHub action,
The same way we are currently doing in webiste, see this PR

I like to work on this issue

@officeneerajsaini
Copy link

@JeelRajodiya, yeah, that's a great idea. Also, we need to add Vercel to our repository so that anyone making changes can submit a pull request. This way, we can check their pull request's UI with Vercel's development environment before merging it into the main branch.

@Julian
Copy link
Member Author

Julian commented Feb 28, 2024

lychee -- which is the actual tool being used there, seems fine/nice -- but I don't really like the flow in that PR for the JSON Schema website -- specifically it's quite odd to have to spin up the website to do the link check.

I would hope there's some more "integrated" way to run lychee over the output of vite and/or React applications, so that it's simply a final step in the build process.

If you or anyone thinks they're able to can you investigate doing things that way?

@JeelRajodiya
Copy link
Contributor

lychee -- which is the actual tool being used there, seems fine/nice -- but I don't really like the flow in that PR for the JSON Schema website -- specifically it's quite odd to have to spin up the website to do the link check.

I would hope there's some more "integrated" way to run lychee over the output of vite and/or React applications, so that it's simply a final step in the build process.

If you or anyone thinks they're able to can you investigate doing things that way?

Sure! I'll investigate on that

@JeelRajodiya
Copy link
Contributor

JeelRajodiya commented Feb 29, 2024

I figured that our frontend is a single page react app. So when we build the project our index.html looks something like this

image
Link checker tools that are available on the internet checks for broken links inside a html or any other static files.

Structure of the build folder

image

The hyperlinks are available into the main html file when the javascript file is loaded and executed using the browser.

if we want to check for the broken links we'll have to run the build in a virtual browser i.e. something similar to lighthouse ( that will hydrate the index.html ) and then we can check for broken links from that index.html file using tools like lychee.

If we don't want to run a virtual browser, since the index.js file contains the links what we can do is write a script to check for broken links from the index.js file.

This index.js file

image

Example of links saved in the index.js file

image

@JeelRajodiya
Copy link
Contributor

JeelRajodiya commented Feb 29, 2024

I found a npm package puppeteer that can crawl a SPA (Single-Page Application) and generate pre-rendered content (i.e. "SSR" (Server-Side Rendering)).

I am thinking of this flow: First build the project -> run puppeteer to generate a static html file -> run lychee on the generated static html file

@JeelRajodiya
Copy link
Contributor

@Julian let me know if I should proceed or not

@Julian
Copy link
Member Author

Julian commented Feb 29, 2024

Thanks for the research -- I'm not fully thrilled with that kind of setup, but I don't yet have any other suggestion. Let's hold off for a bit then and I'll have to have a look at trying to find something that illustrates, or else I'll give up and we can go with something like that, but I want to look first.

@Julian Julian removed the good first issue Good for newcomers label Mar 1, 2024
@Julian Julian removed the help wanted Extra attention is needed label Jun 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
frontend-ux Improvements to usability in the UI internal Non-user-facing improvements
Projects
None yet
Development

No branches or pull requests

3 participants