Useful tips for your pet-project #1

When I was looking for my first job I created a pet-project. Now, I worked as front-end developer, and after all these, I can suggest some tips for your project.

This article is only for junior developers who want to improve their projects. Some tips can be useless for someone. This is just my opinion

#1 / no-lib

In my pet-project I used some libs for difficult cases. But in our production, we don’t use any libs like slider, preloader, etc. Because we may get some errors due to a conflict of versions or other pitfalls. In general, I want to say that you shouldn’t use libs if you understand that you can solve it in your own way.

Of course, we can’t replace fundamental libs like React, Redux, Axios, etc. I mean libs that are popular and which solve fundamental problems of developing your project or created for automation routine work.

#2 / think about screen readers

When you’re creating your pet-project you must always think about people with disabilities. A screen reader can be a program that reads text from a screen. In general, many junior front-end developers understand that you should bind input and label tags. But why? Because the label tag is like a link to an input that you bind with the ‘for ’attribute. But if you will check your input with a screen reader you may find some problems.

By the way, that doesn’t matter if you will wrap label in input or vice versa. But there are some differences with behavior — if label outside input — you can place it everywhere and link to input also will work.

What’s wrong with this code? Nothing. But the screen reader doesn’t think so. The person who uses a screen reader will listen: “Find somethind<>Find dot dot dot”. I guess, you already understand why this is so — because the screen reader reads placeholder. How to fix it?

After this, the screen reader will ignore “Find…” because we added aria-* attribute. This is a small tip but it can improve your UI. Generally, I recommend using aria-* attributes and thinking about special cases (e.g how to hide an element from screen reader).

Screen reader about the value of functionality? If we add attribute to button — that’s about functionality, otherwise — value.

#3 / all constants in one file

Imagine you have a word that is repeated many times like ‘Amazon’ on their site. As you can see ‘Amazon’ repeats 28 times! At first, it’s OK but suddenly you need to change ‘Amazon’ to ‘AMAZON’. Yeah, you can use “Change all occurrences” in VS Code or any other functions in your IDE but if you need to do other complex operations you should work with one input instance.

After this, you can import the constant you want and if you change the main instance — you change all repetitions in your application.

#4 / combine all colors in one function

For CSS-IN-JS pattern only.

As I said it’s best to have one main instance. And it’s also about colors.

In colors, we must add only colors by “color name — color code”. In semantic, “essence — colors.colorYouWant ”. In use it looks like this:

#5 / presentation and container components

Separate your logic into container and presentation components. We use the container component when we want to do any side effects, save/update a local state, and in general when we want to separate application logic from UI. We use the presentation component for rendering, in other words for UI.

This is an example that shows how to correctly separate the logic of the components.

#6 / single style for commits

When you want to make a commit you must write a commit message. For example, if you made a footer component, you do the following operations:

git add .
git commit -m 'add a footer'

What do you think about it? This is OK? Yes but imagine that your work requires more than 10+ commits. I mean that sometimes you can make a lot of commits and make commits correctly in the same style.

As you can see, I use specific flags for the names of the commit.

--refactor / code refactoring
--style / added/fixed styles
--feature / added new functionality

I recommend creating flags which ‘comfortable’ for you. By ‘comfortable’ I mean, flags that describe your exact actions. Usually, I use these flags:

But you can make your own flags.

Conclusion.

I wrote 6 tips for your project and that’s not all I want to share with you. I really hope these tips are useful to you. I plan to continue this article and add new tips so you can improve your pet-project!

Thank you for reading!