fontsource / search-directory Goto Github PK

We seem to have major bugs when it comes to loading up the site on a smartphone (mine currently being an iPhone XS, but I'm sure other devices are being affected. I suppose we should look into it?

The main repository had a couple of breaking changes which would leave the docs to be outdated.

Would it make sense to instead pull and parse the markdown files from Fontsource directly since our docs change quite a bit and it might be a lot of work manually updating the directory constantly to keep up?

I want to implement fontsource/fontsource#79 soon as I think this project has matured enough and it's a good opportunity to actually reduce the size of our README.md. I want to move most of our documentation over to the site, which can then allow me to add a lot more in-depth explanations and examples (because I previously felt the README would become too long if I added a lot more).

I'm thinking of just Markdown docs that could add new pages to the documentation with a file structure such as:

-Installation
----Webpack
----Sass
-Variable Fonts

This way, we could add more pages if need be as we add more features and different methods of installation. It also allows us to be more organised with how we document differing parts of the project.

Then you would not need to process the README's of each font and instead, just let it act as a preview function with all the included supported variables? Maybe it'd also have a bit like yarn add @fontsource/<fontname>. I'll be removing a lot of the information on the package README's in favour of the docs hosted onsite.

What're your thoughts on this?

The website looks great so far, but on mobile devices, people might find it challenging to navigate around, especially on smaller devices.

• We need to make the navbar(font list) retract into the side on smaller devices and add a button to open it.
• We also need to make the font a little smaller.

Several fonts do not include a Latin subset, so a preview is not shown for them. Ex: YakuHanJP, Bayon, and Odor Mean Chey do not display a preview. This problem should be fixed so that users can get a feel of what the font looks like.

I've been thinking once we finish up with #62, we should migrate this repo into the main Fontsource monorepo under a new /website folder.

The main benefit I see is simply more exposure to our developer community which could lead to more issues being highlighted and possibly more pull requests being contributed. The website then becomes a more 'active' element of the Fontsource project. Other than that, it's mainly just housekeeping and organisation following monorepo fashion.

Things to do to make the change:

• Re-organise all the issue labels in the main repo to be more distinguishable for which platform is being addressed e.g. Platform: Website.
• Move over the repo
• Setup Vercel accordingly

Changes made to the website on the main repo will then always have to be facilitated with pull requests and reviews rather than committing to master like this repository though.

Having a direct easy access link to the Fontsource pages on each font would be useful to improve site experience.

e.g. Roboto
https://www.npmjs.com/package/fontsource-roboto
https://github.com/fontsource/fontsource/tree/master/packages/roboto#readme

The directory itself is looking great and just needs a little polishing. However, it would make sense for us to have an initial homepage of a sort to introduce the project and give context to random viewers.

Even as something as simple as this would serve to be useful: https://google-webfonts-helper.herokuapp.com/fonts

Feel free to assign this to yourself if you are addressing it, else I'll eventually pick this up after I'm finished with the implementation of variable fonts.

This is a suggestion that I could personally handle if approved by all other parties.

I believe it may be good for us to migrate over to Next.js as the base framework for the directory, rather than building our own tech stack from scratch. I don't believe the refactoring will be too difficult, and the beauty of Next.js is that it is fairly close to regular React code and is fairly easy to pick up without prior experience. It's just a change in organisation for a lot of files.

Main benefits for the transition:

• Reduce dependency management. No need to keep track and maintain Webpack and its large number of other dependencies (babel, loaders, etc.) via Dependabot or manually. Simply keep track of the sole Next.js dependency that manages the tech stack for us.
• Pre-optimised settings will likely lead to smaller bundles for viewers.
• TypeScript safety.
• Better developer experience with Fast Refresh.
• More sustainable and maintainable code that stays closer to industry standards over the long term.
• And all sort of small improvements and potential feature additions bundled with Next.

Something that can also simplify the whole directory implementation is relying on MDX, which also Next has the relative integrations for, to build all the pages and docs. Will need a bit more research into.

Deployment could also be simplified via Vercel, where we could get an Open Source partnership to gain access to all the team features without expense. The deployment will be pointed to the domain fontsource.org.

Thoughts on this @jwr12135?