DEV Community: Methmi

The joy of validating with Joi

Methmi — Fri, 23 Sep 2022 03:58:13 +0000

Validation is a crucial step. But one look at the lines of IFs spawning from endless checks could send us over to NPM, hoping to find the perfect library.

And one of the validation libraries you would find is Joi. And like its name, it’s a joy to use.

With Joi, you can

Describe your data using a simple, intuitive and readable language.

So to ensure some user input contains a name and a valid email, it’s simply

const schema = Joi.object({
name: Joi.string()
   .min(3)
   .max(30)
   .required(),
email: Joi.string()
   .email({ minDomainSegments: 2, tlds: { allow: ['com', 'net'] } })
})

This code block validates an input to have a name property with a number of characters between 3 and 30, and an email with two domain parts (sample.com) and a top level domain (TLD) of either .com or .net.

But to get a better view of what Joi has to offer, let’s see how we could build a simple form that validates a user’s input according to a schema.

A Simple Form Validation

Installing Joi is as easy as running:

npm i joi

After importing Joi at the top of your file with,

const Joi = require("joi");

Joi can be used by first constructing a schema, then validating a value against the constructed schema.

For this example let’s assume that we already have four text fields taking in a user’s name and email and asks to enter a password twice.

A simple form built with Material UI

Now to create the schema that Joi will validate against. Since a schema is designed to resemble the object we expect as an input, the schema for our four property form data object will look like this:

  const objectSchema = {
    name: Joi.string().alphanum().min(3).max(30).required(),

    email: Joi.string().email({
      minDomainSegments: 2,
      tlds: { allow: ["com", "net"] },
    }),

    password: Joi.string()
      .pattern(new RegExp("^[a-zA-Z0-9]{3,30}$"))
      .required()
      .messages({
        "string.pattern.base": `Password should be between 3 to 30 characters and contain letters or numbers only`,
        "string.empty": `Password cannot be empty`,
        "any.required": `Password is required`,
      }),

    repeatPassword: Joi.valid(userData.password).messages({
      "any.only": "The two passwords do not match",
      "any.required": "Please re-enter the password",
    }),
  };

According to this schema:

name is validated to be:
- an alphanumeric string
- between 3 to 30 characters
- a required field
email is checked to have :
- two domain parts (sample.com)
- a top level domain (TLD) of either .com or .net

Custom Error Messages

The fields name and email use default error messages:

But the fields password and repeatPassword use .messages() to return a custom error message for a set of specific error types.

For example, the custom error messages for the password field are:

.messages({
   “string.pattern.base”: `Password should be between 3 to 30 characters and contain letters or numbers only`,
   “string.empty”: `Password cannot be empty`,
   “any.required”: `Password is required`,
}),

The first one is a custom message for an error of type string.pattern.base, if the entered value does not match the RegExp string (since the password field is validated with a RegExp).

Likewise, if a an error of type string.empty is returned (the field is left blank) the custom error message “Password cannot be empty” is shown instead of the default.

Moving on to repeatPassword, Joi.valid() makes sure that the only valid value allowed for the repeatPassword field is whatever the user data is for the password field. The custom error message shown for an any.only error type is shown when the entered value does not match the provided allowed value, which is userData.password in this case.

The full list of possible errors in Joi can be viewed here:
https://github.com/hapijs/joi/blob/master/API.md#list-of-errors

Validating the Form Field on an onChange event

In this example, each form field will have its own error message. So to make updating the state of each error message cleaner, an object was created to hold the values of error messages for all form fields with a useReducer hook to manage its state.

//INITIAL VALUE OF ALL ERROR MESSAGES IN THE FORM
//Each property denotes an error message for each form field
const initialFormErrorState = {
   nameError: “”,
   emailError: “”,
   pwdError: “”,
   rpwdError: “”,
};
const reducer = (state, action) => {
   return {
      …state,
      [action.name]: action.value,
   };
};
const [state, dispatch] = useReducer(reducer,initialFormErrorState);

The reducer function returns an updated state object according to the action passed in, in this case the name of the error message passed in.

For a detailed explanation on the useReducer hook with an example to try out, feel free to check out my article on using the useReducer hook in forms.

Forms with React Hooks

Methmi ・ Sep 9 '22

#javascript #react #hooks

Moving on to handling the onChange events of the form fields, a function can be created to take in the entered value and the name of the error message property that should show the error message (to be used by the dispatch function of the useReducer hook).

  const handleChange = (e, errorFieldName) => {
    setUserData((currentData) => {
      return {
        ...currentData,
        [e.target.id]: e.target.value,
      };
    });
    const propertySchema = Joi.object({
      [e.target.id]: objectSchema[e.target.id],
    });

    const result = propertySchema.validate({ [e.target.id]: e.target.value });
    result.error == null
      ? dispatch({
          name: errorFieldName,
          value: "",
        })
      : dispatch({
          name: errorFieldName,
          value: result.error.details[0].message,
        });
  };

