DEV Community: Syriamme

Understanding the Spread Operator in JavaScript: An example of such in MongoDB Product Management

Syriamme — Mon, 16 Sep 2024 15:09:10 +0000

In the context of the ES6 and subsequent versions of JavaScript, the spread operator (... ) is a convenient feature for operations such as copy of arrays and objects or combination of properties. This operator is used to spread the object’s elements or an array’s properties so that the developer is able to handle both easily. Here in this article the explanation will be given with an example so that the users can understand the concept of spread operator easily When we want to update the data of many products to a MongoDB database we will know how to do it by using the spread operator.

The Scenario: Updating a Product in MongoDB

Suppose you are using MongoDB database where you keep product records. In every product, there are fields like title, image, price, description, and also an _id which is an automatically generated field. During an edit operation you only wish to modify specific fields of the product while keeping the _id unchanged.

The Challenge

When updating a product, you want to:When updating a product, you want to:
Make certain that the product’s unique identifier (_id) does not change intentionally or unintentionally.
Consider updating only the attributes of the product such as title, image, price, and description that you are allowed to change.
Do not include _id value in the fields you update as this is not allowed in MongoDB.
Here’s where the spread operator is used.

The Spread Operator in Action

Let’s discuss a save method, which concerns with creation of a new product and update of an existing product. If the product comes in with an _id then the record will be updated; else a new record is inserted in the database.

Example Code Using the Spread Operator

Explanation of the Spread Operator

In the code snippet above, the spread operator plays a crucial role in handling the product update:In the code snippet above, the spread operator plays a crucial role in handling the product update:

Step 1: Destructuring the Object and Excluding _id

Here we use Object destructuring to pull out the _id field from the this object which is the reference to the product instance. The remaining fields, title, image, price, and description, are grouped into a new object known as productData.
This step is important to make sure that _id is not included in the update operation as it cannot be updated in MongoDB. We only want to update the fields like title, image, price, and description.

Step 2: Using the Spread Operator to Pass the Remaining Fields

This line utilizes the spread operator to take all the properties in the productData, and spread it to the $set object. The $set operator in MongoDB is used when updating only one or more fields of a document.
Here, the spread operator will make sure that almost all fields in productData contain the update operation, except for the _id field. This makes the code less cluttered and more efficient because you do not have to type out all the properties you want to set again.

Why is the Spread Operator important?

Clean and Concise Code:

With the help of the spread operator, you do not have to repeat property names. Instead of writing:

You simply write:

This makes it easier for your code to be manage, and also reduce the likely hood of an error when dealing with objects that contain many properties.

Flexible and Dynamic Updates:

For example, if you add a new field such as category, you will not have to change the update logic. The spread operator adds all fields from productData during updates making the process flexible.

Avoids Mutating the _id:

By extracting the _id field before the update, there is a way of making sure that the rules set by MongoDB that do not allow an update on the _id are observed. This prerecords your methods and prevents errors in the runtime while also maintaining the integrity of your database.

Conclusion

The spread operator (...) is perhaps one of the key features of the current JavaScript that helps in dealing with objects and arrays. In the above example, we used it to omit _id from the product update and spread the rest of the product data dynamically into the MongoDB $set operation.
Thus by using the spread operator you get to write better easily maintainable code at the same time there is a guarantee that only correct fields have to be update in the database. Regardless of whether you are modifying a product or dealing with more intricate array structures, leveraging the spread operator will greatly improve your understanding of JavaScript.

Understanding Re-Throwing Errors in JavaScript

Syriamme — Fri, 13 Sep 2024 19:55:36 +0000

Let’s assume you are a manager of a store and you require information about some items in the store database. You have a task of making sure that everything is fetched as agreed and handle any complications that may be present. Re-throwing errors in programming is similar to tossing an error to a higher authority since the current hierarchy may not be the most appropriate to handle it. This technique is good in enhancing the management of errors, in that, they may be corrected from a common point if this is where they occurred most.

