Forem: Stephany Ikebudu

Flexbox vs Grid: How to Choose

Stephany Ikebudu — Tue, 14 May 2024 14:32:50 +0000

In modern CSS, the popular options for layout are Flexbox and Grid. In this article, I explore the features of both and highlight when each can be considered better than the other when developing layouts for websites or web applications.

The Difference

Flexbox is a one-dimensional layout system in CSS. What this means is elements are positioned in rows (side by side) OR in columns (stacked on top of each other). On the other hand, Grid is a two-dimensional layout system with an element having (neighbor) elements both to its side AND on top and/or below it. In Grid system, elements are positioned in rows AND columns.

How to Choose

Flexbox is generally suited for when elements need to be aligned in a single direction. Examples would be a navbar layout or centering elements in a container.

Grid is useful for creating more complex layouts considering both vertical and horizontal alignment, an example would be an image gallery component consisting of 15 photos. This component can take a 5-column 3-row layout.

In the component example, it can be observed that Grid layout is more effective as opposed to multiple Flexbox(es) needed to layout such a component.

Conclusion

Furthermore, Flexbox and Grid can be combined and nested within one another to develop more complex responsive layouts. Understanding the features and different applications of both is important in making informed layout decisions.

Thanks for reading x.

: vs :: in CSS3

Stephany Ikebudu — Mon, 15 Apr 2024 21:27:55 +0000

Have you always used trial and error to style elements when it involves either a colon : or a pair of colon ::? Yeah, me too. But today is the day you become confident with your CSS pseudo-selection…whatever that means lol ;)
In this article, I explain them both with examples and share a few tips for styling elements using either.

The Difference
: precedes and identifies the state of an element while :: “creates” element(s). The difference between : and :: is that the former describes the state of a selected element usually involving user interaction while the latter is used to create element(s) as a part of the selected element and/or used to target elements using the selected element as reference.

It is important to note that : creates pseudo-classes, some examples are
:hover - to style an element when user is on it without selecting ie hovers over an element
:active - to style an element when clicked ie when element is active
:visited - to style anchor tags (links) when a user has clicked on it.
:focus - to style an input field that user clicked on.

While :: creates pseudo-elements. Some examples of pseudo-elements are
::before - targets created element that precedes selected element
::after - targets created element that succeeds selected element
::placeholder - targets placeholder atrribute value

How to Use
A good rule of thumb is to only use :: when it is necessary as this got introduced with CSS3 meaning :before is valid CSS and compatible with older browsers that haven’t fully adopted the changes introduced by CSS3. Following this rule makes your CSS backward-compatible.
It is also good practice to only use CSS-generated content when necessary as CSS-generated elements do not appear on the DOM and therefore cannot be parsed by accessibility tools.

I hope you found this helpful, thank for reading!

Git Commit Like A Pro

Stephany Ikebudu — Mon, 01 May 2023 01:16:10 +0000

Version control systems make collaboration seamless in software development. Git is a version control system used for source code management. It is amongst others not only the most popular among developers but offers excellent features to help in the tracking and managing of software. Git interacts with software using specific commands via the command line interface to perform various tasks ranging from initializing a git repository to keeping track of every step of the development process. In this article, some important git commands including git init, git add and git commit will be explained with an emphasis on git commit.

GIT INIT
This command is used to initialize a git repository which is basically telling git to keep track of the repository, to “keep an eye out for changes” in the repository. This is the first step to managing source code with git. The syntax for this is git init <repository name>.

GIT ADD
This command is used to track file(s) in the git repository. This command tells git to take record of specific file(s) for the next commit. Git takes a snapshot of the file(s) pending the next commit, only file(s) succeeding this command will be recorded by git. The syntax for this is git add <file name> or git add .. Using the period symbol (.) in place of file name tracks all files instead of a single file. This is preferred in instances where tracking multiple files is needed, instead of having to repeatedly run a single command with the different file names or type out multiple file names, git add . is more efficient.

GIT COMMIT
This command is used to save the recorded changes made using the git add command. This command however takes at least two additional arguments. The most common syntax for this is git commit -m “write commit message here”. The -m flag means message which is recorded in the quotation marks that comes right after the flag. It is important to note that the commit message should always be written in the imperative form that is statements that gives a command or makes a request from the reader. This would be a quick way to make a commit, but there are times when a more detailed commit message is needed beyond a simple statement.