Line 2 to line 7 updates the state of the userData object with the form field’s input. For simplicity, each form form field’s id is named its corresponding property on the userData object.

propertySchema on line 8 is the object that holds the schema of the form field that’s calling the handleChange function. The object objectSchema contained properties that were named after each form fields id, therefore, to call a fields respective schema and to convert it into a Joi object, Joi.object({[e.target.id] :objectSchema[e.target.id],}) is used and the resulting schema object is stored in propertySchema.

Next, the input data is converted to an object and validated against the schema in propertySchema with .validate().

This returns an object with a property called error, this property contains useful values like the error type (useful when creating custom messages) and the error message.

But, if the error property is not present in result, a validation error has not occurred, which is what we are checking in line 13.

If a error is present, the dispatch function is invoked with the name of the form error object’s field that should be updated in name, and the error message that it should be updated to in value.

This will make more sense when we look at how handleChange is called in a form field. Given below is how the form field ‘Name’ calls handleChange.

<TextField
   //TextField component properties
   ...
   onChange={(value) => handleChange(value, “nameError”)}
   value={userData.name}
/>

handleChange accepts the value of the field as the first parameter and then the name of the respective error object’s field that the dispatch function in handleChange is supposed to update, nameError.

The object, initialFormErrorState had one property for each form field’s error message. In this case, any validation error in the ‘Name’ field will change the nameError property of initialFormErrorState which will in turn be displayed in the respective alert box under the form field.

Here’s a look at the finished form:

Hope this simple example helped show how joyful validation with Joi can be. 😊

Till next time, happy coding!

Happy emoji vector created by freepik - www.freepik.com

Making life a breeze, with Git

Methmi — Fri, 16 Sep 2022 04:40:43 +0000

Simply put,

Git is a distributed version control system.

Breaking this down shows the essence of Git:

Control System : Git can be used to track and store content stored in repositories.

Version Control System : A history of all changes made to the content is stored. Also, Git allows multiple users to change content parallelly and keep things clean by separating work into branches

Distributed Version Control System : Machines using a Git repository have a local copy of the repository stored and the repository is stored by remotely on a server by Git as well.

To sum up, Git can be used anywhere content will be changed constantly and where it will be helpful to keep track of changes made so that content can be reverted to how it was at a certain point in its history.

These features along with other features such as branching, to run multiple projects with the same base, parallelly, makes Git a very useful tool for storing and updating code.

Creating a Git repository

A repository is where all your code (or any other content) will live. It can start off as an ordinary folder or folder structure and then be converted into a smart Git repository.

For this example, we will assume that an empty folder called ‘my-code-base’ has been created and a terminal window is opened up and the ‘cd’ command is used to navigate into the folder.

cd my-code-base

git init

The git init command turns the folder into a local repository.

Staging and Committing

Assuming that a plain text file called ‘dummy-file.txt’ is added to the folder, let’s stage it, and then commit it.

Staging is preparing a file (or a change in a file) to be put into a change called a commit.

Staging is required before every commit, this is how the file 'dummy-file.txt' will be staged.

git add dummy-file.txt

To stage multiple files at once:

git add dummy-file.txt dummy-file2.txt

Or to stage all files into staging area:

git add .

Committing involves registering all files currently in the staging area as a change to the repository, including a commit message describing the changes made.

git commit -m "Dummy data added to the file"

The -m indicates that the following string wrapped in " " is a commit message. If this is omitted the user is prompted to enter a commit message after running this command.

Another commit option is -a which automatically stages all modified files to be committed. However, this will only automatically stage files that have already been committed to the repository. For example, if file1 which has been committed in a previous commit is modified and file2 is a newly added file which has not been committed, the -a option will only stage and commit file1 because Git is not aware of file2.

git commit -am “New changes”

Status

Status of files including which files have been modified and what files are in the staging area can be revealed with

git status

Branches

Branches are useful for editing the same codebase parallelly without affecting another developer editing the same code. Also, if a mistake is made when editing, this will be kept separated from other branches and the main branch.

A branch can be created with

git branch test-branch

and switch from the master branch (or current branch) to the created branch with

git checkout test-branch

Also, a list of branches created can be shown with

git branch

Now, new changes can be staged and committed to this branch using the previous commit and stage commands.

Merge

This is used to join a separate branch back into the active branch.

First, checkout into the branch that the other branch needs to be merged into.

git checkout master

Then run

git merge test-branch

and the branch test-branch will be merged into the branch you are currently on.

Managing a remote repository

The repository made so far exists in the local scope, this repository can be stored in remote server that can allow other developers to access and clone the repository.

GitHub is a popular repository hosting service, and for this example the remote repository will be hosted in GitHub.

After logging into a GitHub account, a new repository can be created via the menu on the top-righthand corner.

Next, a name and privacy setting for the repository can be chosen.

After setting up the repository, locate the repository’s URL on its page.

