Contributing to Github-Dashboard

Miscellaneous lessons learned about React, organizing an open source project, and SVG icons

In Github-Dashboard our navbar still needed a bit of work. It had some issues with its responsiveness, was creating odd css conflicts across pages and a new component needed to be to make it a bit more apparent that the user was logged in. So I decided to update this part of it and get more experience with flexbox along the way.

This post will be a collection of some note-worthy things I learned or experienced while working on the project. They’re not in any particular order, they’re simply a collection of things I found notable and potentially useful to others.

React State Mutations

Earlier when creating my component I was setting fields onto this.state directly, writing something like:

this.state.login = info.login;
this.state.avatar = info.avatar;

However this is frowned upon. As stated in the React docs:

Never mutate this.state directly, as calling setState() afterwards may replace the mutation you made. Treat this.state as if it were immutable.

So basically we want to avoid using this.state because it risks unintentional changes to the states we want to keep track of. In reality using this.setState could work in a lot of cases, but treating it as immutable is a best practice to avoid strange edge cases. If you are looking for some novel ways to get around this issue, you might want to try reading this post.

I then changed my code to the recommended method:

this.setState({ ...info });

If you’re wondering what the ellipses are doing, they’re a really cool technique I learned about after reading over a Gothub-Dashboard pull request submitted by pynnl. What they’re doing is automatically defining and initializing fields in state that match the info object. So it makes it so that this.setState({ …info }) is essentially equivalent to:

this.setState({ login: info.login });
this.setState({ avatar: info.avatar });

Organizing an Open Source Project

Sometime during Hacktoberfest I came across an amazing post where the maintainers of the project tracked the progression of it through screenshots right before/after a new change was merged into master.

I think this project is exemplary of a certain aspect of open source, in how it was so rapid and whimsical in its development. It shows how quickly a project can evolve over time with multiple people contributing, and how different it can look from each iteration merged into master.

What they made reminded me of Github-Dashboard; each contributor has a different store of knowledge they’re working on, in turn making contributions a bit unpredictable, which is a good thing. I knew enough to help give the project direction, but when I was reading PRs I was often introduced to better ways of going about things I hadn’t even thought of when writing issues for them.

A bit about SVG vs Font Icons

There is still some work to be done for Github-Dashboard until it’s complete, and before that happens there’s a certain improvement I think should be made so the project is stronger.

Up until recently my only real experience with website icons were font based and png/jpeg based ones, but lately I’ve been experimenting more with SVG ircons. As I get more experience working with with them they really seem like the most superior option to choose from. They:

• Are abundant online and easy to create with the right tools
• Can be manipulated directly in whatever html they are embedded in and manipulated with custom css
• Are sharper/better quality than icon based images

Inline SVG vs Icon Fonts [CAGEMATCH] | CSS-Tricks