Looking back at some code that I have written in the past 2-3 months ago, I have realized that there is a huge difference in the way I write code along with file structuring and documentation.

A huge difference like I have been reading other people's code and see how do they get things done, how they structure their applications, along with how they document their code. So, I looked at my old code and refactor some bits of it but I realized that I am still on version 1.0.0 of my application.

so imagine that you have been working on this project of yours for quite some time, pushing new features and updates just to realize 3 months later that your application is still on version 1.0.0 and who knows how many bug fixes you have fix nor how many features added to this project of yours not to mention if you added something that is not backward compatible so yeah 🤷‍♀️

And I admit the fact that I am not that of an organized person like sometimes I get carried away with work or tasks that I end up not doing the most basic things like updating your project's version number

This is a weird approach since I just mentioned earlier that I am not that of an organized person yet I found a way to automate this process.....interesting 🤔

Well, you write it once and use it forever plus imagine how much time I will be saving when pushing more than 5 commits and trying to think if this is a feature or a bug fix

So I started to research about common patterns for version management and see how other developers are handling this issue. What I noticed is that most of them are following a method called semantic versioning (or semver for short) which I found a site that explains it pretty well here also not to forget npm's documentation of semantic versioning as well which can be found here

without getting into details, your version number is made up of 3 numbers which they are: major, minor, and patch

the major number is to indicate which major version of this project it is on and when you increase that number, it just indicates that you have submitted a change that is not backward compatible at all (keep in mind that when you shift to an upgraded version number, your minor and patch number is set to zero. Example: shift from version 1.5.7 to 2.0.0)

the minor number is to indicate how many features and additions have been added to this project. It offers backward compatibility as long it is on the same major version number

the patch number is to indicate how many patches and bug fixes have occurred on that major version number

usually how you update your version number?

depends on the developer, since each developer has his/her own way of upgrading their version number.

Some might just update the value by accessing the project's package.json and increment the number, some might create a script that automates the process so when they commit and push changes then it increments the number

in a nutshell, what pjsv does is that it reads your package.json file and gives an interactive menu to update your version number based on what you have chosen by writing to that package.json file

the cool thing about pjsv is that it only updates your package.json file and nothing else. It doesn't push updates using git just updating your version number, giving you full freedom to do what afterward

I would highly recommend using Husky along with pjsv

"husky": {
    "hooks": {
      "pre-commit": "pjsv upgrade",
    }
  }

in this setup every time you write a git commit message, it will upgrade your package.json file then adds it to the commit itself

you can start by downloading it as a dev dependency in your project

it also supports the use of npx if you don't want to install it on your project

you can find out more about pjsv on Github

PJSV - open source cli tool to manage your package.json's version

I created a tool to manage my future projects versions since it is ideal to find which version an error occurred (or because I am just lazy to know if this is a feature or a bug fix 🤷‍♂️)

I'm a heavy Redux user and quite a fanboy of the library itself as well to a point I also dabbled into Redux Toolkit which is the Redux's team opinionated way of using the library efficiently and tried it out by using it on a production application. (I took the risk but hey! things went well!)

It is a solid state manager for React. It works out of the box and does everything that you expect from it to do not to mention that it is configurable with various plugins created by the community to make your work easier as well.

A lot of people talk about Redux's setup that they have to write a good amount of boilerplate code to make it work, although that is true it is solvable when using Redux Toolkit since it offers a preconfigured setup with redux-thunk and setup with the Redux DevTools extension out of the box.

My biggest issue with Redux is that using other library's hooks is quite a pain, take an example of React Toastify library which offers a hook to show a toast on your website (a small popup). If I want to use that library along with Redux then either I have to pass it along with my dispatch function or create a Context component that uses the useSelector hook inside of it and use that hook to make a popup when a user inserts wrong information (or maybe I have been using Redux incorrectly and I have found a proper way to handle this situation)

Come to think of it, React does offer a decent amount of hook functions that do the job as expect and the best part: you don't have to install other libraries for state management since you already have one built-in for free!

The best part about Context is that you get to use all of React's cool features out of the box and use other hooks inside of it without any issue at all.

The worst part is that you will have to manage multiple Contexts inside of your app (you could use one Context just like what Redux does but I prefer to split things down into small manageable chunks).

Here I will be offering a small example using React Native and React Navigation to check whether a user is logged in or not

import React, {useState, useEffect, createContext, useContext} from 'react';
import AsyncStorage from '@react-native-community/async-storage';
import {useNavigation, CommonActions} from '@react-navigation/native';

const checkIfLoggedIn = async () => {
	const token = await AsyncStorage.getItem('token');
    if(token !== null) {
    	return true;
    }
    return false;
}