What is Re-Throwing Errors?

This is the process of catching an error that has occurred, handling it in a brief manner (if necessary) before passing it to another higher level of the application. This is particularly helpful where the current function or block of code doesn’t adequately handle the error. Through re-throwing, it becomes possible for other parts of code to handle the error or exception on their own.

A Practical Example: Product Retrieval

Suppose the specific task involves searching through a database and identifying a list of products. Here’s how you might handle this in JavaScript using a method that interacts with a MongoDB database:
Here’s how you might handle this in JavaScript using a method that interacts with a MongoDB database:

Breaking down the Example

Fetching Products: o The fetchAll method is intended for the usage in cases where all products from a database should be obtained. o This first establishes a connection with the database and selects the products collection it will be using.
Error Handling: o The method employs a try block to try and retrieve the products. In case the above query is executed, it returns a list of products as result of the operation. o In case of an error for instance if the data base connection failed or the query written was erroneous then the catch block is run. Here, the error is logged with the help of console.error in order to give information about the failure.
Re-Throwing the Error: o After logging the error, the method uses the JavaScript throw statement to re-throw the error, throwing err;; This implies that while it can handle the error within the fetchAll method, it delegates the handling of the error to whoever is calling the method. o This approach enables requesting layers of the application, for instance, a controller or the main application logic layer, to handle the error, possibly with more background information or with a set of proper measures to undertake.

Why Re-Throw Errors?

Delegation: When errors are re-thrown, it gives the current function the ability to pass on the error to another part of the code. This is useful when the function is not well located to deal with the full extent of the error.
Centralized Error Management: If you rethrow the errors, you have a better way of handling them since it centralizes them. For instance, if two or more functions can experience errors, it is more convenient to handle them from a central error handler.
Code Clarity and Maintainability: It also helps you maintain your code as less cluttered and a lot more manageable. The function does its main goal (retrieving products) but prescribes error resolution to a higher level of the application.

When is IT appropriate to re-throw an error?

Delegating Error Handling:

o Scenario: If a method involves dealing with external systems such as databases or APIs and such a method encounters an error, then the error may not be fully managed within that method.
o Example: Think of a scenario where you have a static method performing data retrieval from a database. If this method is confronted with an error (for instance, a database connectivity problem), it may pass or throw the error back upwards to a calling function such as a controller or a higher level handler who can handle it such as logging, informing the user, or trying to fix.

Centralized Error Management:

o Scenario: If you wish to have a centralized point for error handling, including a global error handler, one might re-throw errors in methods to ensure they are pick up and dealt with.
o Example: An API service method that re-throw errors could be co-raveled by an global error middleware in an Express.js application that formats and returns errors consistently.

Layered Architecture:

o Scenario: In some agreed upon three tier environment where several tiers like data access tier, business logic tier are invested with certain functions, then the error may be re-thrown to a higher tier that has more context /scope of handling them.
o Example: A method of the data access layer might re-throw an exception to be returned to the business logic layer where it will have knowledge of whether to retry the operation or not, display an informative message to the user, or pass on the problem to the next level.

Unhandled Scenarios:

o Scenario: Sometimes when a method gets to a situation it has not foreseen or handled it may throw the error again to be dealt with by other functions.
o Example: A utility method may actually re-throw an error if their test encounters something it does not expect, so that the higher-level material may deal with it.

When Not to Re-Throw an Error

Self-Contained Error Handling:

o If you are able to leave the error ‘to the method’s own devices’, so to speak – in other words, if you do not need to do anything further to rectify the situation – you may well decide not to re-throw. For instance, if a method can repeat an operation or mend a problem internally then it should not re-throw.

Non-Critical Operations:

o If the error does not seriously hinder the functionality of the application, and can be safely disregarded or reported without adversely affecting the application, re-throwing may not be necessary.

Conclusion