CRAFTING GREAT GIT COMMIT MESSAGE
An effective git commit message consists of the right amount of information written properly. Conventional commits defines the specification that provides easy rules for creating useful commit history that makes it easy for you, your project collaborators and/or git as the case may be to understand and possibly perform tasks with your git commits. These specifications automatically generate change logs, can help determine semantic version bumps based on your commit and establish a properly structured commit history. Some benefits of properly structuring a git commit are:
It makes debugging easier using commit history.
It helps a developer contribute meaningfully to open source software.
It makes collaboration easier and enables better use of even more git commands like git reset, git revert and so on.
It identifies a developer as a good collaborator as a good commit message saves project maintainer time because pull requests are clearer and faster to review.
Any git commit message can be split into five as specified by conventional commits. The syntax for this is:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

<type>: This is the first part of a commit message and is used to communicate the intent of your change. This usually takes the value fix for when the commit addresses a bug, feat for when the commit includes a feature you worked on, build, chore, style, refactor, test, ci or docs as the case may be.
[optional scope]: This is the second part of the commit message, it provides additional information to the <type> value passed. Best practice for writing the scope is usually a noun surrounded by parentheses eg feat(user): introduce anonymous comment feature. You can also indicate if this commit type contains and change that may break the code by using an exclamation mark (!) after the closing parenthesis ()) and before the colon (:). This part of a commit message is optional.
<description>: The third part of the commit message is the description which is what is written in a one-liner git commit message using the -m flag. The description should be written in the imperative form, a great test for the imperative form of a commit message will be to insert it in this phrase - “When implemented, this commit will ”. The sentence should be grammatically correct if the commit message is in the imperative form. It should be short and precise. This part of the commit message is in actual sense the commit title.
[optional body]: The fourth part of the commit message is an optional body which further explains the commit description, it follows the commit title with one blank line. This is optional as well as not all commits are complex that they require further description.
Additionally, the 50 72 git commit rule suggests that the <description> is limited to 50 characters while the [optional body] should wrap at 72 characters.
[optional footer(s)]: The fifth part of a commit message is the footer. It is usually separated from the body by one blank line and contains an issue tracker. The footer is optional as well considering not all commits are directly addressing an issue and need to reference and issue ID. This section can also be used to document metadata options eg indicating what method you used for development.
Run git commit in the command line interface without any argument to prompt the git commit message full edit mode.

A common confusion around making a git commit is how often to make a commit which raises the question: how much change deserves its own commit? The best opinion I’ve come across so far concerning this is that a unit of (functional) change is equivalent to a single commit. This way you can easily reverse to a previous version of the code without doing any serious “damage”.

The git commit command is flexible enough to take a variety of flags and even a combination of flags to perform various tasks. Some other git commands can give insight using the git commit command. Some useful related git commit commands are:
git commit -v: this commands shows the status of files, which ones have or haven’t been staged for commit as well as gives an insight or context to what the content of the commit should be.
git commit —amend: this command is used to add newly tracked files to the previous commit
git commit —amend -v: this command is used to add newly tracked files to previous commit and have a detailed view of what is being added to the previous commit, the commit message of the previous commit can be updated using this command.
git commit —amend —no-edit: this is used to add new files to previous commit without changing the commit message.
git show: this is used to view the latest commits.
git log: this displays all the commits for the current working repository, this can take additional flags like —oneline, —stat or —patch to display more specific information about the commit history.
git blame: this is used to view the changes in a file line by line as well as see who changed what.

You can read more on Conventional Commits here.

Accessing Objects in JavaScript: Dot Notation vs Bracket Notation

Stephany Ikebudu — Fri, 28 Apr 2023 04:19:50 +0000

When referring to accessing object properties in JavaScript, there are two different syntax - dot notation and bracket notation. It can be confusing to decide which to use when writing programs. Are they the same? Do they work the same? You’ll find out soon enough! I carefully explain and illustrate what they both are and how to use both efficiently in this article.

