Giter VIP home page Giter VIP logo

Comments (5)

donmccurdy avatar donmccurdy commented on June 28, 2024

Curation overhead aside, it's also a burden on authors to manually send PRs to our YAML file every time they do a minor or major release, and every time A-Frame itself does a release. So, I agree with the need to loosen up manual work required here. But if it was just that problem, we could deal with it by scraping NPM APIs better, and just having an expectation that package.json be maintained correctly.

I have two questions about your proposal:

  1. If we go in the direction of less curation, how do we deal with component decay? The awesome-aframe list suffers from that IMO, and a lot of the components there don't work on current versions of A-Frame. It might be reasonable to use a component's package.json to detect the version of A-Frame they declare as a peerDependency or dependency, and rank things lower if that's < stable. We could sort by github stars, or by downloads / month, or have some manually curated set of "featured" components, but still accept all submissions.
  2. What's the primary purpose of the registry?
    • If it's a standalone destination for discovering components, then yes, the curation and versioning is probably overkill.
    • If the registry is meant to serve the inspector, then IMO there are stronger expectations that components should actually work. We can't do much to rank more reliable components here, because discovery in the inspector is primarily via search. If there are a bunch of unmaintained and broken components, the inspector itself is going to feel broken.

from aframe-registry.

dmarcos avatar dmarcos commented on June 28, 2024

The purpose of the registry was:

  1. Help separate signal from noise by having a place where people can find good components (something that a simple google search won't give you). We knew that manual curation would not scale over time. It would be great to find a way to automate. Anything we can think of? Is there anyone that might help with manual curation for a while and help find ways to automate?
  2. Serve the inspector so it can be used as a playground to test and discover new components as @donmccurdy mentioned.

from aframe-registry.

ngokevin avatar ngokevin commented on June 28, 2024

Adding @kfarr since I think we've chatted about this. Loose thoughts:

Even when I curated the components, which is maybe the best case scenario, it still didn't stop component decay. I've asked around, I don't think anyone would have time + knowledge to curate. Yeah, I would have a small set of featured components and then a looser list under it.

At least if the components are listed in a visual form (e.g., seeing how recently it was updated, maybe add some package.json fields), it would give an extra layer of indication to their quality than awesome-aframe. While A-Frame is moving fast and breaking, we could let things loose for now, and look at baking things later.

The Inspector integration was one of the original purposes and was a neat idea. In practice, I don't find it as useful. It's a Select Box that gives names of components with not much more information. Many components will not work under the context of a 2D visual Inspector (e.g., controls, backend components, event-based components). If you find one, you'll still need to search for the script tag and include it. How often do people use that feature? I personally use Inspector as a way to pause the scene and get a different view of the scene.

I think a smoother workflow is to find a component on the Registry, include it, and if you find it useful and it works, then you can fiddle with the Inspector values if it makes sense to for that component. So I would want to move it more towards a standalone page, that we can point to and say "here's literally every single feature that was ever made, here's some that are really, and here's some that may work but are at least a good reference or place to file issues".

from aframe-registry.

donmccurdy avatar donmccurdy commented on June 28, 2024

That's fine with me. I do think that better indicators/sorting are necessary. The current health of components listed, or at least their likelihood of working via the inspector, needs to improve and I don't see room to loosen that up. But agreed we can improve things by means other than manual curation.

from aframe-registry.

ngokevin avatar ngokevin commented on June 28, 2024

OK, I'll think about it some more.

from aframe-registry.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.