Error handling is one of the most crucial aspects of JavaScript coding, and re-throwing of errors is one of the best practices in it. With this approach, if not handled correctly, you know where errors occur, thus making your code less sensitive to change and therefore more robust and maintainable. From the responses of database operations, API calls, or any other asynchronous processes, it is important to understand re-throwing to develop more robust applications.

Understanding Asynchronous Operations and Using async/await in JavaScript

Syriamme — Mon, 09 Sep 2024 20:56:13 +0000

As you already know JavaScript is a single-threaded language and it can perform one action at a time. However, many operations in web development including pulling data from a server or reading the files in the disk can take some time to be accomplished. If it does perform these operations synchronously, meaning JavaScript has to wait until the operation is done before going to the next line of code, then it will slow down the responsiveness of the application. To complete such tasks more efficiently, JavaScript employment asynchronous programming technique.

What Are Asynchronous Operations?

Asynchronous operations are operations which are initiated at the current time but allowed to finish at some other time while the program continues with other lines of code. In JavaScript the handling of asynchronous behavior is done through the use of callbacks, promises, and latterly the async/await syntax. This approach makes the JavaScript perform tasks in the background thereby enhancing the overall performance of web apps.
For instance, consider the case in a web application where information about a user has to be retrieved from the database. This process could take a few seconds depending on the speed of the network or high traffic to the server. JavaScript can continue with the rest of the code instead of halting the application as it waits for the data to be received. This kind of non-blocking behavior is the basic idea behind asynchronous programming.

Introducing async/await

The async/await syntax, which is a part of ES2017 (ES8), is arguably the most elegant and easy-to-understand means to deal with asynchronous code. It is based on Promises and gives a way to look asynchronous code like synchronous code for easy to understand and maintain.
An async function is a function that has the Promise as its return type. The async keyword when attached to a function tells the program that the function will always return a Promise regardless of whether a Promise is actually being returned or not. Await is used inside an async function to allow the function to wait for a promise to complete or reject.

How Does async/await Work?

Now let me illustrate with an example how use async/await. Consider the following code snippet that retrieves a user’s shopping cart and displays it:

In this example, the getCart function is declared as async, therefore, it can use the await keyword for handling asynchronous operations within it.

const cart = await req.user.getCart();: This calls the getCart method on the user object, this retrieve the current cart instance of the user. The await keyword ensures that JavaScript wait for the Promise returned by getCart() to be completed. The resolved value (the user’s cart) is then assigned to the cart variable.
const products = await cart.getProducts();: Likewise, this line pauses the execution of the code until the getProducts method is done, which brings the products in the user’s cart. The await keyword tells the CLR that the following line of code should not execute until the product data is ready.
Rendering the Response: Upon completion of both asynchronous operations, the variable res.render() is executed to render the cart page alongside the products.
Error Handling with try...catch: The try...Finally, catch block is employed to handle any exceptions that may arise due to the asynchronous operations. If there is an error at any of the await statements, the catch block handles the error and logs it to the console.

Benefits of using async/await

The async/await syntax offers several advantages over traditional promise-based code:The async/await syntax offers several advantages over traditional promise-based code:
• Improved Readability: It is easy to follow and comprehend because the code looks like normal synchronous code despite its ability to handle asynchronous operations.
• Error Handling: Using try...Async/await makes error handling as simple and uniform as catching the error with sync/async.
• Simplifies Complex Operations: async/await should be used for the code which has multiple asynchronous operations because the code would be easier to be written, tested, and debugged.

Conclusion

Async programming is particularly crucial in JavaScript to execute computationally intensive operations without stalling the main thread. The async/await syntax offers some more sophisticated way of dealing with these operations and the code generated is more readable, cleaner and easier to debug. Async/await helps developers to write asynchronous code, which makes their application more predictable and faster.

Explicitly Avoiding Callback Hell

Syriamme — Wed, 28 Aug 2024 10:10:28 +0000

Asynchronous programming is one of the major strengths of JavaScript, especially in Node.js; however, due to necessary separation of concerns, multiple asynchronous operations are often performed via callbacks, and this can lead to what is known as “callback hell.” For instance, consider a situation where we are working with nested callbacks in our JavaScript code, and let’s look at how we can refactor it using Promises and the async/await structure.