Next, this URL can be used to form the command that points the local repository to the remote repository.

git remote add origin [repository-URL]

Git Push

A push involves sending changes from a local repository to its remote repository.

To push changes, the following command is used

git push -u origin master

This pushes the committed changes in the master branch of the local repository to the master branch of the remote repository.

Git Pull

A pull denotes updating the local repository with latest changes in the remote repository.

Latest code of a certain branch (the master branch, in this example) of a remote repository can be pulled by

git pull origin master

Create a working copy of a repository ( Checkout repository )

A locally stored repository repository can be cloned by running the command:

git clone path/to/local/repo

And, for a repository stored in a remote server:

git clone <<repository-url>>

And that is how Git can be used to make versioning easy and clean and to make collaboration a breeze!

Till next time, happy coding!

Forms with React Hooks

Methmi — Fri, 09 Sep 2022 06:57:35 +0000

React Hooks

In a nutshell, React Hooks can be described as ;

Functions that let you “hook into” React state and lifecycle features from function components. — React

Introduced in React 16.8, a Hook (in React) is a function that keeps track of the state of a React functional component, and is used to solve the problem of only class components in React being able to access the state of the application before Hooks were introduced.

And state is how the dynamic data of a component is tracked by a component so that it can maintain the changes made to the component between renders.

So, to sum up, state stores the changing data of a component, and Hooks are used to manage that state.

This would mean that Hooks are essential for interactive components.

To start off, let’s see how we could use react hooks to keep track of the changing state in a vital interactive web component, forms, using two Material UI components to demonstrate, a select and a checkbox.

For the second part, a few more components will be added to the form to demonstrate how the code can be cleaned. And for the sake of an interesting example, the final form tries to figure out which type of dog matches a user’s personality. 🤭

Handling form state

Handling a form’s state would mean specifying what will happen when a user changes an input field in the form, and keeping track of each change the user makes in the form.

A Select component

To start, here’s the basic structure of Material UI’s Select component.

<Select
value={}
onChange={}
label="On a typical weekend, I'll be"
labelId="select-outlined-label"
>
  <MenuItem value={3}>Bungee jumping, if I had the chance</MenuItem>
  <MenuItem value={2}>Taking a calm walk</MenuItem>
  <MenuItem value={1}>Taking a well deserved nap</MenuItem>
</Select>

Each <MenuItem> tag denotes an item in the select’s drop down list. And the value property on the <MenuItem> tag holds the data that identifies each option. The value property of the <Select> tag will be the value of the option picked by the user, and will therefore be used to display the option picked by the user.

Therefore, the data in the value property of the <Select> tag is what should be tracked as state, since the user selecting an option is the dynamic (changing) aspect of this form input field. Which means a variable to hold state should be passed into the value property of the <Select> tag. And the onChange property defines what will be done when the Select input field is changed. In this case, we would want it to update the data stored in the value property of the <Select> tag.

The useState Hook

The useState() Hook is used to create a state holder required by the Select.

const [activeScore, setActiveScore] = useState(3)

To break down that statement;

The argument passed into useState() is what the initial value of the state holder created will be. In this case the initial value would be 3. This means that the Select will initially display the menu item with a value property of 3 (value={3}) as picked by the Select component.

[activeScore, setActiveScore] uses array de-structuring here. The useState() function returns an array of two items:

The state holder
A reference to a function that is used to update the value held in the state holder.

When array de-structuring is used here, the first element of the array returned (state holder) is stored in the variable activeScore and the second element of the array (a reference to update function) is stored in setActiveScore.

The variable names that are used when de-structuring the array could be anything, in this case they are named activeScore and setActiveScore to represent the state value they will be referring to.

The previous code for Select had data for its value and onChange property missing.

So, to pass the de-structured array to each prop, the value property will receive activeScore since it holds the value selected by the user for active score. To ensure that the activeScore will preserved when the page re-renders, the onChange property will receive setActiveScore because each time the user changes the value of Select, the new value will have to be updated in the activeScore state holder, and setActiveScore contains the reference to the function that does that.

But the each time the field is changed, an event object will be returned, which will contain the value of the value property of the <MenuItem> that the user has picked from the Select. This is the value that should be passed into setActiveScore and to extract this value, the onChange will be defined as (e) => setActiveScore(e.target.value) where e is the variable defined to store the event object received.

And the completed Select component with all its properties set to display and update the state, will look like this:

<Select
value={activeScore}
onChange={(e) => setActiveScore(e.target.value)}
label="On a typical weekend, I'll be"
labelId="select-outlined-label"
>
  <MenuItem value={3}>Bungee jumping, if I had the chance</MenuItem>
  <MenuItem value={2}>Taking a calm walk</MenuItem>
  <MenuItem value={1}>Taking a well deserved nap</MenuItem>
</Select>

And the Select component rendered like this:

The option to which activeScore is initialized to is displayed initially

A Checkbox component

