I Built the ProjectGrid. It Still Doesn't Solve the Problem.
In April I wrote a post called I Shipped a Component Library. I Have No Idea If Anyone Actually Uses It.
For anyone who hasn't read that post, Projex is an npm library that renders a searchable, filterable grid of project cards from a config file.
Code review found twelve issues, the review agent asked if I could demo Projex in 60 seconds, I couldn't, and the conclusion was that the code wasn't the blocker. The first-time experience was. The fix I gestured at was a single component: <ProjectGrid>, one component that accepts the config and handles the data fetching internally. No manual async, no server/client split.
"The thing I need is something like a <ProjectGrid> component."
That was the unlock I named.
I built it. It shipped in Projex 1.4.0 on August 7th and it's live on npm, where the package went from 755 downloads in April to 143 last month.
Then I sat down and asked whether it actually did what I said it would.
It didn't.
What I actually shipped
Here's the component. Stripped down (the actual export is SmartProjectGrid; the April post called it <ProjectGrid>, so I'll keep using that name):
<SmartProjectGrid projects={projects} showSearch showFilters>
{(project) => <MyCard project={project} />}
</SmartProjectGrid>Vs the old way:
const [query, setQuery] = useState('')
const [tags, setTags] = useState<string[]>([])
const searched = useProjectSearch(projects, query)
const filtered = useProjectFilters(searched, tags)That's the diff. The April post described a component that handles the data fetching internally, no manual async. The shipped one takes projects as a prop. You still write the fetching code yourself. That part of the idea didn't survive.
The new wrapper saves you maybe twenty lines of boilerplate per page where you want a sortable, filterable, searchable grid. Real savings. Worth shipping.
It does not solve the demo problem. Not even a little bit.
What I thought the demo problem was
The April post framed the demo problem like this:
Here's what getting Projex running actually involves right now:
- Install it
- Write async data fetching code
- Understand that GitHub data only loads at build time, not dev time
- Wire up a server component for the data fetch
- Wire up a client component for search
- Deal with the server/client split
The conclusion was that this list is what blocks the 60-second demo. Six steps, server/client split, build-time fetching that doesn't show up in pnpm dev. None of that is the <ProjectGrid> fix.
What <ProjectGrid> actually does is collapse steps 4 through 6. It does not collapse steps 1 through 3. Steps 1 through 3 happen before any code matters. Someone lands on the npm page, reads the README, finds out the data fetching is manual and the GitHub data only loads at build time, and decides whether to install it at all. The wrapper component isn't visible at that moment. They haven't installed it yet. They're trying to imagine what their portfolio would look like.
If they install it, they get the wrapper. If they don't install it, the wrapper doesn't matter.
The wrapper helps the people who already decided they wanted it. It does not help the people who are deciding.
What I should have framed the problem as
The demo problem is not "the API has too many steps."
The demo problem is "I cannot show someone what Projex does without them first installing it."
To show someone what Projex does, I need a URL. A page on the internet that renders Projex output with real data, that doesn't require them to clone a repo, that doesn't require them to wire up a Next.js project.
The npm page is a README. The README is text. Text is not a demo.
The <ProjectGrid> component does not solve that. It cannot solve that. No component can solve that. Only a URL solves that.
I already had one. My projects page has been rendering straight from the Projex package since March, pulling its data from this blog's projex.config.ts. The April post links to it as proof the library works. I named a component as the unlock in the same post that linked to the actual unlock.
Where that leaves the component
In April I named the wrong thing. I named a component because Projex is code, so code felt like the answer. What I needed was something to send someone, and I already had it. The URL existed before the post did.
If I'd asked in April "can someone see what this does without installing it?", the answer would have been yes: my own projects page. I could have gone straight from that question to the Product Hunt launch, the thing the April post said couldn't happen without a demo. I asked "can I demo this in 60 seconds?" instead, which framed the answer as code I hadn't written yet. So I waited for code that was never the blocker.
The component itself is fine, for what it is. It saves maybe twenty lines per page for people who install Projex, and I moved this blog's catalogue onto Projex's own search, filter and sort helpers so the page and the library share one implementation. That's real. It was never the unlock.
So the next thing is a real demo site: a standalone URL whose whole job is showing what Projex does. This post is the soft launch of that idea. The demo doesn't exist yet. The post does.