Callback Hell: An Example

Let's start with some code that uses callbacks to handle file operations for a simple product management system:

Here, we have several well-nested backcalls to read from, and write to a file. This is probably one of the instances you would write when you are deep inside callback hell. Finally, with a greater number of asynchronous operations the code will grow as will the amount of indentation making it harder to read. In the save() method, the fs.readFile function reads the file, and then its callback parses the content and uses a fs.writeFile function to rewrite the content of the file which is done in another callback. Such levels of nesting makes the code resemble what is referred to as a “pyramid of doom.”

Moving to Promises and Async/Await

In order to avoid this callback hell, there are JavaScript promises and the async/await syntax which makes code much more readable, manageable, and debugging-friendly.
Here's the improved version:

Why Promises and Async/Await?

Promises are helpful by enabling management of asynchronous operations linearly and with the least number of nested structures. The async/await pattern enhances the readability of the code and also addresses the asynchronous operations in a way that looks closer to synchronous operations. Using specifically try and catch blocks, the error processing becomes more transparent and easier to understand which contributes to the code maintainability.

Conclusion

Callback hell can be the real problem while writing the code in clean working manner in JavaScript, particularly in Node.js. With the help of Promises and async/await, it is possible to turn heavily nested callback hell into clean linear code at the same time making it easier to deal with errors. It not only transforms you code to look much better but also sets you on the right track of becoming a better JavaScript programmer.

Product Management System with Express.js and Embedded JavaScript Template Engine (EJS)

Syriamme — Sun, 25 Aug 2024 17:51:11 +0000

In my recent project, I created an application that manages products using Express.js web application framework and EJS template engine. The objective of the project was to develop a web-based application for adding products and displaying them on a homepage and shop page. In this article, the basic functionalities of the project are discussed which includes the creation of the Express.js server, the uploading of files with Multer and the display of the product data with EJS Templates.

The project was started with the creation of an app.js server. To set up the Express application, I made an app.js file. In this server, the port 3000 is used while serving static files located in the public folder where stylesheets and images are included. When creating an app using Express I defined EJS as the template engine and set the directory for the views as views. The routes for managing product and for displaying them were built in different files to enhance the organization of the project.

File Uploads with Multer

One of the important characteristics of this system is the function for uploading product images. For file uploads, I used Multer, a middleware for handling file that are in the ‘multipart/form-data’. The Multer package was set up to store the uploaded files in the public/images folder and name it using the current time. This makes it possible that no two images will have the same name, making it difficult to overwrite the files.

Here in routes/admin.js, I configured the Multer middleware allowing files upload in the /add-product route. The form for submitting the addition of a product has input fields for the title, price, description, and image of the product. Multer is used to handle the image file and the path of the image is written to the database (or in this case an array in memory) for later use.

Managing Product Data

The product data is stored as an easily accessible in memory array in the products.js controller. The postAddProduct function deals with the submitted forms by mapping product details from the request body and file from Multer. The product is then inserted as a new element in the products array. It can also change the target page after adding a product, for example, accepting the user to the home page.

To display the products, I created a views in shop.ejs. The shop.ejs template renders a list of different products including their title, price, description, and the image. This view utilizes data from the res.locals.products which is passed to it from the middleware in app.js.

Challenges and Solutions

One of the issues faced was how to correctly display paths of the product data such as images paths. This, I eradicated by making a point that the products array was within the reach of both the admin and the shop routs. Another obstacle was how one should address the issue of file uploads the correct way. In the Multer setup, I properly set the filters leading to the acceptance of image files only.

Conclusion

This project explains in detail a practical use of Express.js and EJS in the development of a product management system. It emphasizes file upload with Multer and the utilization of the EJS templating engine for interactive content presentation. The system let the users add and view the products let alone the navigation structure, which forms the strong base for further development as well as refinement.