The only difference in this component is that it simply stores a Boolean value, therefore its state will be initialized to a true or false value unlike the previous state holders which were initialized by numbers.

const [agree, setAgree] = useState(false);

And used in the Checkbox component in the following way;

<FormControlLabel
label={
"I agree to not be offended by the results as this is just an " +
"example and not at all an accurate representation of me or the dog
😁"
}
control={
  <Checkbox
  checked={agree}
  onChange={(e) => setAgree(e.target.checked)}
  color="primary"
  />
}
/>

To demonstrate how state is dynamically updated, let’s enable the submit button only when the check box is checked.

Box checked so button is enabled

Box unchecked so button is disabled

This can be done easily by passing the agree state holder manipulated by the checkbox to the disabled property of the Button component. When agree is true, disabled should be false. The logical NOT operator ! is used with agree to get the logical complement (the opposite Boolean value) of agree.

<Button
disabled={!agree}
variant="contained"
color="primary"
onClick={displayResults}/* displayResults is the function that determines the result from the user input */
>
  Show me the result
</Button>

Now with our form in place, we will be moving to the final piece of the page, the result display.

Result shown below the button

The component is nothing more than text below the button, but it will have to display a different result for each different combination of answers according to the displayResults function.
Sounds familiar? Yup, we will be tracking state here as well.

First the state holder for the result, with the initial result set to nothing:

const [result, setResult] = useState("");

Next, a Typography component to show the result and update each time result changes.

<Typography variant="h4">
  {  result ? `It's the ${result}` : ``  }
</Typography>

The ternary operator (<variable> ? <if true> : <if false>) used here says that if result is true, the sentence is shown, else an empty string is visible. The sentence itself is a template literal that displays the value stored inside result with ${result}.

When the submit button is clicked, the displayResults function is called and it changes result each time, by calling setResult within displayResults.

The displayResults function of this example is just a function that categorizes a user to a personality based on the scores chosen and can be replaced by any function that processes form data.

Cleaning up the Hooks

A few more components like a slider and a radio group were added to this form to show how a lot of useState hooks could be a problem.

With a couple more input fields, the useState hooks now look like this:

And having a separate useState hook for each input won’t look any better when the number of input fields increase.
Enter the useReducer hook.

The useReducer Hook

This hook can be used alternative to the useState hook when managing complex state logic in a React component.

The useReducer() Hook will be given a reducer function and an initial state, the Hook returns an array with the current state and a function to pass an action to and invoke, in this case when an input field changes. The current state object and dispatch function are de-structured and stored in state and dispatch respectively.

const [state, dispatch] = useReducer(reducer, initialFormState);

The initialFormState is the original state of the form and will there for have all the values passed into the useState() Hooks earlier, combined as one object.

const initialFormState = {
  alertScore: 4,
  friendlyScore: 100,
  activeScore: 3,
  agree: false,
};

The reducer function passed into useReducer() returns some data, in this case an updated state object, and it will update the state based on the passed in action’s type. So, the reducer accepts a state (the current state) and an action.

const reducer = (state, action) => {
switch (action.type) {
   case "activeScore":
    return { ...state, activeScore: action.value };
   case "alertScore":
    return { ...state, alertScore: action.value };
   case "friendlyScore":
    return {  ...state, friendlyScore: action.value };
   case "agree":
    return { ...state, agree: action.value };
   default:
    throw new Error();
  }
};

A switch case block inside determines how the state is updated, based on the type property of the action passed in.

So, if an action of, for example, activeScore is given, the activeScore property of the current state state is updated with the value property of the action action.value and a new state is returned.

return { ...state, activeScore: action.value };

But, to only update the required property of the state object, the state is spread with the spread operator ... .

The syntax expands the current object (state) so that all its current elements are included and the required element (activeScore in this case) is updated while preserving the original value of the other elements.

To capture user input, the reducer function is accessed by invoking the dispatch function returned from the useReducer(), in the onChange event of an input field.

Here’s the opening tag of the Select component doing that:

<Select
  value={state.activeScore}
  onChange={(e) => dispatch(e.target)}
  //more component properties . . . 
>

Notice that the value of <Select> is now set to state.activeScore since we’re accessing the state of activeScore from the property stored in the current state object, state.

Simplifying the reducer function

The useReducer() implemented now works. But, a case statement is needed for each action type (i.e.: each input field) that exists, which would be bad news for large forms.

However, notice how all the action types have the same name as the state element it controls.

Therefore, the reducer can be simplified to update the state element that has the same name as the action.type passed into it.

And the entire reducer function can be simply written as:

const reducer = (state, action) => {
  return { ...state, [action.type]: action.value };
};

where the [action.type] is the required property to updated in the state.

And the onChange functions will be updated to:

<Select
  value={state.activeScore}
  onChange={(e) => dispatch(
   {
      name: "activeScore",
      value: e.target.value,
   }
  )}
  //more component properties . . .
>

