For example: https://github.com/yields/isArray has build status but http://localhost:4000/yields/isArray just has some html text

rework and templates

somewhere

not sure the best way to do this, but since a lot of components are UI-related, it'd be really great to have a place to play around with live examples.

some assumptions would probably have to be made about how to create examples, but I think the community is flexible enough to adopt some sort of standard practice.

that @ForbesLindesay has working

what component is how it works blah blah

https://github.com/visionmedia/ci-badge

when the other stuff is done. ideally a smaller badge for the listing

As brought up in #30 it would be pretty useful to have a static version of each and every site abailable. At least the index and component pages should be available without ajax.

for repos and component itself

not actually too fond of grids, they're distracting when you actually want to read through

Unless you're already aware, or working on something, thought I'd let you know the site is currently down.

http://component.io/

502 Bad Gateway

Might be related to the recent commits.

Not sure if this is a known issue...if it is, obviously disregard; however, this is the situation:

https://github.com/component/spinner

Hello,

How can I actually add my component projects:

• View
• Router

I looked through the code but do not find anything that serves http://component.io/components.

usually use varnish but I have nginx setup already so things need to be configured

Maybe we should sort the components by stars. Would be user-friendlier.

What do we do with too many keywords?

1. Limit the array to a certain length
2. Automatically cut them off with extra css and extra wrapping markup (overflow: hidden)
3. Same as 2 but on :hover make the cut off keywords visible.

It would be very possible to build a version of conponent-builder that streamed the resulting file, This would run pretty slowly, but extremely scaleable. Do we want to do that?

not a big deal right now but once we have more components the initial dom junk will be pretty heavy if we dont do an infinite scrolling sort of display

...do you care?

We're going to need some clever caching and a good way to invalidate our caches. The home page and the listing pages for each user (/:user) will require us to send off hundreds of requests to github to render just one page, so we really need to sort out a good strategy for caching and invalidating that cache.

We could work on the bases of keeping all/most caches valid for a very long time (perhaps several hours) and then add a route:

app.all('/:user/:repo/invalidate-cache', function (req, res) {
  //invalidate cache here
});

That way people could tell us when our cache needs updating using a GitHub hook.

For building our components we really want to cache each component once, we don't want to duplicate for every component we build that has it's own dependencies, so the build will have to be somewhat customised relative to component(1)'s current method of building.

"touch" should display fastclick which has "Polyfill to remove click delays on browsers with touch UIs." touch right in the description

not that we even really have pages... hmm.. haha

similar to http://plugins.jquery.com/selectify/ but not super ugs

branch, with actual pages / info etc.

only really need css / js, parse md on the server when priming the cache and parse the code blocks with pygments

Now that I've actually experienced publishing a component to the component(1) registry and npm and bower (some people are into that, so why not), I'm noticing that better tooling to automate some of the tedium would be nice.

Like, when I bump the version, it's kinda annoying to have to do it in {package,component}.json as well as bump History.md.

I realize that the tool shouldn't do everything for you; however, something to at least convert one json format to the other might be a good idea even if it is only useful for some folks.

slide out contents, this makes a few things a bit easier, and a bit less "shock" when your search results are suddenly gone. This may have implications once we implement search pagination (even when infinite) however.

This is happening for a few days now so I'd let you now:

When I enter the site I see the compment list as expected but when I search I get:

Sorry, no results for that query! Try again!

If I look in the dev console I see the search api is status 404:

Request URL:http://component.io/components/search/json
Request Method:GET
Status Code:404 Not Found

The response data is an empty array.

This is on FireFox 22.0 and Chrome in Windows.

to make the differences clear between various solutions out there and the pros/cons of each

firing per char is lame

Should spit out a list similiar to / but filtered by the author name.

to individual repos (# of deps / dependents etc), and global stats like our author count, component count, counts per category etc

from the wiki, some inspiration:

http://www.unheap.com/section/inputs-forms/input-sliders/

having images like that would be cool but we would have tons of unpopulated ones

inception:

I propose the following site structure:

/ => The site's home page should contain a listing of all available components (paged if need be) with a search box and links to a few other key parts of the site. The components in this listing should display their license and number of stars on GitHub. They should be grouped by category based on the wiki, and sorted by number of stars in GitHub, then alphabetically within that.

/about => this userID is not available in GitHub, I think it should contain an introduction to Components + a Getting Started guide with accompanying video and a few sample projects in GitHub.

/:user => should show a listing of all the components a given user has produced, it should look very much like the one displayed on the home screen.

/:user/:repo => The primary listing page for each component. It needs to display some key info about the repo: browser compatibility based on automated tests, License, number of stars, dependencies, dependants, installation instructions/links to different pre-made builds. I would like to also display the readme with an automated table of contents so that this can be used as the home page for most components.

/:user/:repo/download => Listing for downloads of the component. This should include minified and unminified. standalone builds of each version of the library, it should also include a build of the library that doesn't include any dependencies or the require script so that you could have:

<script src="https://component.io/require.js"></script>
<script src="https://component.io/foo/bar/download.js"></script>
<script src="https://component.io/foo/baz/download.js"></script>
<script>
  var bar = require('bar');
  var baz = require('baz');
</script>

We need to decide exactly how we structure the URLs for download links. We need to have at least one link to the latest standalone unminified build as that will allow us to get most of the components submitted to microjs.com (see microjs/microjs.com#344)

/component-badge.svg => should serve the SVG for the component badge:

Anyone got any to add/not like any of these?

On the generated README.md files, [foo](/dist/foo) is translated into http://component.io/username/dist/foo, resulting in a 404, when it should be forced to be resolved into http://github.com/username/dist/foo.

Hello,

I am wondering why you components do not seem to require their templates to be precompiled to javascript?

https://github.com/component/component.io/blob/master/lib/list/component.json#L11

If I do this I am always getting an error "Failed to require..." (as I did not add them to the script array).

Sorry if this does not fit well to be an issue....

Bodo

what do you guys think ?
component-graph

it's kinda annoying to have to download it in order to run it, and i think even if it had it's own domain it will be annoying too.

Here's a concept for the search box that makes it accessible all over the site, and still not that intrusive. Basically there's a small fixed row at the bottom of the page that's always there (a slightly darker color than the current page, so it looks recessed) and it's the component index. Clicking it would make it expand, taking over almost all of the screen (up to the top navigation, which will always remain visible).

If you don't already know what component is and how to use it, going to http://component.io/ does not help with that in any way.

migrated from componentjs/component#398