npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

test_truetoform_fit_widget

v0.3.11

Published

A widget for TrueToForm

Downloads

27

Readme

React(Vite) Fit Widget Project

file naming convention

  • kebab-case for file name that has more than one word
  • add extension to the file before the language ext(eg, .jsx)
button_component.jsx
capitalize.util.js
button.icon.jsx
button.stories.jsx

I hope this example demonstrates why using this naming convention is beneficial. It makes it easier to identify the type of file and its purpose.

It's also good practice to use the .jsx extension for any file that contains JSX, as it makes it easy to identify the content of files and gain an idea about the logic inside without opening them. Additionally, if you have icon extensions, it will make it easy to spot these files.

With this naming convention, it's okay to use a flat folder structure, but I think it's better to put some files inside folders when it makes sense, such as the lib folder containing atomic components (components that cannot be split into any other separate components).

I also think there is no need to create a components folder, but I'm open to other ideas about that. I just think we can put the components that are combinations of atomic components inside the src folder directly.

For pages/screens, we can put them inside the pages/screens folder, and the naming doesn't matter as much here. We can also use extensions like .page or .screen for these files.

The page components can have both kinds of components in the src folder or in the lib folder.

PropTypes

While it might seem tedious to write PropTypes for every component, it's really helpful for the team to know what props are required for the component and what type of data it should be. Additionally, it's helpful for the IDE to give you hints about the props that you should pass to the component. Moreover, it's really good for Storybook to generate controls for the props that you have in the component.

The linter requires all these rules except for the file naming convention. Sorry if this sounds like a lot, but I think it's really helpful to have these rules to ensure we have clean code overall.