This dispatch call from onChange could be simplified further too.

Right now, the object passed into dispatch() is hardcoded for each input component.

But if we could retrieve the name and value both from the target property of event e itself, the dispatch() function would only require e.target to be passed into it. This is possible by giving a name property to .

<Select
name="activeScore"
value={state.activeScore}
onChange={(e) => dispatch(e.target)}
//more component properties . . .
>

This way, both name and value can be extracted from e.target.

And to make the reducer function extract name from the action (e.target) passed in, the reducer will be updated the following way:

const reducer = (state, action) => {
  return { ...state, [action.name]: action.value };
};

so that name is extracted from action instead of type.

And that’s how the :

useState Hook can be set up to manage state.
useReducer Hook can be used to manage large state objects, as an alternative to the useState Hook.
reducer function of the useState Hook can be cleaned up a bit 😊.

Hope this example helped shed some light on React Hooks and how they are used in interactive web components to manage their state.

Till next time, happy coding!

Giddy-up with GitHub Actions

Methmi — Fri, 02 Sep 2022 05:22:56 +0000

Explore GitHub Actions with a CV generator ✨

What is GitHub Actions?

GitHub Actions is a platform that can be used to automate a build, test and deployment pipeline. This platform has several components:

Events: Something that happens in a GitHub repository (such as pushing to a branch, opening an issue or a pull request)that can trigger the start of a workflow.
Workflows: An automated process that is configured to run once a trigger is fulfilled. They consist of one or more jobs.
Jobs: A job consists of a series of steps that run in the order they are written, one after the other in the same runner. Multiple jobs could run parallelly. Each step in a job could be a shell script or an action.
Actions: This is what happens in a workflow (a single step). They perform tasks that are complex and repetitive, therefore they can reduce repeated code in your workflow file.
Runners: A runner is a server that runs the triggered workflow, and each runner will run a single job at a time.

This article focuses on a project that generates a CV using a python script that converts data in JSON files to a format for a LaTeX CV template, run automatically by a GitHub Actions workflow that also converts the generated .tex file to a CV in PDF format when changes are pushed to the master branch.

methminug / CV-Generator

Edit a simple JSON file to generate an elegantly formatted CV ✨

CV-Generator 🖨️

A python script that converts data in JSON files to a .tex format for a LaTex CV template, run automatically by a GitHub Actions workflow that also converts the generated .tex file to a CV in PDF format when changes are pushed to the master branch.

But why? 🤔

LaTex templates are great for creating well formatted documents.
However, some may find it hard to work with the TeX type setting system used in LaTex, and may even feel that its not worth the time spent editing a complex looking .tex file to create a fairly simple looking CV.

And, that's what this script tries to fix.

Usage

A user edits the simple JSON files in the sections folder that correspond to each section in the CV template.
Here's an example from the experience.json file for the Work Experience section of the CV.