const flushToken = async () => {
	await AsyncStorage.clear();
}

export const AuthContext = createContext(null);

const AuthProvider = ({children}) => {
  const [authorized, updateAuthorization] = useState(false);

  const navigation = useNavigation();

  useEffect(() => {
    checkIfLoggedIn().then((response) => {
      if (response) {
        navigation.navigate('App');
        updateAuthorization(true);
      } else {
        navigation.navigate('Auth');
      }
    });
  }, [authorized]);

  const logout = async () => {
    await flushToken();
    navigation.dispatch(
      CommonActions.reset({
        index: 0,
        routes: [{name: 'Auth'}],
      }),
    );
    updateAuthorization(false);
  };

  return <AuthContext.Provider value={logout}>{children}</AuthContext.Provider>;
};

const useLogout = () => {
  const context = useContext(AuthContext);
  if (context === null || context === undefined) {
    throw new Error('useLogout must be inside of the AuthProvider');
  }
  return context;
};

export {AuthProvider, useLogout};

When the user opens the app, it checks if there is a token saved in the device's localStorage first. If there is a token then it navigates to the App Stack, if not then it takes the user to the Auth Stack so that they can sign up or log in.

Inside that Context is a logout function which what it does is that it sets the authentication state to false and triggers the useEffect hook which navigates the user back to the Auth Stack and removes the previous history so that they don't go back (some Android phones have a back button, if you didn't clear your navigation stack then they can go back to the App Stack even though they are logged out) and deletes your token from the phone.

I also created a useLogout hook which lets me to logout in any component that is encapsulated within that AuthProvider component (handy for later use) which relies on the logout function that is inside of my AuthProvider (inside of my AuthContext).

See that I have relied on useNavigation, a hook from the React Navigation library and it was easily integrated inside of my application.

Yes, you can do a similar action with Redux but the key difference is that you have to add a reducer in your store and create some actions to dispatch an action for logout and logging in not to mention that you need to find a way to pass the useNavigation hook function to navigate the user to a different screen.

Here I made things a bit simpler for me to debug not to mention that if I wanted to add a different hook function or send an API function whenever I logout then it is easily done with the Context example. This way I encapsulate each functionality with its own state and keep things modular rather than sticking everything in one store and one place.

I've tried multiple state managers in React and React Native, they did their job as intended but Context does things a little bit different and a bit better

This is probably the 5th if not 6th time redoing the blog but I have a legit reason this time

the previous blog was created using a Gatsby template which served its purpose but adding one thing or removing something was somewhat of a pain so I decided to take matters into my hand and redo it from scratch.

The Gatsby template relied on a git-based CMS called Forestry (tho the UI of Forestry is lit 🔥  and I really liked it) but it is time to move to a new CMS! so I chose Prismic which offered a very generous free tier (and an actual client library to mess around with 🤷‍♀️)

I went beyond the edge and used Nextjs and Tailwind, rewrote the entire thing from scratch even though I have postponed the development of the site for quite some time (exactly 3 months, it should have been finished 3 months ago but anyway)

This is a beta version of the site, there are a lot of things that needs modifications and a lot of features coming on the way but for a starting point it is not bad

you can access this admin section and post whatever you want! no restrictions no boundaries whatsoever!

Better SEO, Better analytics, Better tagging

in the previous template, it lacked SEO to a point that any blogpost pointed to nowhere. This time I have written the SEO tags according to the standards so they should appear on Facebook, Google, and Twitter as expected.

The site now uses Google Tag Manager and Google Analytics as expected, this functionality is also written from scratch whereas the previous site relied on a Gatsby plugin (and it was performing poorly)

This version of the blog is optimized for performance and speed, although it is still in beta mode the results are not so bad after all! There is more room for improvement but as a starting point, it is not that bad.

2020 was tough, I stopped blogging for quite some time to focus on the things that mattered the most. Now that I have recreated the blog and starting to have a little bit of time on my hand, I might dedicate around 30 mins to write more.

I used to write a blogpost and spam it on Facebook, even though some might be interested yet the majority aren't so I have decided to post it on the Facebook page and some subreddit groups on Reddit where it reaches the right people. I might utilize the Instagram page to add the blog posts there as well.

As for the content, I have made a promise in the past that I will deliver high-quality content and I am still on my promise.

here are the upcoming features that I have in mind for the next update:

Newsletter (serverless, secure, and always on the first day of the month but also made from scratch)

Support page (if you felt that the blog is benefiting you and you wish to support it)

Book recommendations page (separate thing and it can be included in the newsletter)

Contact page (plans is to make a Slack bot not emails which are easier for me to manage)