Before we dive into JavaScript access syntax, there are some core concepts to first understand in order to have a clearer understanding of how dot notation and bracket notation work which include object, object property, key and value.
An object in JavaScript is simply a group of unordered key-value pairs, and each of the key-value pair is what is referred to as an object property. An object property is a characteristic of the object which is made up of a key that holds a value. A property value is accessed by declaring the key against the object name using either dot or bracket notation. Using the dot or bracket notation, we can access, modify or add a new property to an object. It is worthy to note however also that an object property can be deleted by prefixing the keyword delete before object.property or object[property]

//Declare an object
const person = {
    name: "Steph",
    hair: "Brown"
}


let result = person.name; //dot notation
let result2 = person["hair"]; //bracket notation


console.log(result); //returns Steph
console.log(result2); //returns Brown

DOT NOTATION
This approach uses a period sign (.) to access an object property value, the syntax for this is object.property. When evaluated, it takes a left-to-right approach. So, it checks if an object exists first and then checks if the specified property exists within that object.

BRACKET NOTATION
This approach involves using the use of square brackets to access object property, the syntax for this is object[expression] where the expression within the brackets is evaluated and returns what is then used as the key. When accessing person’s hair value, it should be noted that the key hair is enclosed in quotation in order for it to be evaluated correctly as an expression, the quotation marks make hair a valid expression in the form of a string. Therefore person[hair]throws an error.

THE DIFFERENCE
Using dot notation only allows static keys while bracket notation permits the use of dynamic “key(s)” since it will eventually be evaluated to get the actual key. This means that when a property is accessed with dot notation, whatever value follows the period sign (.) is compared with the list of keys in the referred object looking for a match but when the bracket notation is used to access an object’s property, the content within the brackets is first evaluated and returned as the key.

//Illustrate difference
const person = {
    name: "Steph",
    hair: "Brown"
}


const human = {
    id: "name"
}


console.log(person[human.id]); //returns Steph
console.log(person.human.id); //undefined

The first person[human.id] evaluates human.id and returns a string ”name” which then serves as the key, in other words person[“name”] is what is accessed. On the other hand, person.human.id rather searches for an object person and then checks within the object for a key human which is undefined as person doesn't have a key human.

THE DECISION FACTOR
The decision on how to access a property in JavaScript should be determined by the type or nature of the property to be accessed. When dealing with a static key, dot notation is most efficient and when dealing with dynamic keys, the bracket notation should be used. Also, you should put into consideration static keys that may include a character like the hyphen (-), or a combination of characters should be accessed with bracket notation.
I hope this helps you understand both dot and bracket notations better!

Basic Structure of README.md File

Stephany Ikebudu — Sat, 18 Mar 2023 19:25:25 +0000

Once you've started learning to code, one of the things you'd so often encounter is a README file while reviewing, learning from or contributing to open source software. I'm pretty sure you've heard the saying "Always have a README.md file at the root of your project" more often than not and my guess is that your reaction was similar to mine - "What exactly is that?". In this article I carefully explain what a README.md file is, its basic structure and what it should contain.

Firstly, what is a README.md file? It's simple - It is a file that contains all the necessary and important information of your project. This is where you document important information about your project think of it like a project summary or a manual for your project where anyone can have access to be able to have an nderstanding of what your project is, how to use or implement your project source files. Its importance cannot be overemphasized, it is best practice to always include one at the root of your project as well as carefully go through the README file of any open source project(s) you intend to interact with. Notice that this README file always has a '.md' extension and this indicates it is a Markdown file type and therefore it should be written with the Markdown syntax. Please see my article to learn and get started on basic Markdown syntax here.

A README file should contain:

The file name as the header
An introductory paragraph
Table of contents
Project overview
Project process
Author

The header is usually the project name as a title of the README file, then following that is a descriptive paragraph on what the project is about. The table of contents contain subheadings to further describe the project in details. The first subheading is the overview, this section contains detailed explanation of the significance of the project, link(s) to where your project is histed if its live and may contain snippets/snapshots of the project as well. The second subheading details the project process. Here, the technologies used in development, some tips or particular skills you picked up working on the project and some helpful resources should be highlighted. Finally, you can attach some personal external links to the author section for ease of contact to people who want to reach out to you for collaboration, learning or opportunity sake. Note that each subheading can further be split into smaller sections (sub-headings) for better structure. There you have it! I hope this helps.