{
    "title":"Work Experience"
    "sectionname":"cventries",

…

View on GitHub

This project is not purely made from GitHub Actions workflows, but they are the core of what will be used to eventually generate the CV. In summary, the final workflow file will:

Be triggered to generate a new CV when changes are made to data in JSON files.
Run a Docker container that will run a Python script to convert data from the JSON files to a LaTeX template, then convert the file from the template to a PDF.
Commit the newly created PDF to the repository.

For a bit of background, LaTeX is a software system widely used to create academic documents, allowing creators to focus on the content while LaTeX handles the formatting. Templates for LaTeX documents make things even faster, making it an ideal option for creating a document like a CV where a more time and effort must be put into the content rather than the format.

The LaTeX template used here is Awesome CV by posquit0, and can be found at: github.com/posquit0/Awesome-CV

Thank you for this cool template!

As this article focuses on actions and workflow files, the content of the Python scripts will not be discussed here, but in short, they replace placeholder text in the LaTeX template with data from JSON files that contain actual data for the CV.

So, let’s jump into the workflow file!

Parts of a workflow file

A workflow is a file written in YAML syntax.

GitHub Actions recognizes workflow files to run by checking specifically for a directory named .github/workflows in the branch that you want the workflow to be triggered from (the master branch in this case).

The main parts of a workflow file are:

Name (optional)
Trigger
Jobs

The name given to a workflow is what will appear when the workflow is shown in the Actions tab of the GitHub repository. The name is configured at the top of the file by the statement:

name: Update CV

The trigger is what will cause this workflow to start running. A trigger can be multiple events or a single event. The following statement configures the workflow to run when a push is made to any branch or when someone forks the repository.

on: [push, fork]

Next, comes the jobs sections which group together all the jobs that will run in the workflow.

jobs:
   <Name of first job>:
      . . .

Building the workflow file

The gist of this generator is that when data in a set of JSON files in the master branch is updated, a new CV should be created according to the updated data in the files.

Therefore, we would want the CV generating workflow to run each time any changes are pushed to the master branch of the repository.

name: Update CV
on:
   push:
      branches: [ "master" ]

As explained previously, the on: section defines the trigger event, and the trigger event of this workflow is a push to a branch, so push: is used.

The push: event has a filter called branches: which allows us to configure the workflow to be triggered only when there is a push event made to a specific branch or branches. In this case, the workflow will only start when a push is made to the master branch of the repository.

Moving onto the jobs: section of the workflow file, our goals are to:

Checkout the current branch.
Generate a CV.
Commit the changes.
Push the changes to master branch.

s these steps have to take place one after the other, they can all be defined as consecutive steps of one job. Each new step will be marked with a hyphen (-).

To set the environment for running this job, the following lines under the jobs: section will be added to the file:

name: Update CV
on:
   push:
      branches: [ "master" ]
jobs:
   update_cv:
      runs-on: ubuntu-latest

      steps:
      - . . .

Here, update_cv is the name given to the job that will run the previously mentioned steps. Note that Update CV is the name of the workflow that runs a job named update_cv.

Next, the update_cv job is configured to run on the latest version of an Ubuntu Linux runner as defined by runs-on: . This job will run on a virtual machine hosted by GitHub.

Then, the steps will be added in the order of execution under steps: .

1. Checkout current branch

This step is necessary to make the contents repository accessible to the workflow. This is important as we will be using a private action in this repository later on in this job. Therefore a checkout action should be used any time a workflow will run against the repository’s code.

. . .
jobs:
   update_cv:
      runs-on: ubuntu-latest

      steps:
      - uses: actions/checkout@v3

The step used to checkout the repository uses the action, Checkout V3, from the GitHub Marketplace, and uses the uses: keyword to define the action that will be used in this specific step.

2. Generating the CV

Next is the step that runs the script to generate the CV and convert it to a PDF, this will be run in a Docker container, so first we will be building a docker container action to be executed in this step. This action will be defined in a separate YAML file in the repository, named generate-cv.yaml.

The Docker container action

To start the Docker container and run the actions code, a Docker image should be specified.

The docker image can be specified in two ways:

As a Dockerfile in the repository.
Using an image from the public Docker registry.

For this example, we will be using a Dockerfile created in the root directory of the repository.

Therefore, the action in the generate-cv.yaml file (which is also in the root directory) will be:

name: 'Generate CV'
runs:
   using: 'docker'
   image: 'Dockerfile'

According to the code, this action will be run using ‘docker’ since it is a Docker action, and an image will be built from ‘Dockerfile’ and the commands will be run in a new container using this image.

Now, the Docker container action created can be used as a private action in the next step of the update_cv job of our workflow file.

. . .
jobs:
   update_cv:
      runs-on: ubuntu-latest

      steps:
      - uses: actions/checkout@v3
      - name: Generate CV
        uses: ./

The private action’s name Generate CV is given to the name: keyword in this step. Since this step uses an action in the root directory, a path of ./ is given to the uses: keyword.

This step will run the Python script that would update the LaTeX template file, create a .tex file from the updated LaTeX template file and finally create a PDF file of the CV from the .tex file.

3. Commit the changes

Next, the newly created PDF file and updates to the LaTeX template file should be committed.

This can be done by via git commands.

. . .
jobs:
   update_cv:
      runs-on: ubuntu-latest

      steps:
      - uses: actions/checkout@v3
      - name: Generate CV
        uses: ./
      - name: Commit generated PDF
        run: |
           git config --local user.email "action@github.com"
           git config --local user.name "github-actions"
           git add --all
           git commit -m "CV updated via GH Actions" -a
        shell: bash

The first two commands configure the GitHub Actions bot to commit to the repository.

Then, all the changes are committed by the bot under a new commit with the commit message "CV updated via GH Actions" .

These commands are executed using bash which is the default shell on non-Windows platforms.

4. Push the changes to branch

Finally, the commit made should be pushed to the master branch.

The third party action GitHub Push from the GitHub Marketplace will be used for this.

. . .
jobs:
   update_cv:
      runs-on: ubuntu-latest

      steps:
      - uses: actions/checkout@v3
      - name: Generate CV
        uses: ./
      - name: Commit generated PDF
        run: |
           git config --local user.email "action@github.com"
           git config --local user.name "github-actions"
           git add --all
           git commit -m "CV updated via GH Actions" -a
        shell: bash
      - name: Push changes
        uses: ad-m/github-push-action@master
        with:
           github_token: ${{ secrets.GITHUB_TOKEN }}

The keyword with: groups the inputs sent to the GitHub Push action. As a repository has not been given as input, the changes will be pushed to the master branch of the current repository.

The input for github_token used here is a unique GITHUB_TOKEN secret that GitHub automatically creates at the start of each workflow run, which can be used to authenticate on behalf of GitHub Actions.

A repository scoped personal access token could also be used as the github_token input instead.

And that concludes our job for our GitHub Actions workflow!

The complete codebase can be found in the repository linked below, so feel free to fork it, make some changes to the JSON files in the /sections directory and watch this workflow spring to action!

methminug / CV-Generator

Edit a simple JSON file to generate an elegantly formatted CV ✨

CV-Generator 🖨️

But why? 🤔

And, that's what this script tries to fix.

Usage

{
    "title":"Work Experience"
    "sectionname":"cventries",

…

View on GitHub

Till next time, happy coding!

Dog cartoon vector created by catalyststuff — www.freepik.com

Rhyme Ping Pong

Methmi — Mon, 29 Aug 2022 22:04:51 +0000

Overview of My Submission

Play ping pong, but with rhymes! 🏓

Go back and forth with rhymes instead of a ping pong ball and see if you can have the last word! The application uses inputs of previous players to come up with its rhymes as a response to yours.

The rhythm and flow of most poems, sometimes felt like a game of ping pong to me, which became the inspiration behind the simple game, Rhyme Ping Pong. 😁

This application tries to come up with a rhyme for each sentence entered and simultaneously builds up its knowledge by storing each unique sentence entered so that it can be used as a rhyme in the future.

How it's built

The user interface of this application was built with React and the Material UI library, and communicates through REST APIs built with the Express framework.

Redis, a key value data store was used as the primary database where its modules RedisJSON and RediSearch were used to store and retrieve data respectively.

Submission Category:

Wacky Wildcards

Video Explainer of My Project

Language Used

JS/TS/Node.js

Link to Code

methminug / RhymePingPong

Play ping pong, but with rhymes! 🏓

Rhyme Ping Pong

Go back and forth with rhymes instead of a ping pong ball and see if you can have the last word! The application uses inputs of previous players to come up with its rhymes as a response to yours.

The rhythm and flow of most poems, sometimes felt like a game of ping pong to me, which became the inspiration behind the simple game, Rhyme Ping Pong. 😁

Screenshots

Overview video

Here's a short video that explains the project and how it uses Redis:

How it works

New sentences input by the user are stored along with the word ending of the sentence’s final word, which is then used to…

View on GitHub

Additional Resources (Screenshots)

Check out Redis OM, client libraries for working with Redis as a multi-model database.
Use RedisInsight to visualize your data in Redis.
Sign up for a free Redis database.

Why JavaScript Promises are awesome

Methmi — Fri, 26 Aug 2022 04:34:00 +0000

What is a Promise?

A promise, in computer science, is basically a concept that handles a value that is to be produced in the future, after an asynchronous operation completes successfully or if it does not, gracefully handles a failure.

Too much jargon?

Here’s a high level picture -

You may lend something to a friend and trust them enough to know that you won’t have to stop whatever you were doing and wait for them to return it. You know that they will return it eventually, so, you’ll be able to go one with your life until the item (or an excuse 😅) is returned.
Although you will act on the eventual outcome of the promise that the friend gave you, you will save that for the time the promise is actually fulfilled.

This was the concept in mind when the term Promise (in computer science) was first coined in 1976.

Promise concepts were popularized in the JavaScript world by the jQuery Deferred Objects, that were similar in concept to the Promise, but differed from the current specification of Promises in ECMAScript 2015.

After their official acceptance into the ECMAScript 2015 spec, they are now implemented in all the latest browsers and Node, and are here to cleanup the potential muddle in callbacks and simplify the process.

What about Callback functions?

Callbacks also produce values after an asynchronous operation but executing one asynchronous operation after the other requires callbacks to be called inside another callback, as shown below.

The callbacks being nested deeper and deeper cause the code to expand horizontally as well, leading to an error-prone and confusing code block understandably known as ‘Callback Hell’.

Promises are used to bypass this.

Using Promises instead

A promise can be created with its constructor:

let promise = new Promise(function(resolve, reject) {
   // Your application logic goes here
});

The function taken into the constructor is the executor function and takes in two arguments: Resolved and Rejected.

The code inside this function is the logic to be executed each time a new Promise is created.

The Promise returned from the constructor should be able to inform the executor function, handling async (asynchronous) operations, when execution has started, completed or returned an error.

Parts of a promise

A promise has a STATE and a RESULT

A promise has 3 states:

Pending
Fulfilled
Rejected

Pending promises in JavaScript, much like in the real world, is a promise that has been executed but not yet completed and can therefore move to the ‘Fulfilled’ or ‘Rejected’ state.

Fulfilled promises are resolved or completed, indicating a successful outcome.

Rejected promises indicate an unsuccessful outcome due to an error or a timeout.

And, promises that are either Fulfilled or Rejected are called Settled.

The result property of a promise can hold the values:

undefined : When the state is pending
value : When resolve(value) is called
error : When reject(error) is called

Resolving and Rejecting

The promise can be resolved with resolve() and placed in the fulfilled state, or rejected with an error as reject(new Error('Something went wrong')) in and placed in rejected state.

let myPromise = new Promise(function(resolve, reject) {
   resolve("This will be resolved"); // EXECUTED
   reject(new Error('Something went wrong')); // ignored
   resolve("Resolved again?"); // ignored
});

In this example, reject() and resolve() are being called again after the promise has been fulfilled.

But, once the state has changed, any further calls to reject and resolve will be ignored.

Handling a promise

The handler functions .then(), .catch(), .finally() allow functions consuming the promise to be in sync with the executor function when a promise is fulfilled/rejected.

Using `.then()`

This is called to handle a promise’s rejection or fulfillment, and can therefore accept up to two functions as arguments:

myPromise.then(
  (result) => { // a successful outcome, promise fulfilled
      console.log(result);
   },
   (error) => { // promise rejected
      console.log(error);
   }
);

Or if only one of the two outcomes are needed:

// logs SUCCESFUL outcomes only
myPromise.then(
   (result) => {
      console.log(result);
   }
);
// logs ERROR outcomes only
myPromise.then(
   null,
   (error) => {
      console.log(error);
   }
);

Using `.catch()`

Leaving one argument null in .then() to handle errors is not so useful. This is when .catch() used.

In the following example getPromise() is a user implemented function that accepts a URL and returns a promise stating its outcome.

let urlPromise = getPromise(BAD_URL);
   const consumerFunc = () => {
   promise.catch(error => console.log(error));
}
consumerFunc ();

Using `.finally()`

This handler cleans up after an execution (for example, close a live connection) and will run regardless of whether a promise is rejected or fulfilled.

Here is .finally() being used with the other handlers:

let isLoading = true;
isLoading && console.log('Loading...');
//Promise with outcome of URL
promise = getPromise(A_URL);
promise.finally(() => {
   isLoading = false;
   console.log(`Promise settled and loading is ${isLoading}`);
}).then((result) => {
   console.log({result});
}).catch((error) => {
   console.log(error)
});

.finally() will set isLoading to false.
If the URL is valid, .then() is executed and result is logged.
If the URL is invalid, error is caught and .catch() is executed and error is logged.
.finally() will be called regardless of a resolved or rejected promise.

Chaining Promises

aPromise.then() always returns a promise this lets us call .then() on the new promise leading to a chain of .then() methods passing down a single promise.

A .then() can return a new promise, or throw an error too. The following example demonstrates this:

let myPromise = getPromise(URL_RETURNING_MULTIPLE_ITEMS);
promise.then(result => {
   // extracts URL of oneItem
   let oneItem = JSON.parse(result).results[0].url;
   return oneItem; // returns the URL
}).then(oneItemURL => {
   console.log(oneItemURL);
   return getPromise(oneItemURL); // new promise returned
}).then(itemData => {
   console.log(JSON.parse(itemData));
}).catch(error => {
   console.log(‘Error caught. In the Catch block’, error);
});

Where the new promise is created, the URL from the previous .then() is passed into getPromise() which returns the new promise that is then resolved sent down the chain where itemData is logged.

If an error is caught, the .catch() in the chain is triggered and the error is handled.

And those were the basics of how Promises can be used for asynchronous functions, resulting in clean, understandable code that’s less prone to errors.

Till next time, happy coding!

DEV Community: Methmi

The joy of validating with Joi

A Simple Form Validation

Custom Error Messages

Validating the Form Field on an onChange event

Forms with React Hooks

Methmi ・ Sep 9 '22

Making life a breeze, with Git

Creating a Git repository

Staging and Committing

Status

Branches

Merge

Managing a remote repository

Git Push

Git Pull

Create a working copy of a repository ( Checkout repository )

Forms with React Hooks

React Hooks

Handling form state

A Select component

The useState Hook

A Checkbox component

Cleaning up the Hooks

The useReducer Hook

Simplifying the reducer function

Giddy-up with GitHub Actions

What is GitHub Actions?

methminug / CV-Generator

Edit a simple JSON file to generate an elegantly formatted CV ✨

CV-Generator 🖨️

But why? 🤔

Usage

Parts of a workflow file

Building the workflow file

1. Checkout current branch

2. Generating the CV

The Docker container action

3. Commit the changes

4. Push the changes to branch

methminug / CV-Generator

Edit a simple JSON file to generate an elegantly formatted CV ✨

CV-Generator 🖨️

But why? 🤔

Usage

Rhyme Ping Pong

Overview of My Submission

How it's built

Submission Category:

Video Explainer of My Project

Language Used

Link to Code

methminug / RhymePingPong

Play ping pong, but with rhymes! 🏓

Rhyme Ping Pong

Screenshots

Overview video

How it works

Additional Resources (Screenshots)

Why JavaScript Promises are awesome

What is a Promise?

What about Callback functions?

Using Promises instead

Parts of a promise

Resolving and Rejecting

Handling a promise

Using .then()

Using .catch()

Using .finally()

Chaining Promises

Using `.then()`

Using `.catch()`

Using `.finally()`