rewrote the whole thing from scratch, but this time it is quite different! I promise

It was the 28th of August, where my friend send my CV to a small company of 2 senior developers asking to have a junior developer onboard in their team.

after they contact me and arranged a meeting, I was given a task (or it was so call homework). The "homework" was to create an employee directory application where it services basic CRUD (Create, Read, Update, Delete) functionalities.

I was given to use what type of frontend (they use Angular in house but since I have some experience with React so React it was) and Nodejs + Express for backend (they use Nodejs heavily for backend). Part of the "homework" is to go wild with it by including scripts that help and aid in development (example: set a script in your package json to remove your build folder using rimraf [a nodejs package] and build your project to have the latest project possible), use of linters and code formatters, use new technologies like Graphql, and as well using external services like Algolia for searching employees.

They have included a detailed description of how to structure the application in a way they find it efficient, clean, scaleable . And they value code quality and git commit quality

This is the first time you find someone asking for git commit quality, usually a recruiter will ask for code you have written before so they can review

typically you would provide your github/gitlab/bitbucket link so they can review your code but that doesn't end here: they review something that not all seniors and CTO do focus on and that is git commits

I didn't get the job but I've learned something from this "homework", you rarely get this kind of chance anywhere.

Idea of this "homework" is not about flexing your skills (if you can flex your skills then good for you) but rather more into adapting and learning new things as well reviewing yourself

why they focused on git commits anyways? 🙂

turn out that with every version of a website/application/library they developed, they put in the README.md file all of the updates done on each version

having proper git commits help a-lot in populating the README.md file as well if any errors occurred, you can always git revert back to a specific commit

having non proper or poor git commits will cause you to have a hard time remembering which commit is responsible for a specific push (and let's be real, not everyone have a photographic memory to remember everything. We humans can forget and that is okay, really!)

here you said that you have updated the navbar, but what did you update in it? 🤔

navbar updated, elements now stacked in a linear way

also still poor because you said that the elements are stack in a linear way but how? why? what was the problem in the first place?

date reverser function for bookings is working

great, you created a function that reverses the date's format but is it inside of the bookings file? why did you create it in the first place? what purpose does it follow?

navbar updated [check description]

- used css-grid instead of flexbox for aligning the elements
- used grid-template-columns with a repeat of 4 columns 1fr wide
- every element is placed in the center to the main grid div tag
- this setting can help us in mobile much faster by switching columns to rows

remember those first two git commits, compare them with this: they are the same but this commit is better to read

I know what is going on and what I used so incase of any errors I can always refer back to this commit

date reverser function on bookings [check description]

- date reverser function was created in the utils folder
- purpose of this function to reverse the format from YYYY-MM-DD to DD-MM-YYYY
- eventhough this should be a backend issue but currently the backend team is busy and we needed a quick fix
- when backend engineers are free, they can reverse it from their side and this function has served its purpose

compare the first date reverser function commit  with this one, the purpose you created this function is because the backend team is not free to reverse a date format and you need to have a quick solution to work with

majority will ignore the description written under those commits and here is why:

the first line written will always will be the title, anything under the title will be considered as body. on Github/Gitlab/Bitbucket the title will show only unless you press on that commit to see the description

adding this to the tittle makes the developer curious of what is written in the body

[UPDATE] stacking elements on Navbar [check description]

- [IMPLEMENT] use css-grid instead of flexbox
- [IMPLEMENT] use grid-template-columns repeated 4 times with 1fr wide
- [IMPLEMENT] every element is placed in the center respectively to the parent grid div
- [SUGGESTION] this setting can help us better in mobile development by switching columns to rows
- [FIX] fix padding on each element by decreasing it from 15px to 10px
- [FIX] set the elements div's left margin to auto to be aligned at the end of the parent navbar div automatically
- [UPDATE] remove bootstrap classes and use own made classes

here is a more verbose version of it, it is more detailed. It might look weird yet time consuming but take into consideration the amount of time you will save trying to guess what you did in that commit

I rarely use this until recently because I know what I have done in details whether it was a fix or a new implementation or future suggestions for later

how to write those commits? 🤔 my terminal doesn't allow me

I use VSCode for this purpose (I use VSCode for everything so it makes sense to set it up as my git editor as well)

easiest way to do it is by setting VSCode as your default git editor

first enable VSCode to work in the terminal by setting a path to VSCode (read it here)

git config --global core.editor "code --wait"

this sets VSCode as your core git editor, and whenever you want to commit in git you do it this way:

and it will open a new window in VSCode, write the commit you want then save it then close the file so it stops waiting for VSCode

write better git commits by following a specific procedure and modify your editor to help with your commits