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

[Discussion] Ideas to improve react-native-directory #188

Open
brentvatne opened this issue Apr 29, 2019 · 4 comments
Open

[Discussion] Ideas to improve react-native-directory #188

brentvatne opened this issue Apr 29, 2019 · 4 comments

Comments

@brentvatne
Copy link
Contributor

What should change about this project to make it more useful? Let us know!

@brentvatne brentvatne changed the title [Discussion] ideas to improve react-native-directory [Discussion] Ideas to improve react-native-directory Apr 29, 2019
@dabbott
Copy link

dabbott commented May 7, 2020

This is a cool project! I like the concept a lot, and it's already great for discovering libraries. I have a few misc ideas:

For discovery

  1. A Twitter account that posts a weekly or monthly digest of new libraries added (or with updates, getting popular, etc)

    I feel like I saw reactnative.directory at some point like a year or more ago and then forgot about it... if it were also a way to keep tabs on cool new libraries, I think I would find it more useful and it'd be more top-of-mind when I go digging for a library

For library insights

  1. Expose the react-native version(s) from the package.json

    I often peek at these to get a sense of health. Maybe it should go into the health score... although sometimes people will only have "*", so not sure.

  2. A 1-click Snack/Appetize where possible

    This would be AMAZING. I'm so much more likely to try a library with a 1-click demo. This could even be opt-in on the library author side... like a link in the package.json or extract any snack links from the README or something. Even if only a handful have it, it'd still be great.

  3. Automated tests that run against react-native@latest

    Not sure if this is realistic, but that'd be so cool. I mean, even just showing if a library has tests would be a useful health indicator. BUT imagine if it also had to pass a yarn && yarn add react-native@latest && yarn test. I know there could be other misc libraries that might conflict (e.g. expo not running on @latest), so it would need to be opt-in.

Misc

  1. Support GH emojis? No more :carousel_horse:

@brentvatne
Copy link
Contributor Author

A Twitter account that posts a weekly or monthly digest of new libraries added (or with updates, getting popular, etc)

I love this idea! Something we should explore automating for sure.

Expose the react-native version(s) from the package.json

I often peek at these to get a sense of health. Maybe it should go into the health score... although sometimes people will only have "*", so not sure.

I'm torn on the React Native dependency - I think this is often not very useful. If you use a fork (eg: people using managed workflow with Expo, and many people using React Native that are willing to get their hands dirty), you will get unnecessary peer dep warnings. If you use an alpha or rc release, same thing applies (npm/npm#8854). I'd rather there be some concept outside of peerDependencies that expresses version compatibility, but that's another topic...

A 1-click Snack/Appetize where possible

We actually have this already! It's the examples field in react-native-libraries.json. Something tricky here is that these go out of date pretty quickly as React Native versions change. Maybe it would be better if people provided a URL to a source file that we can load into Snack, so they can keep that up-to-date in their own GitHub repo easily and then we just pull it in to Snack and attempt to load it with the latest version (if the library and examples are kept up to date in the repo, this should be fine!). We do this in the React Navigation documentation - when you click to run an example in Snack we just pass the source URL to Snack and then it pulls it in. 💡

Automated tests that run against react-native@latest

Flutter's pub.dev actually does something like this 😮 Check out the score analysis tab for this random Flutter package: https://pub.dev/packages/android_alarm_manager#-analysis-tab-

Support GH emojis? No more :carousel_horse:

Yep! @jonsamp


To be totally honest, I don't have a lot of time to dedicate to this. I'm trying to get the ball rolling because it feels like there really is a gap here in the React Native ecosystem, but we could use some help. If anyone wants to get involved and work on the great suggestions that @dabbott provided please don't hesitate to reach out here or on Twitter @notbrent.

@YashM20
Copy link
Contributor

YashM20 commented Aug 21, 2024

Proposal

  1. Display Dependencies (Direct Dependencies)

    • Show the key dependencies that each package relies on.
    • Example: For @react-navigation/native, display its reliance on react-native-screens and react-native-safe-area-context.
    • reason: This helps developers to know which packages they need to install first.
  2. Package Size Information

    • Add information about the package size, including:
      • Minified size
      • Gzipped size
      • Impact on app bundle size
    • Rationale: Size information helps considering performance implications and make trade-offs between functionality and app size.

Schema Updates

It requires extending the current schema as follows:

{
  // ... existing fields ...

  // ... new fields ...
  "dependencies": [ ],
  "size": {
    "minified": "<SIZE IN KB>",
    "gzipped": "<SIZE IN KB>",
    "impact": "<ESTIMATED IMPACT ON APP BUNDLE SIZE IN KB>"
  }
}

What are your thoughts on this?

@dongsuo
Copy link

dongsuo commented Aug 22, 2024

The "Updated 1 month ago" comes from the Github repo. I suggest the time from npm would be better.

image

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

No branches or pull requests

4 participants