Finding knowledge is not hard. Putting it all together is.

The reason why I made topheman/npm-registry-browser

In software development, a lot of great quality resources are available, often for free. I’ve been getting feedbacks from developers – at work, online, at meetups – who shared that the hard part is not finding the knowledge but picking one library over an other or putting them all together.

Tutorials explaining a specific problem are all over there, what’s missing is projects examples / courses with a wider point of view.

This is what I decided to do in my latest project: topheman/npm-registry-browser. I respect some constraints that you would get, developing a real-world application, such as:

• external API calls
• using external libraries (UI kits, router, http clients …)
• project setup for development with teams
• code quality (linter, code formatting)
• tests (unit / end to end)
• automation / dev pipeline

The project itself is a Single Page Application that lets you search for packages in the npm registry and show details for each one of them such as the readme, the versions, the stats … In fact, this project is just an excuse to expose how to put together all those technologies I mentioned above.

The source code is available on github. You can test a demo online. I will be adding more features in the next weeks.

TRY IT

PS: This project is based on create-react-app and remains unejected. It was a constraint I imposed myself from the start. I never used CRA before (I have my own webpack starter-kit), so I wanted to test it to be able to tell what’s possible to do with it and what is not.

PPS: I chose not to use Redux, at least, not in that first version because … You might not need Redux (explanation) …

📺Watch video of the talk (fr)

This post was originally posted on my blog.

Comments

[Benito Serna]

Nice work! ... I have been thinking in that also (tutorials vs projects)... I have been trying to teach what I think I know jaja... but is hard to find the best way to do it... and once you decide for one, is hard to actually do it!!...

I like how you are working to explain your decisions in the Readme... and just as a humble advice... one thing that could help the people that visit your project is to now the process that you use to tackle a new feature... like a little tutorial inside you project (I know this is what you want to avoid jaja), but just to know how they can add more code to software written in this way =)

Keep the good work!

[Tophe]

Hie Benito,

Thx for the comment. As you understood, the goal of that project is to provide a project where you can find out how you would put all the bricks together (have a real example).

I intended from the start to make some blog posts and talk about some specific features. It will come along.

Meanwhile, I took some notes about some problems I stumbled upon and how I fixed them. It's available there : github.com/topheman/npm-registry-b... - maybe I should highlight it more in the README ...

[Benito Serna]

I didn't see that page!... I will check it out =) ... Thanks

[Víctor Adrián]

That's one of the reasons I like writing tutorials:

I have found there are mainly two types of tutorials one should write:

• Scoped, focused tutorials.
• Full step-by-step tutorials.

Scoped, focused tutorials, should be used to explain techniques, like this one: Fluid SVGs with Vue.js.

But, full step-by-step tutorials should be used to teach about new tech stacks.

Going from zero to fully working prototype without skipping steps.
With best practices baked-in, presenting the best libraries available for a given task.
I really like tutorials that take this holistic approach."

Excerpt from: Building a JSON API with Phoenix 1.3 and Elixir

This one is also written in the same spirit: Quickstart guide for a new Vue.js project