Tutorials on Javascript

In this comprehensive guide, we will demystify a fascinating aspect of JavaScript, one of the most widely-used programming languages today. The key question we will grapple with is: "Is JavaScript a compiled or interpreted language?" We'll probe into the complex depths of JavaScript code execution and the functioning of modern JavaScript engines. This understanding will equip you to grasp the finer dynamics of JavaScript, empowering you to evolve into a more proficient JavaScript developer. JavaScript is frequently labeled as an 'interpreted' language, a tag attributed to its execution style. However, this description isn't wholly accurate. While it doesn't generate an executable file like conventional compiled languages, JavaScript does undergo a compilation phase. This guide aims to shed light on this intriguing facet of JavaScript, thereby dispelling any prevailing misconceptions. Conventionally, 'compiled' languages such as C++ convert the source code into a binary executable file. This file can then be disseminated and executed. 'Interpreted' languages, on the contrary, don't yield an executable file. They rely on interpreters to read and execute the code in real-time. In the case of JavaScript, the engines don't produce an executable file, thus reinforcing the perception of it being an interpreted language. Nevertheless, JavaScript code is compiled into an intermediate form known as 'byte code'. This byte code is subsequently executed by the virtual machine. Although the virtual machine interprets byte code, modern JavaScript engines deploy a "Just-in-time (JIT) compiler" to transmute the byte code into native machine code. This machine code executes at a faster pace than byte code, thereby boosting performance. The JIT compilation is a methodology extensively leveraged by present-day JavaScript engines to augment the execution speed of JavaScript code. Post the conversion of JavaScript code into byte code, the engine executes it. The engine also implements several optimizations based on the data accumulated during code execution to enhance performance. One such optimization strategy involves the compilation of byte code into machine code, which executes quicker. The engine earmarks the frequently executed or "hot" sections of the code for this process. These "hot" segments are compiled into native machine code, which is then executed in lieu of the corresponding byte code. The JIT compiler significantly diverges from traditional compilers employed by languages such as C++. Unlike conventional compilers that compile the code in advance, the JIT compiler compiles the code at runtime, during the code execution process. Despite the distribution of JavaScript code in source code format instead of executable format, it is compiled into byte code and potentially into native machine code. Based on the above elaboration, it can be conclusively stated that JavaScript is a fusion of both compiled and interpreted language. It amalgamates the advantages of both paradigms, employing a hybrid approach for efficient execution. The non-existence of an executable output file coupled with the presence of a JIT compiler that compiles code at runtime endows JavaScript with a distinctive identity. Grasping these nuances of JavaScript can offer invaluable insights into the mechanics of code execution and can steer developers towards crafting more effective and high-performing JavaScript code. Therefore, the next time you are quizzed about whether JavaScript is compiled or interpreted, you'll be well-equipped with a sound response! To dive deeper into JavaScript and explore concepts like this, the book Advanced JavaScript Unleashed by Yousaf, an experienced full-stack software engineer, is highly recommended. With a deep understanding of JavaScript and valuable insights shared in this book, any JavaScript developer aspiring to achieve greater heights will find it beneficial.

This article embarks on a journey into the captivating world of JavaScript custom iterable objects. It's an important topic when there is a need to iterate over related objects or define specific iteration behaviors for certain objects. Iterables and iterators are frequently used in JavaScript coding. An iterable is an object that determines its iteration behavior, like the values looped over in a for...of construct, while an iterator is an object that maintains its current position in an iterable. Understanding these two principles, we can create custom iterable objects in JavaScript by implementing the Symbol.iterator method, which returns the iterator object that includes the next method. Let's dive deeper into this concept with a practical example. Imagine a scenario where student objects must be made iterable to streamline the printing of their properties using the for...of loop. The process commences with the creation of a Student constructor, which will be utilized to generate student objects: To render all student objects iterable, the Symbol.iterator method is implemented in the Student.prototype object: Now, when iterating over any student instance, the formatted values defined in the student iterator's next method will be obtained: The brilliance of creating custom iterables in JavaScript lies in the flexibility it offers. The iteration behavior can be fashioned according to any logic, and the returned value in the iterator result object can be formatted in any preferred manner. However, it's noteworthy that the studentIterator object in our example does not inherit from the Iterator.prototype object, so it isn't iterable: This can be addressed by either explicitly establishing the prototype chain link between the Iterator.prototype object and our studentIterator object, or by implementing the Symbol.iterator method in the studentIterator object to make it iterable: Now, the studentIterator object is iterable and can be used with the for...of loop if needed. Currently, the Symbol.iterator method is defined in the Student.prototype object, but it is enumerable, which isn't ideal. It can be made non-enumerable by defining it using the Object.defineProperty method: This article dove into the creation of custom iterable objects in JavaScript. The process of outlining the iteration behavior for any suitable object or a group of related objects was discussed. We also improved the implementation by making the Symbol.iterator method non-enumerable. This understanding is critical when managing collections of related objects, leading to a more flexible and adaptable JavaScript codebase. To dive deeper into JavaScript and explore concepts like this, the book Advanced JavaScript Unleashed by Yousaf, an experienced full-stack software engineer, is highly recommended. With a deep understanding of JavaScript and valuable insights shared in this book, any JavaScript developer aspiring to achieve greater heights will find it beneficial.

In this comprehensive guide, we will traverse through the complexities of memory management in JavaScript. There are numerous myths regarding memory allocation in JavaScript; a prevalent one being primitive values are stored on the stack , while objects are housed on the heap . However, the reality is far more nuanced. We will debunk these misconceptions about memory allocation, explore the role of the JavaScript engine, and shed light on the concept of automatic garbage collection . Memory allocation in JavaScript extends beyond the simplistic dichotomy of stack and heap storage. The ECMAScript specification , which forms the framework for scripting languages including JavaScript, does not dictate specific rules for memory allocation or deallocation. Consequently, decision-making about memory management is left to the individual JavaScript engines. Distinct JavaScript engines may implement diverse strategies for memory management. For instance, in the V8 engine , utilized by Chrome and Node.js, virtually all values, including objects, arrays, numbers, and strings, are stored on the heap. This method doesn't imply that all JavaScript engines allocate everything on the heap. Some might optimize memory usage by storing temporary values on the stack, particularly if these values are not required beyond a function call. The crucial takeaway is that there's no universal rule concerning memory allocation in JavaScript. Simplistic assumptions like " primitives go on the stack and objects go on the heap " fail to capture the complexities inherent in JavaScript engines. In contrast to languages like C that necessitate programmers to manually deallocate memory when it's no longer needed, JavaScript streamlines this process through automatic garbage collection . JavaScript engines are equipped with a garbage collector that identifies and marks redundant memory blocks for garbage collection. Contemporary JavaScript engines utilize the Mark-and-sweep algorithm to identify 'unreachable' memory blocks, i.e., blocks that no longer have any active references in the application. Unlike Java, where programmers can manually initiate garbage collection, JavaScript doesn't offer this level of control. While some may perceive this as a limitation, it's predominantly viewed as an advantage as it mitigates common memory leaks that occur in languages devoid of automatic garbage collection. In summary, memory management in JavaScript is not as simplistic as it's often perceived. It encompasses intricate decisions made by the JavaScript engine and automatic garbage collection. The stereotype that " primitives go on the stack and objects go on the heap " is just a myth. On the contrary, memory allocation is a sophisticated process differing across various JavaScript engines. Understanding these nuances can enable programmers to appreciate the flexibility and sophistication inherent in JavaScript as a programming language. To dive deeper into JavaScript and explore concepts like this, the book Advanced JavaScript Unleashed by Yousaf, an experienced full-stack software engineer, is highly recommended. With a deep understanding of JavaScript and valuable insights shared in this book, any JavaScript developer aspiring to achieve greater heights will find it beneficial.

JavaScript, a crucial language in the field of web development, is renowned for its asynchronous capabilities. A pivotal feature of JavaScript is the "callbacks" - functions that are carried out following the completion of an operation. However, using callbacks can pose certain challenges. This educational article dives into the issues related to JavaScript callbacks and offers insights into handling these complications more effectively. The primary issue while working with JavaScript callbacks correlates to a situation where numerous asynchronous operations need to be executed sequentially. This complication arises as each operation depends on the outcome of the preceding one. The traditional solution has been to nest callbacks, but this method can lead to a complex structure that is difficult to read and manage, especially when the operations increase. This situation, referred to as "JavaScript Callback Hell" or the "Pyramid of Doom," is demonstrated in the code snippet below: The pyramid-like structure in the JavaScript code is evident, creating challenges in reading, managing, and refactoring the code. The complexity escalates when error handling is incorporated into this JavaScript code. Another challenge with JavaScript callbacks surfaces when trying to handle errors. As seen in the code above, to manage errors, specific error handling logic needs to be included in each JavaScript callback. This results in duplicated code and lacks a centralized location to handle errors for all asynchronous operations. To conclude, while callbacks are an integral feature of JavaScript, necessary for writing asynchronous code, they introduce a layer of complexity and challenges, especially when dealing with multiple nested operations and error handling. However, alternatives like promises and async-await syntax, to be discussed in later lessons, provide solutions to these issues. They still employ JavaScript callbacks but in a more manageable manner, helping to prevent the dreaded Callback Hell. The objective is not to eradicate callbacks but to utilize them more judiciously and effectively, resulting in JavaScript code that is more readable, maintainable, and easier to debug. To dive deeper into JavaScript and explore concepts like this, the book Advanced JavaScript Unleashed by Yousaf, an experienced full-stack software engineer, is highly recommended. With a deep understanding of JavaScript and valuable insights shared in this book, any JavaScript developer aspiring to achieve greater heights will find it beneficial.

Inheritance is a key concept in Object-Oriented Programming (OOP) that allows objects to adopt properties and methods from other objects, promoting code reuse and minimizing redundancy. JavaScript's implementation of inheritance, known as "prototypal inheritance," offers a unique approach compared to languages such as Java or C#. In this article, we'll dive into the intricacies of prototypal inheritance in JavaScript, including the "prototype chain," prototype properties, and accessing the prototype of an object. JavaScript's programming paradigm allows objects to be linked with other objects, enabling an object to utilize the functionality of another connected object. This connection between objects is referred to as the "prototype chain". This is akin to the scope chain, where each scope is connected to another until reaching the global scope. Prototypal inheritance in JavaScript implies that an object can adopt properties from its prototype object. For example, when creating an object literal in JavaScript, it is automatically linked to the default Object.prototype object. Here's a demonstration: In this scenario, the Object.prototype object is the prototype of the obj object. JavaScript objects possess a hidden internal slot called [[Prototype]] . When a new object is created, it is linked to another object by storing a reference to that object in the [[Prototype]] slot of the new object. This referred object becomes the "prototype" of the newly created object. For example, the [[Prototype]] slot of the obj object retains a reference to the Object.prototype object, thus obj.[[Prototype]] provides the prototype of the obj object. The term "prototype" in JavaScript can be somewhat perplexing as it's used in two distinct contexts: as a property (like Object.prototype ) and as a term to describe an object that shares its properties with another object. Functions in JavaScript can possess properties, similar to any other object. One such property is prototype , which is absent in arrow functions. The prototype property of a function refers to an object utilised as the "prototype" for other objects when the function is invoked as a "constructor function" using the "new" keyword. Here's an illustration: The Car function is designed to be used as a constructor function. The prototype property becomes crucial when a function is invoked as a constructor using the new keyword. Any properties added to the Car.prototype object will be shared among all instances created from the Car constructor function. Therefore, the Car.prototype function acts as the "prototype" for all instances of the Car constructor function. We'll now add a property to the Car.prototype object: When a function is invoked using the new keyword, the [[Prototype]] internal slot of the newly created object points to the object referenced by the function's prototype property. Therefore, the new object can access the properties defined on the object referred to by the constructor function's prototype property. The Object function in JavaScript has a static method named getPrototypeOf , which can be used to fetch the prototype of any object. It returns the value of the internal [[Prototype]] property of the object. In the example above, the Object.getPrototypeOf function returns the Car.prototype object because the Car.prototype object is the prototype of all instances of the Car constructor function. This article has clarified the concept of prototypal inheritance in JavaScript, how objects are interconnected in JavaScript, the prototype property of functions, and how to obtain the prototype of any object. Understanding these concepts can boost your JavaScript proficiency and provide a deeper comprehension of how the language operates behind the scenes. To dive deeper into JavaScript and explore concepts like this, the book Advanced JavaScript Unleashed by Yousaf, an experienced full-stack software engineer, is highly recommended. With a deep understanding of JavaScript and valuable insights shared in this book, any JavaScript developer aspiring to achieve greater heights will find it beneficial.

In this comprehensive guide, we'll be exploring the intriguing world of asynchronous programming in JavaScript, including its unique advantages and the challenges it presents. We'll be delving into the traditional approach of handling JavaScript asynchronous programming and the transformative changes ushered in by the introduction of Promises in ES2015. Additionally, we'll shed light on the revolutionary async-await syntax that simplifies the implementation of promises in JavaScript. Asynchronous programming signifies that a JavaScript program has the ability to initiate a potentially time-consuming operation and proceed with other tasks without waiting for the long-duration task to complete. Upon completion of the task, the program is notified and can access the resultant data. Asynchronous programming in JavaScript provides solutions to common issues encountered with traditional synchronous programming. Synchronous programming executes instructions sequentially, one following another, in the exact order they appear in the JavaScript program. While sequential execution makes synchronous programs relatively easier to comprehend, it also poses certain problems that asynchronous programming is designed to resolve. A key drawback with synchronous JavaScript programs is that a long-duration task can pause the execution of the entire program until its completion. This results in subpar performance, inefficient resource allocation, and a less than optimal user experience. Even though asynchronous programming resolves these issues, it introduces its unique challenges, including error handling, managing shared state and resources, and coordinating various parts of the JavaScript program. Before we dive into the specifics of writing asynchronous JavaScript code and how it is managed, let's first understand the problems JavaScript encounters when executing long-running code, such as loops. Consider this JavaScript example: JavaScript is a single-threaded language, which has its unique benefits and limitations. On the upside, JavaScript developers are spared from dealing with issues common to multi-threaded programs like race conditions and deadlocks. However, the single-threaded nature of JavaScript has certain limitations, as demonstrated by the JavaScript code example above. The JavaScript code simulates a long-duration operation that takes roughly 3 seconds to complete. During these 3 seconds, the main thread running the JavaScript code is blocked, halting all other executions. If this JavaScript code is integrated with an HTML file and run in a browser, the UI will freeze until the loop is completed. For instance, try adding the following HTML code to an HTML file and attaching the above JavaScript code to it: Upon initial page load, you'll observe that the button is not responsive for a few seconds. The UI remains stagnant until the JavaScript code, specifically the long-duration loop, has executed. This results in a poor user experience in web applications. Despite modern JavaScript engines being optimized for efficient code execution, it's crucial to ensure that the main thread isn't blocked by any time-consuming code. JavaScript also offers the functionality to execute some code in a separate thread, independent of the main thread, using web workers. In the succeeding section, we'll discuss the conventional method of writing asynchronous code in JavaScript using callbacks and the problems associated with this approach. To sum up, asynchronous programming in JavaScript allows for the execution of extensive tasks without inhibiting the main thread, resulting in superior performance and user experience. Despite the challenges it presents, with the right understanding and tools, asynchronous programming can be a potent tool in a JavaScript developer's arsenal. In the next segment of this series, we'll dive deeper into the traditional and contemporary methods of writing asynchronous code in JavaScript. Stay tuned! To dive deeper into JavaScript and explore concepts like this, the book Advanced JavaScript Unleashed by Yousaf, an experienced full-stack software engineer, is highly recommended. With a deep understanding of JavaScript and valuable insights shared in this book, any JavaScript developer aspiring to achieve greater heights will find it beneficial.

JavaScript, known for its versatility and power, can pose significant challenges, especially when it comes to comprehending its fundamental concepts like closures . This article aims to debunk misconceptions about JavaScript closures, dive into the details, and highlight the importance of understanding closures in JavaScript programming. A common misunderstanding about JavaScript closures is related to their formation, and that is when a function yields a nested function. This misconception is due to numerous online resources showcasing JavaScript closures through code snippets containing a function that returns a nested function. In reality, JavaScript closures can be implemented irrespective of a function returning a nested function. They form every time a function is declared, encapsulating the environment or scope they originate from. This often goes unnoticed as most functions are invoked in the same scope where they are defined. However, when a function is invoked in a different scope from its definition, the intricacies of JavaScript closures become clear. A JavaScript closure is essentially a fusion of a function and a reference to its creation environment. When a function is defined, it preserves a reference to its originating environment. This collection of a function and its environmental reference is called a JavaScript closure. JavaScript closures enable a nested function to access declarations within the parent function, even after the parent function's execution is completed. Here's a simple JavaScript closure example: In this JavaScript closure example, the inner function can access the outerVar variable, even after outerFn has stopped execution, showing an example of a closure. Grasping the basic concept of JavaScript closures might seem simple, but a profound understanding requires a wider context. This is because JavaScript closures are not just an isolated concept but a fundamental element of JavaScript programming. Mastering JavaScript closures can streamline your JavaScript code, enhancing its modularity and readability. Since JavaScript closures are prevalent in existing code, mastering JavaScript without understanding closures is nearly impossible. JavaScript closures also significantly influenced JavaScript's evolution. Before recent language updates, achieving privacy or modularity was impossible without JavaScript closures. Despite JavaScript now supporting private fields and methods , closures continue to be a vital aspect of the JavaScript toolkit. Understanding JavaScript closures is instrumental to becoming an adept JavaScript developer. They are a pivotal concept that enables data hiding, encapsulation, and code modularity. By avoiding the misconceptions and diving into the core concept, we can appreciate the essential role of JavaScript closures. And the book Advanced JavaScript Unleashed does exactly that. As you progress in your JavaScript learning journey, bear in mind that a closure is not merely a function within a function, but a crucial aspect of JavaScript programming. By thoroughly exploring closures, not only can you demystify this essential concept, but also enhance your efficiency in writing modular and robust JavaScript code.

In the journey of becoming a proficient software developer, understanding and mastering key language features is crucial. JavaScript, a popular programming language, is no exception. One of its most intriguing yet often misunderstood aspects is 'hoisting'. This integral JavaScript feature can be both a boon and a bane. Therefore, every JavaScript developer must comprehend hoisting thoroughly. This blog aims to bring clarity to the concept of JavaScript hoisting, transforming confusion into understanding. JavaScript hoisting is a unique mechanism where variables and function declarations are placed at the top of their containing scope during the compile stage. This fascinating feature empowers developers to invoke functions before they make an appearance in the code. In the code snippet above, despite myVar being declared after the initial log statement, it's hoisted to the scope's top and thus, doesn't result in an error - it simply outputs undefined . Hoisting can be a game-changer in JavaScript, allowing code to be structured with the core logic and file flow at the top. However, it can also lead to unforeseen results if not comprehended properly. It's essential to remember that hoisting isn't a haphazard feature of JavaScript. Its existence can be traced back to the web's early days when JavaScript was interpreted over slow 56k modems. To maximize performance, all initializations were shifted to the "slow start" phase, leading to the inception of JavaScript hoisting. In present times, JavaScript undergoes compilation before execution, rendering hoisting technically unnecessary. However, due to the need for backward compatibility, hoisting remains an integral part of the JavaScript language specification and is here to stay. Mastering JavaScript involves more than just learning syntax, functions, and loops. It requires a deep understanding of fundamental concepts and features like hoisting. To truly excel in JavaScript, it's essential to dive deep into the language, grasp it, and comprehend why certain features act the way they do. For a comprehensive understanding of hoisting, understanding the concepts of declaration, initialization, and assignment is crucial. These fundamental concepts are often the subject of interviews and are core to JavaScript mastery. Hoisting, an intriguing JavaScript feature, can be a source of both utility and perplexity. It emerged from a necessity for optimization in the early days of the web and continues to be an integral part of the language specification. Understanding hoisting is pivotal to JavaScript mastery, aiding developers in writing cleaner, more efficient code. To dive deeper into JavaScript and explore concepts like hoisting, the book Advanced JavaScript Unleashed by Yousaf, an experienced full-stack software engineer, is highly recommended. With a deep understanding of JavaScript and valuable insights shared in this book, any JavaScript developer aspiring to achieve greater heights will find it beneficial.

JavaScript is often misconstrued due to its complex concepts. One such concept that makes developers scratch their heads is Coercion . This article aims to clarify the concept of JavaScript coercion, to equip readers with the knowledge to conquer JavaScript's coercion mystery. The topic of coercion is frequently highlighted as a challenging area within JavaScript. Here are some typical sentences you will hear from developers regarding coercion: What makes coercion a hot debate in JavaScript? Coercion in JavaScript is the automatic conversion of one data type to another without explicit command from the developers. This can lead to unexpected outcomes and hard-to-pinpoint bugs, especially for those not well-versed with the complexities. Numerous JavaScript developers aim to understand core concepts but often find that tutorials, courses, and documentation fall short of their needs. The solution, an age-old proven method to understand stuff in the deepest of depths, books. Advanced JavaScript Unleased in one such book, this book was created specifically to solve the problem of struggling JavaScript developers. To assist in this journey, the book Advanced JavaScript Unleashed has been curated. Designed for developers who have been grappling to comprehend JavaScript's core concepts and features. The book discusses a wide array of topics, including Event Loops , Promises , Symbols , this , Coercion , and more. After interacting with hundreds of JavaScript developers facing exactly the same difficulties, this book was created to tackle them. The author, Yousaf , is a seasoned full-stack developer with extensive experience in JavaScript and Java. He has dedicated more time learning JavaScript than any other language, cultivating a deep understanding that he aspires to share. He holds a Gold JavaScript badge on stackoverflow.com , for answering countless JavaScript-related queries. The path to mastering core JavaScript concepts like coercion doesn't have to be soul-crushing. With resources like Advanced JavaScript Unleashed , readers can gain a profound understanding of these concepts. Don't let the hurdles of learning hinder your progress as a JavaScript developer. Avail the book now: Happy learning!

JavaScript is often misunderstood due to its complex concepts. One such concept that makes developers scratch their heads is Coercion . This article aims to clarify the concept of JavaScript coercion, to equip readers with the knowledge to conquer JavaScript's coercion mystery. The topic of coercion is frequently highlighted as a challenging area within JavaScript. Here are some typical sentences you will hear from developers regarding coercion: What makes coercion a hot debate in JavaScript? Coercion in JavaScript is the automatic conversion of one data type to another without explicit command from the developers. This can lead to unexpected outcomes and hard-to-pinpoint bugs, especially for those not well-versed in the complexities. Numerous JavaScript developers aim to understand core concepts but often find that tutorials, courses, and documentation fall short of their needs. The solution, an age-old proven method to understand stuff in the deepest of depths, books. Advanced JavaScript Unleased in one such book, this book was created specifically to solve the problem of struggling JavaScript developers. To assist in this journey, the book Advanced JavaScript Unleashed has been curated. Designed for developers who have been grappling to comprehend JavaScript's core concepts and features. The book discusses a wide array of topics, including Event Loops , Promises , Symbols , this , Coercion , and more. After interacting with hundreds of JavaScript developers facing exactly the same difficulties, this book was created to tackle them. The author, Yousaf , is a seasoned full-stack developer with extensive experience in JavaScript and Java. He has dedicated more time learning JavaScript than any other language, cultivating a deep understanding that he aspires to share. He holds a Gold JavaScript badge on stackoverflow.com , for answering countless JavaScript-related queries. The path to mastering core JavaScript concepts like coercion doesn't have to be soul-crushing. With resources like Advanced JavaScript Unleashed , readers can gain a profound understanding of these concepts. Don't let the hurdles of learning hinder your progress as a JavaScript developer. Avail the book now: Happy learning!

As a seasoned JavaScript developer, you must have encountered Symbols in your coding journey already. These unique identifiers, often used as a replacement for UUID, offer more than meets the eye. They're instrumental in preventing collisions with keys in objects, as they're inherently unique each time they're created. Many developers tend to overlook the complexity and benefits of using Symbols in the JavaScript landscape. This guide offers an insight into the usage of JavaScript Symbols, both well-known and custom, and how to leverage them effectively. In JavaScript, Symbols are distinct from other data types since they can't be constructed using the new keyword. Instead, you invoke the Symbol() function to create a Symbol. Each symbol is unique and different from any other symbol, even if the description or the name of the symbol is the same. Symbols in JavaScript are typically used as identifiers for object properties. Their unique nature helps prevent name clashes and collisions in your code, thus enhancing your coding efficiency. JavaScript boasts several well-known symbols, including: - Symbol.toPrimitive - Symbol.toStringTag - Symbol.isConcatSpreadable - Symbol.iterator These symbols play an integral role in adjusting the default behavior of JavaScript objects. For example, you can use Symbol.toPrimitive to convert an object into a primitive value. Custom Symbols may not find many applications, but they're vital when you need to add properties to an object that shouldn't interfere with other code sections. Using custom Symbols can mitigate unexpected behavior in your code and ensure your functions work as intended. In the example above, the id property doesn't interfere with other user object properties, ensuring the code functionality remains intact. JavaScript Symbols are a potent tool that lets you add unique properties to objects, prevent collisions, and tweak the default behavior of objects. While they may appear complex initially, comprehending and utilizing them effectively can significantly boost your JavaScript coding prowess. Books such as Advanced JavaScript Unleashed are the best resource for studying JavaScript in-depth. If you're feeling lost or overwhelmed, don't despair. Several resources are available, including comprehensive JavaScript books such as Advanced JavaScript Unleashed that dive deep into Symbols and other advanced concepts. Your growth as a developer often stems from challenging yourself to understand these intricate concepts. So, dive into the captivating world of JavaScript Symbols and elevate your coding skills. Happy coding!

JavaScript, a powerful and widely-used web programming language, is packed with unique features and aspects that can sometimes seem scary to both beginners and seasoned developers alike. One such concept is this , a notorious JavaScript keyword known for its seemingly inconsistent behavior. Grasping this , along with some other crucial JavaScript concepts like the Event Loop and Promises, can significantly improve your coding ability and problem-solving skills. This article aims to simplify this , and several other misunderstood JavaScript fundamentals. In JavaScript, this is a language feature governed by several rules that decide its behavior, based on the context in which it's used. Here are the different scenarios where this can take on different meanings: Many JavaScript developers can survive without an in-depth understanding of this , primarily because their work doesn't really require knowledge of language features in-depth. However, if a job requiring a deeper comprehension of this and other core JavaScript concepts like Event Loops and Promises arises, difficulties can emerge very quickly. Consider this and other fundamental JavaScript concepts as the nuts and bolts of the language. As a developer, you can construct simple frameworks without knowing what these are or how they operate. But as projects become more complex, understanding these small, fundamental parts becomes increasingly important. The Event Loop and Promises are two other central JavaScript elements that frequently baffle developers. The Event Loop is a mechanism in JavaScript that manages asynchronous operations, enabling JavaScript to remain responsive even during long-running operations. Promises, conversely, are objects symbolizing the eventual completion or failure of an asynchronous operation, and its resulting value. Comprehending these concepts, along with this , can dramatically boost your coding skills, enabling you to write more efficient and effective JavaScript code. To master JavaScript, one needs to understand its core features and concepts, including the often misinterpreted this keyword. While these concepts can seem formidable initially, a proper understanding of them can unlock a plethora of opportunities and enhance your problem-solving abilities as a developer. Remember, the journey from being an intermediate to an expert JavaScript developer involves grappling with such intricate details of the language. But with persistence and the right resources such as Advanced JavaScript Unleased — a book specifically created for this purpose — this journey can be a gratifying experience.

JavaScript, known as a versatile and dynamic programming language, plays a significant role in the current web development landscape. However, gaining mastery in JavaScript requires understanding complex concepts like Event Loops and Promises and many more. This article tries to demystify these topics, equipping readers with the essential tools and knowledge to enhance their JavaScript proficiency. JavaScript, a single-threaded, non-blocking, and asynchronous concurrent language (phew, those were a lot of big words), uses Event Loops as the core of its asynchronous behavior. Event Loops manage the execution of multiple code blocks over time, allowing JavaScript to appear multi-threaded on the front while remaining single-threaded on the back. Emerging JavaScript developers often find Event Loops challenging due to its abstract nature. However, mastering Event Loops is crucial for writing clean and efficient JavaScript code. Consider a piece of code that needs to be executed after a specific delay. Unlike other languages that might use a sleep function, JavaScript employs the setTimeout function, which leverages the Event Loop . In this code snippet, 'Hello' and 'Goodbye' print instantly, while 'World' prints after a 2-second delay. This delay is courtesy of the Event Loop via the setTimeout function, which prevents the rest of the code from blocking. Promises in JavaScript signify an incomplete operation that is anticipated to be completed in the future. They provide a method to handle asynchronous operations without succumbing to callback hell. Promises can be in one of three states: A pending promise can either be fulfilled or rejected later. A promise is considered settled once it is either fulfilled or rejected and it cannot alter its state thereafter. Here's a basic example of creating and utilizing a Promise : This example creates a Promise that resolves after 1 second. The then method defines the actions only after the resolution of the Promise . While JavaScript learners have access to a wide variety of resources including videos, online tutorials, and documentation, none can replace the comprehensive understanding a well-written JavaScript book like Advanced Javascript Unleased can provide. A JavaScript book will not only explain the core concepts of JavaScript but also delve into the language's nuances and all those little things that are often missed in other resources. They offer a structured pathway to mastering the language, enhancing the understanding of the reader on how different JavaScript components interact and complement each other. Mastering JavaScript requires a deep understanding of its fundamental concepts like Event Loops and Promises . While other resources can offer a basic understanding, a comprehensive book like Advanced JavaScript Unleased allows readers to dive deeper into these topics, filling knowledge gaps and enabling JavaScript developers to write code that they truly comprehend. Whether you're preparing for a job interview or embarking on a challenging JavaScript project, taking the time to thoroughly understand these complex concepts will save future headaches and assist in writing efficient, non-blocking, and maintainable JavaScript code.

In this article, we will learn how to build an XY line chart with custom annotations using visx and React.visx is a library built and maintained by the folks at AirBnB , that provides low-level visualization primitives for React. It is a thin wrapper around D3.js and is infinitely customizable for any of your data visualization needs. visx provides React components encapsulating D3 constructs, taking away some of the complexities and learning curve involved in working with D3. In this tutorial, we will learn how to use custom annotations to enrich and add context to your line charts using visx and React. We will be charting Apple Inc.’s (AAPL) stock price over the last ten years and overlaying it with annotations for different product launch dates. This will help us understand how the stock price was affected by various important launches in the company’s history. Let us start by creating a stock standard React TypeScript app using create-react-app . We can then install the @visx/xychart library which we need for this tutorial, along with date-fns which we will use for date manipulation. In this tutorial, we will use historical stock price data for Apple (AAPL) from Kaggle. I’ve transformed the raw CSV data into JSON and simplified it to have just two main properties per data point - the x property representing the date and the y property representing the closing stock price at that date. I have also curated an additional dataset containing dates for important Apple product launches and company events in the last ten years. This has been combined with the stock price data - some of the data points have an additional events property which describes the events that occurred around the time as an array of strings. The data can be found in the GitHub repo for this tutorial . Let us use the components from the @visx/xychart library that we installed earlier to create a simple plot using the first dataset from step 2. Let us take a closer look at the different components used in the chart: When the Chart component is instantiated in App.tsx , your app should look somewhat like this: Now that we have a basic chart up and running, we can use the additional data in the events properties to add custom annotations to the chart. This can be done using the Annotation component from @visx/xychart . labelXOffset and labelYOffset are pixel values that indicate how far away the annotation needs to be from the data point it is associated with - this prevents the annotation completely overlapping and obscuring the point in question. We've filtered out the data points from stockPrices that have the events property, and added an annotation for each one that has events. Each annotation has a label that displays the date and all the events for that date. The label is attached to the data point using an AnnotationConnector . With the annotations added, your chart should now look like this: The annotations help provide a better picture of the company over the years, and can offer possible explanations for the variations in share price (do note, however, that correlation does not necessarily imply causation 😉). In this tutorial, we have used the example of Apple's share price variations to understand how to plot an XY chart with custom annotations with visx and React. There are a number of improvements that can be made to the chart, including: You can read more about the XY Chart in the official docs . As always, all the code used in this tutorial is available on GitHub .

In this capstone tutorial, we're going to actually use the micro-library in app code so you can see how the micro-library makes things easier for developers in real world development. In the previous steps of this 4-part tutorial, this is what we accomplished: In this final tutorial, we will now refactor an example component to use the @Component decorator and the attachShadow function from our micro-library. We're refactoring a file, packages/component/src/card/Card.ts , which contains the CardComponent class. This is a regular Web Components custom element. To get it to use our micro-library, we first import Component and attachShadow from our micro-library. Next, we add the Component decorator to CardComponent . We remove the line at the bottom of the file that registers the component, noting the tag name in-card . Remove customElements.define('in-card', CardComponent); . The above code is now automated by our micro-library. We set the selector property to the ElementMeta passed into Component to in-card , the same string originally used to register the component. Next, we move the content of the style tag in the constructor to the new style property on ElementMeta . We do the same for the template of CardComponent . We migrate the HTML to the new template property until the ElementMeta is filled in. Next, we remove everything in the constructor and replace it with a call to our micro-library's attachShadow function, passing in this to the first argument. This automates Shadow DOM setup. To make sure everything is working properly, this is where we start up the development server and observe the changes in the browser. Nothing should have changed about the user interface. Everything should appear the same. Our CardComponent has now been successfully refactored to use the micro-library's utilities, eliminating boilerplate and making the actual component code easier to reason about. That completes this 4-part tutorial series on building a micro-library for developing with Web Components. Our micro-library supports autonomous and form-associated custom elements. It enables developers to automate custom element setup as well as Shadow DOM setup, so they can focus on the unique functionality of their components. In the long run, these efficiencies add up to a lot of saved time and cognitive effort. If you want to dive more into ways to build long-lived web apps that use Web Components and avoid lock-in into specific JavaScript frameworks, check out Fullstack Web Components: Complete Guide to Building UI Libraries with Web Components.

Here is Part 3/4 of our tutorial series on building a JavaScript micro-library for creating your apps with Web Components. As I pointed out in previous lessons, the micro-library eases the path to development with Web Components, automating a lot of the work so developers can build their apps faster. Here's what we covered so far: Now in this tutorial, Part 3, we will automate another piece of functionality for classes that use our decorator. In this case, we'll automatically attach a Shadow DOM to those classes so that the user of the library does not have to manually create a Shadow DOM for their custom elements. Now that we have ElementMeta stored on the prototype of any class using the Component decorator, our next step is to write a reusable function that'll be used in the constructor of the same class to instantiate the Shadow DOM. By abstracting this logic to a reusable function , we'll reduce several lines of code in each component implementation down to one line. Basically, we want to take something like this... ...and reduce it to one line. The first argument of attachShadow is the instance of the class which, in the constructor , you can reference as this . The second argument is the Object that configures the call to element.attachShadow . You can read more about element.attachShadow on MDN . To start development of this new function , make a new directory named template in packages/common/src and create a new file in that directory named index.ts . Create another file in the directory, named shadow.ts . In packages/common/src/template/shadow.ts , create a new function named attachShadow and export it. Declare two arguments for attachShadow : context and options . Make options optional with ? and type define context as any , and options as ShadowRootInit , a type definition exported from lib.dom.d.ts . Follow up in packages/common/src/template/index.ts and ensure attachShadow is exported for the main index.ts . Finally, in packages/common/index.ts , export the attachShadow function. Jumping back to packages/common/src/template/shadow.ts , fill in the algorithm for attachShadow . Make a const named shadowRoot , type defined as ShadowRoot , equal to context.attachShadow . On the next line, make a const named template , equal to document.createElement('template') . This line creates a new HTML template. Set the content of the HTML template using the ElementMeta stored on the prototype of whatever class will use this attachShadow function. Pass in context.elementMeta.style to a style tag and context.elementMeta.template afterward. Finally, append a clone of the HTML template to the ShadowRoot . When you are finished, the attachShadow function should look like this: With Component and attachShadow now supporting autonomous and form-associated custom elements, you can now use the new decorator pattern in actual components. Build the @in/common package again so files inside the @in/ui package can pick up the latest changes. We're almost done building this Web Components micro-library, though there's a lot more features you could add. In the final lesson in building our micro-library, we'll refactor some example components to use the micro-library so you can see how end developers actually use the library. For more about building UI Libraries using Web Components, check out our latest book Fullstack Web Components: Complete Guide to Building UI Libraries with Web Components.

If you've ever wondered how libraries like React , Preact , or Svelte work under the hood, this is a great exploration of what you need to know. Using Web Components means that your own micro-library, which we build in this series, will work easily with any JavaScript codebase. This achieves greater levels of code reuse. Let's dive in. When building with Web Components, you will rely heavily on the set of specifications that make up Web Components: The main benefits Web Components bring to the table: reuse, interoperable, accessible, having a long lifespan, are due to their reliance on browser specifications. Had we adopted a library or framework, we might have lost some or all of these characteristics in the user interfaces built with it. UI components coded with some libraries aren't interoperable with other JavaScript libraries or frameworks, which puts a hard limit on reuse. Even though we gain these benefits from Web Components, we have lost any benefit JavaScript libraries have to offer. Frameworks and libraries like React, Vue, Angular, and Svelte provide an abstraction around browser specifications. React, for example, famously opted for a purely functional approach, giving engineers "hooks" to manage side effects in user interfaces. JavaScript libraries and frameworks provide architectural patterns that make life easier on the part of the web developer, offering features not available with browser specifications alone, like data binding and state management. What if we could retain the benefits of Web Components while also gaining the architectural design of a JavaScript framework? Indeed, there are many such Web Component libraries already. Now you get to build your own. In this 4-part tutorial series , we'll demystify the inner workings of Web Components libraries as you get to develop your own. Using TypeScript decorators, we'll develop a new interface that simplifies development but doesn't compromise on performance. The micro-library we'll code optimizes to less than 1Kb of minified JavaScript. Among its features is that it allows the components we develop to transform from something like this: ...to instead use a TypeScript decorator named Component , like this: Decorators are denoted by the @ symbol, followed by the name of the decorator function , in this case, Component . In the above example, the Component function is called with a single argument: an Object where the developer can declare the tag name, CSS style, and HTML template. These are the advantages of using class decorators to handle templates and styling: In addition to making a class decorator that allows you declare a tag name, styling, and template with a cleaner interface than before, you'll also code a method decorator that simplifies binding event listeners to custom elements. Instead of typing this.addEventListener('click', this.onClick) , what if you could decorate the onClick method and still provide the same functionality? It could look something like this: If all of this seems foreign, don't fret. Coding decorators is much like coding any JavaScript function . Providing these framework-like features to custom elements may be easier than you think. Think of a micro-library as a collection of prewritten code used for common development tasks that has a small footprint. Micro-libraries may have similar functionality as much larger libraries but with way less code that optimizes down to a few Kb or maybe even less than 1 Kb. That's why they are "micro". Micro-libraries have existed for a while. Famously, Preact is a ~3 Kb alternative to the ~45 Kb React. Micro-libraries exist, in part, to provide a more performant alternative to popular JavaScript libraries. In the context of custom elements, micro-libraries are an interesting solution because we can gain the functionality of a JavaScript library with little expense with regards to performance. In Parts 2-4 of this micro-library tutorial series, I'll show you how to identify reusable parts of Web Components code and abstract logic away from each component implementation in a functional manner. You'll code a class decorator that handles declaration of a component selector, styling and template. You'll learn how to use method decorators to attach event listeners to DOM elements. You'll have a basic Web Components micro-library you can expand upon and use in actual apps. For a deep dive into Web Components, check out our latest book -  Fullstack Web Components: Complete Guide to Building UI Libraries with Web Components . It covers how to build robust UI libraries and entire applications using Web Components. 

Web Components are a standard JavaScript technology whose adoption has soared in recent years. Since it enables your components to work in any JavaScript code base , whether you are using frameworks/libraries like React, Angular, Vue, or vanilla JavaScript, you can use Web Components everywhere. Author Stephen Belovarich , Principal Software Development Engineer at Workday, unpacks practical ways to build real world apps using the latest evolution of the web spec. In Part 1 of the book , you learn the basics of Web Components and build some standard component building blocks. Part 2 walks you step by step through building a library for Web Components and leveraging the library in actual development. In Part 3 , you integrate Web Components into a full app with JavaScript on the front end as well as Node.js with Express on the backend. In the course of building these practical projects, these are some of the skills you will learn: Get hands-on experience coding UI with Web Components, but also learn how to test and maintain those components in the context of a distributed UI library in Fullstack Web Components .

When I am working on personal projects, I often find the need to setup an API that serves up data to my app or webpages. I get frustrated when I end up spending too much time on hosting and environment issues. These days what I end up doing is hosting the API using Cloud Functions for Firebase . It hits all my requirements: The official name is Cloud Functions for Firebase. In this article, I am going to call it Firebase Functions. This is mostly to distinguish it from Google's other serverless functions-as-a-service: Cloud Functions. You can read more about the differences here . From that page: While I'm not going to write a mobile app in this article, I like to use Firebase Functions because: If all this isn't confusing enough, Google is rolling out a new version of Cloud Functions called 2nd generation which is in "Public Preview". So in order to move forward, let's identify our working assumptions: After all this is complete, you should have a single file called firebase.json and a directory called functions . The functions directory is where we'll write our API code. We'll take the emulator out for a spin. Congrats, you have Firebase Functions working on your local system! To exit the emulator, just type 'Ctrl-C' at your terminal window. This is all very exciting. Let's push our new "hello world" function into the cloud. From the command line type: The output should look similar, but not exactly to: And if we navigate to the Function URL we should get the 'Hello from Firebase!' message. Exciting! Do you see how easy it is to create Firebase Functions? We've done all the hard part of setting up our local environment and the Firebase project. Let's jump into creating an API using Express Install express: Next, edit the index.js file to look like: Then if you run You can load up your api locally. Note the URL link on the emulator is a little different -- it should have 'api' added at the end like: You should see our 'Hello World' message. Now for more fun, add '/testJSON' to the end of your link. You should see the browser return back JSON data that our API has sent: Now finally, let's deploy to the cloud: Note that when you try to deploy, Firebase is smart enough to detect that major changes to the URL structure have occurred. You'll need to verify that you did indeed make these changes and everything is ok. Since this is a trivial function, you can type Yes . Firebase will delete the old function we deployed earlier and create a new one. Once that completes, try to load the link and validate your API is now working! This article has walked you through the basics of using Firebase Functions to host your own API. The process of writing and creating a full featured API is beyond the scope of this article. There are many resources out there to help with this task, but I hope you'll think about Firebase Functions next time you are starting a project.

Testing is basically a requirement for modern software today, not a nice-to-have. In the past, end-to-end testing was hard to set up, flaky, and generally a pain to deal with, but it's the best automated testing option to confirm software works. Cypress.io continues to improve the e2e testing experience and its new feature Cypress Studio takes it a step further to make writing tests quicker and easier too.Photo by Farzad Nazifi on Unsplash When Cypress.io first hit the scene in 2015, it made a splash because it fixed so many of the issues that existed with other end-to-end testing (e2e) competitor frameworks. Between good documentation, intuitive syntax, improved debugging, and no reliance on Selenium under-the-hood - everything about Cypress was a major step forward for e2es, but it wasn't content just to stop there. The team behind Cypress regularly keeps releasing new features and functionality to make it more and more useful for devs, and make e2e testing (traditionally kind of a pain) easier and easier as well. One recent release that's currently tucked behind a feature flag is called Cypress Studio , and it's an absolute game changer. Today, I'll show you how to add Cypress to an existing JavaScript project, enable Cypress Studio, and let it help do the heavy lifting of writing end-to-end tests. It's such a cool feature to help dev teams save time on testing, deliver new features faster, and still ensure the mission critical functionality of the app continues to work as expected. Although Cypress is kind enough to provide a host of sample scripts to show many of its features in action, it really shines with a local app to test against, and I just so happen to have one that fits the bill. The app I'm using is a React-based movie database that allows users to see upcoming movies and movies in theaters now, browse movies by genre, and search for movies by title. This will be a good app to demonstrate Cypress Studio's power. Once we've got an app to add Cypress to, the first thing we'll need to do is download Cypress to it. This is another reason Cypress stands head and shoulders above its competitors: one npm download gives you all the tools you need to start writing e2es. No dev dependencies, no extra libraries with mismatched package versions, none of that nonsense to deal with. At the root of your project, where your package.json  file lives, run the following command from the terminal: This will add a bunch of new Cypress-based folders and files to your app, and with just a few small configuration changes we'll be ready to go. See all those new folders under cypress/ ? That's what you should see after initial installation. For ease of use, I like to add npm scripts for the two main Cypress commands we'll be using: In your package.json  file, add the following two lines in your "scripts"  section. Now when we need to run the tests, a simple npm run cy:run  or npm run cy:open , straight from the command line, will do the trick.  Ok, before we get to writing our own tests, let's run the pre-populated tests in Cypress to get familiar with the its Test Runner. From your command line, run the following shell command: This should open the Cypress Test Runner, and from here, click the Run integration spec button in the top right hand corner to run through all the pre-made tests once. After all the Cypress tests run and pass, we're ready to delete them and get to work on our own tests for our app. Go ahead and clear all the files out of the Cypress folders of fixtures/ and  integration/ . You'll probably also want to add the folders of cypress/screenshots/  and cypress/videos/  to your .gitignore  file just so you don't commit those screenshots and videos that Cypress automatically takes during test runs to your GitHub repo (unless you want to, of course). Add baseUrl variable With that taken care of, let's set up a baseUrl  in our cypress.json file and enable Cypress Studio there too. Turn on experimentalStudio To enable Cypress studio, just add "experimentalStudio": true  to our cypress.json  file. So here's what the cypress.json  file will end up with. Now we can write our first test file and test. Inside of the cypress/integration/  folder in your project, create a new test file named movie-search-spec.js . This folder is where Cypress will look for all your e2e test files when it runs. Give it a placeholder test: we have to tell Cypress where we want it to record the test steps we're going to show it. So just create a typical describe  test block and inside of that, create an it  test. A good first test would be to test that a user can navigate to the movie search option, search for a particular movie name, and click into the results based on that search. Here's what my empty testing placeholder looks like in the movie-search-spec.js  file. I think we're about ready to go. One thing you must do before starting up Cypress to run tests against your local app is to start the app locally. For Cypress, it's an anti-pattern to start the app from a test, so just fire it up in a separate terminal, then open up the Cypress Test Runner. Start the movie app In one terminal run our movie app: Start the Cypress Test Runner And in a second terminal, open the Cypress Test Runner: In Cypress, Add Commands to Test When the Cypress Test Runner is open, enter our test file and click the tiny blue magic wand that says  Add Commands to Test  when you hover over it. And from here, go for it - test the app. For me, I clicked the Movie Search link in the nav bar, typed "Star Wars" into the search box, clicked into one of the results, etc. When you're satisfied with what your test is doing, click the Save Commands button at the bottom of the test, and Cypress will run back through all the commands it's just recorded from your actions. Tell me that's not cool. If you go back to your IDE now, you'll see all the actions Cypress recorded, along with a few comments to tell you it was Cypress generating the code and not a developer. This is what my test now looks like: Just wow, right? Although our test is good, Cypress can't be expected to test for all the things a developer might know are important. Things like the number of movies returned from searching "star wars" or checking the title of the movie being clicked into and the contents inside of the movie page itself. I'll fill in some of those details myself now.  If you look at my code above, I added comments after the extra assertions I added - mainly small things like checking for search text, the count of movies returned, the movie info like rating and release date in this specific movie. I didn't add a ton of extra code, just a few extra lines of details. Now run the test again and check the results. And we're done! Congrats - our first Cypress Studio-assisted e2e test is written.  Just repeat these steps for as many end-to-end tests as you need to write and prepare to be amazed at how much time it saves you. In modern software, testing is a critical piece of any solid enterprise application. It helps ensure our app continues to function as expected while adding new functionality, and end-to-end testing is the closest we can get to mimicking exactly how a user would use the app with automation. Cypress broke the mold of what e2e testing frameworks are capable of when it debuted back in 2015, and it's only continued to improve with time. My favorite new feature of late is the ability to show  Cypress how a test should act instead of writing it yourself with Cypress Studio - the time saving possibilities are immense. And more time saved means finishing features faster and getting new functionality into the hands of users quicker. Win win win. In 10 modules and 54 lessons, I cover all the things I learned while at The Home Depot, that go into building and maintaining large, mission-critical React applications - because it's so much more than just making the code work. From tooling and refactoring, to testing and design system libraries, there's a ton of material and hands-on practice here to prepare any React developer to build software that lives up to today's high standards. I hope you'll check it out.

Web development is tough enough as it is, something as mundane as mismatched versions of Node in development versus production shouldn't be another thing you have to keep in mind. Volta can prevent this sort of issue and so much more for you and your dev team automatically, and it's easy to set up to boot. Read on to get started using it yourself.Photo by Felix Mittermeier on Unsplash When you're working with a team of developers, especially on a team responsible for managing multiple applications, you very well might have JavaScript apps that run on different versions of Node.js. Some might use Node 10, others Node 12, some may use Yarn as their package manager, others might use npm - and keeping track of all that is really hard. Ensuring every developer on the team is developing with the correct versions all the time is even harder. But it's essential. While the consequences might be relatively minor during local development: it works on one dev's machine and throws an error on another's, this sort of lack of standardization and clarity can have devastating effects when it comes to production. And it could have all been avoided if we'd been using a handy little tool called Volta.  I want to introduce Volta to you today so you can avoid the stress we went through - it's simple to get started with and can prevent catastrophes like this. What this means in practice is that Volta makes managing Node, npm, yarn, or other JavaScript executables shipped as part of packages, really easy. I've told you what Volta is, but you're probably still wondering why I chose it in particular - it's certainly not the only game in town. NVM's another well known option for managing multiple versions of Node. I used to use Node Version Manager (NVM)  myself. Heck, I even wrote a whole blog post about how useful it was. NVM is good, it does exactly what it sounds like: it allows you to easily download and switch versions of Node.js on your local machine. While it does make this task simpler, NVM is not the easiest to setup initially, and, more importantly, the developer using it still has to remember themselves to switch to the correct version of Node for the project they're working on. Volta, on the other hand, is easy to install and it takes the thinking part out of the equation: once Volta's set up in a project and installed on a local machine, it will automatically switch to the proper versions of Node. Yes, you heard that right. Similar to package managers, Volta keeps track of which project (if any) you’re working on based on your current directory. The tools in your Volta toolchain automatically detect when you’re in a project that’s using a particular version of the tools and takes care of routing to the right version of the tools for you. Not only that, but it will also let you define yarn and npm versions in a project, and if the version of Node defined in a project isn't downloaded locally, Volta will go out and download the appropriate version. But when you switch to another project, Volta will defer to any presets in that project or revert back to the default environment variables. Cool, right? Ready to see it in action? For ease of getting started, let's create a brand new React application with Create React App, then we'll add Volta our local machine and our new project. First things first, create a new app. Run the following command from a terminal. Once you've got your new React app created, open up the code in an IDE, and start it up via the command line. If everything goes according to plan, you'll see the nice, rotating React logo when you open up a browser at http://localhost:3000 . Now that we've got an app, let's add Volta to it. Installing Volta to your development machine is a piece of cake - no matter your chosen operating system. Unix If you're using a Unix based system (MacOS, Linux or the Windows Subsystem for Linux  - WSL) to install Volta, it's super easy. In a terminal, run the following command: Windows If you've got Windows, it's almost this easy. Download and run the Windows installer and follow the instructions. Once Volta's finished downloading, double check it installed successfully by running this command in your terminal: Hopefully, you'll see a version for Volta like my screenshot below. If you don't try quitting your terminal completely, re-opening a new terminal session and running that command again. The current version of Volta on my machine is now v1.0.5. Before we add our Volta-specific Node and npm versions to our project, let's see what the default environment variables are. Get a baseline reading In a terminal at the root of your project, run the following line: For me, my default versions of Node and npm are v14.18.1 and v6.14.15, respectively. With our baseline established, we can switch up our versions just for this project with Volta's help. Pin a node version We'll start with Node. Since v16 is the current version of Node, let's add that to our project. Inside of our project at the root level where our package.json  file lives, run the following command. Using volta pin [JS_TOOL]@[VERSION]  will put this particular JavaScript tool at our specified version into our app's package.json . After committing this to our repo with git, any future devs using Volta to manage dependencies will be able to read this out of the repo and use the exact same version. With Volta we can be as specific or generic as want defining versions, and Volta will fill in any gaps. I specified the major Node version I wanted (16) and then Volta filled in the minor and patch versions for me. Pretty nice! When you've successfully added your Node version, you'll see the following success message in your terminal: pinned [email protected] in package.json (or whatever version you pinned). Pin an npm version That was pretty straightforward, now let's tackle our npm version. Still in the root of our project in the terminal, run this command: In this particular instance, I didn't even specify any sort of version for npm, so Volta defaults to choosing the latest LTS release to add to our project. Convenient.  The current LTS version for npm is 8, so now our project's been given npm v8.1.0 as its default version. To confirm the new JavaScript environment versions are part of our project, check the app's package.json  file. Scroll down to the bottom and you should see a new property named "volta" . Inside of the  "volta" property should be a "node": "16.11.1"  and an "npm": "8.1.0"  version. From now on, any dev who has Volta installed on their machine and pulls down this repo will have their settings for these tools automatically switch to use these particular node and npm versions. To make doubly sure, you can also re-run the first command we did before pinning our versions with Volta to see what our current development environment is now set to. After this, your terminal should tell you it's using those same versions: Node.js v16 and npm v8. Now, you can sit back and let Volta handle things for you. Just like that. 😎 If you want to see what happens when there's nothing specified for Volta (like when you're just navigating between repos or using your terminal for shell scripts), try navigating up a level from your project's root and checking your Node and npm versions again. In the screenshot below, I opened two terminals side by side: the one of the left is inside of my project with Volta versions, the one on the right is a level higher in my folder structure. I ran the following command in both: And in my project, Node v16 and npm v8 are running, but outside of the project, Node v14 and npm v6 are present. I did nothing but switch directories and Volta took care of the rest. Try and tell me this isn't cool and useful. I dare you. 😉  Building solid, stable apps is tough enough without having to also keep track of which versions of Node, yarn and npm each app runs best with. By using a tool like Volta, we can take the guesswork out of our JavaScript environment variables, and actually make it harder for a member of the dev team to use the wrong versions than the right ones. And remember to double check your local Node version matches your production server's Node version, too. In 10 modules and 54 lessons, I cover all the things I learned while at The Home Depot, that go into building and maintaining large, mission-critical React applications - because it's so much more than just making the code work. From tooling and refactoring, to testing and design system libraries, there's a ton of material and hands-on practice here to prepare any React developer to build software that lives up to today's high standards. I hope you'll check it out.

Code dependencies are like Lego's . We're able to pull in other people's code; combining and stacking different packages together to fulfill our goals. Using dependencies greatly reduces the complexity of developing software. We can take advantage of the hard work someone has already done to solve a problem so we can continue to build the projects we want. A development pipeline can have multiple kinds of code dependencies: In JavaScript, we have a package.json file that holds metadata about our project. package.json can store things like our project name, the version of our project, and any dependencies our project has. Dependencies, devDependencies, and peerDependencies are properties that can be included in a package.json file. Depending on the instance where code will be used changes the type of dependency a package is. There are packages that our users will need to run our code. A user is someone not directly working in our code-base. This could mean a person interacting with an application we wrote, or a developer writing a completely separate library. In other words, this is a production environment. Alternatively, there are packages that a developer or system only needs while working in our code. For example linters, testing frameworks, build tools, etc. Packages that a user won't need, but a developer or build system will need. Dependencies are packages our project uses in production . These get included with our code and are vital for making our application run. Whenever we install a dependency the package and any of its dependencies get downloaded onto our local hard drive. The more dependencies we add, the bigger our production code becomes. This is because each new dependency gets included in the production build of our code. Evaluate adding new dependencies unless they're needed! Dependencies are installed using npm install X or yarn add X Packages needed in development , or while developing our code, are considered dev dependencies. These are programs, libraries, and tools that assist in our development workflow. Dev dependencies also get downloaded to your local hard drive when installed, but the user will never see these dependencies. So adding a lot of dev dependencies only affects the initial yarn or npm install completion time. Dev Dependencies are installed using npm install --save-dev X or yarn add --dev X Peer dependencies are similar to dependencies except for a few key features. First, when installing a peer dependency it doesn't get added to your node_modules/ directory on your local hard drive. Why is that? Well, peer dependencies are dependencies that are needed in production , but we expect the user of our code to provide the package. The package doesn't get included in our code. This is to reduce including multiples of the same dependency in production . If every React library included a version of React as a dependency, then in production our users would download React multiple times. Peer dependencies are a tool for library owners to optimize their project size. Peer Dependencies are installed using yarn add --peer X I recently released a course, Creating React Libraries from Scratch, where we walk through content just like how NPM dependencies work, and a lot more! We start with an empty project and end the course with a fully managed library on npm. To learn more click the link below! Click to view Creating React Libraries from Scratch!

React Native is a platform for developing apps that can be deployed to multiple platforms, including Android and iOS, providing a native experience. In other words, write once, deploy multiple times . This tenet holds true across most aspects of app development. Take, for example, usability testing. In native development, teams would need to test business logic separately on each platform. With React Native, it only needs to be tested once. The code we write using React Native is good to go on both platforms and, in most cases, covers more than 90% of the entire code base. The React Native platform offers a plethora of options. However, knowing which to use and when comes from understanding how those pieces fit together. For example, do you even need a database, or is AsyncStorage sufficient for your use case? Once you get the hang of the ecosystem around React Native, building apps will become the easy part. The tricky parts are knowing how to set up a strong foundation that helps you build a scalable and maintainable app and using React Native the right way. If we look at the app as a product that our end users will use, we will be able to build a great experience , not just an app. Should that not be the principal aim of using a cross-platform tool? Let's try and break it down. Using React Native we are: Looking at the points above, it's clear that focusing on building our app as a product makes the most sense. Having a clear view of what we are looking to build will help us get there. It will also keep us in check that we are building the right thing, focusing on the end product and not getting lost in the technicalities or challenges of a platform. Storyboarding the app will help us achieve just that. I recommend a Storyboarding approach to build any front-end application, not just apps. This is not the typical storyboard that is created by the design teams, though the idea is similar. These storyboards can be a great way of looking at our app from a technical implementation point of view, too. This step will help us: To start, we will need to go through the wireframe design of the app. The wireframe is sufficient as we will not be focusing on colors and themes here. Next, we will go through every screen and break it down into reusable widgets and elements . The goals of this are multi-fold: For example, let's look at a general user onboarding flow: A simple and standard flow, right. Storyboarding can achieve quite a lot from the perspective of the app's development and structure. Let us see how. Visualize your app from a technical, design, and product standpoint As you will see, we have already defined eight or nine different elements and widgets here. Also, if elements like the search box, company logo, and the cart icon, need to appear on all screens, they can be put inside a Header widget. The process also helps us build consistency across the app. I would recommend building custom elements for even basic native elements like the Text element. What this does is make the app very maintainable. Say, for some reason, the designer decides to change the app's font tomorrow. If we have a custom element, changing that is practically a one-line change in the application's design system. That might sound like an edge case, but I am sure we have all experienced it. What about changing the default font size of the app or using a different font for bold texts or supporting dark mode? The Atomic Design pattern talks about breaking any view into templates, organisms, molecules, and atoms. If you have not heard about it, Atomic Design comes highly recommended, and you can read about it here . Taking a cue from the methodology, we will break down the entire development process into elements and widgets and list out all those that we will require to build the views. How do you do this? The steps are as follows: This process will help streamline the entire development process. You'll end up with a list of widgets and elements that you need to build. This list will work like a set of Lego blocks that will build the app for you. You may end up with a list like this for the e-commerce app: Looking at this list, we might decide to build a carousel widget that works like a banner carousel by passing banners as children, and as a category scroller by passing an array of category icons. If we do this exercise of defining every component for the entire app before we start building, it will improve our technical design and allow us to plan better. The process can also help iron out design inconsistencies as we will be defining all the elements, down to the most basic ones. If, for example, we were to end up with more than four of five primary buttons to define, that could indicate that we need to review the design from a user experience perspective. Source: Google Following this model will make the development approach very modular and set us up for the development phase. By now, we should also have a thorough understanding of: We also have an idea of how the layout of views will look from a technical standpoint: do we need a common header, how will transitions happen if there is animation, and so on. To summarize, we now have a wireframed plan in place that will give us a lot of confidence as we proceed with development.  To learn more about building apps with React Native, check out our new course The newline Guide to React Native for JavaScript Developer .

To get a better understanding of what Svelte brings us, it helps to step back and look at how we got here: Back in the 90s, in the original version of the web, there was only HTML. Browsers displayed static documents without any interactivity. The only way to get updated information, was by reloading the page, or navigating to a new page. In 1995, Netscape released JavaScript , making it possible to execute code on the end-user's machine. Now we could do things like: As developers began experimenting with this newfangled JavaScript thing, they found one aspect really tough: dealing with the differences between browsers. Both Netscape Navigator and Internet Explorer did things in their own way, making developers' responsible for handling those inconsistencies. The result was code like: This kind of browser detection code littered codebases everywhere. The extra branching was a nuisance, like a cognitive tax, making code harder to read and maintain. Translation: not fun. In 2006, John Resig released a compatibility layer called jQuery . It was a way to interact with the DOM without being an expert on browser feature matrices. It completely solved the inconsistency issue. No more if (isNetscape) or if (isIE) conditions! Instead, we could interact with the page using CSS selectors, and jQuery dealt with the browser on our behalf. It looked like this: But there were some challenges here too: In 2010, Google launched AngularJS 1.x , a framework that helps with state management. Instead of writing jQuery code, like: Expressions (called bindings) could be embedded directly inside the HTML: and Angular would sync those bindings for us. Later, if we change our HTML, say by switching an <h1> to an <h2> , nothing breaks with the Angular version. There's no CSS selectors to update. AngularJS components looked like this: The magic was that anytime you changed something on the $scope variable, Angular would go thru a "digestion cycle", that recursively updated all the bindings. But there were some problems here too: In 2013, Facebook launched React , a library for syncing state with UI. It solved some issues that AngularJS 1.x had. It's isomorphic, it can render HTML both on the server and in the browser, fixing the SEO problem. It also implemented a more efficient syncing algorithm called Virtual DOM . Refresher: Virtual DOM keeps a copy of the DOM in memory. It uses the copy to figure out what changes (the delta), while limiting potentially slow interactions with the browser DOM. (Though it's been pointed out that this may be overhead .) It's still conceptually similar to AngularJS, from a state management perspective. React's setState({value}) or in more recently, the useState() hook, is roughly equivalent to Angular's $scope.value = value . Hook example: React relies on developers to signal when things change. That means writing lots of Hook code. But Hooks aren't trivial to write, they come with a bunch of rules , and those rules introduce a extra cognitive load into our codebases . In 2019, Rich Harris released Svelte3. The idea behind Svelte is: What if a compiler could determine when state changes? That could save developers a lot of time. It turns out to be a really good idea . Being a compiler, Svelte can find all the places where our code changes state, and update the UI for us. Say we assign a variable inside a Svelte component: Svelte detects the let statement and starts tracking the variable. If we change it later, say year = 2021 , Svelte sees the assignment = as a state change and updates all the places in the UI that depend on that binding. Svelte is writing all the Hooks code for us! If you think about it, a big part of a developer's job is organizing state, moving state back and forth between the UI and the model. It takes effort, and it's tricky to get right. By offloading some of that work to compile-time tools, we can save a lot of time and energy . Another side effect is, we end up with less code . That makes our programs smaller, clearer to read, easier to maintain , cheaper to build, and most importantly: more fun to work with. P.S. This post is part of a new course called "Svelte for React Devs" So stay tuned!

In this article, we will learn how to implement Firebase authentication in a React app.Firebase is an increasingly popular platform that enables rapid development of web and mobile apps. It offers a number of services such as a real-time database, cloud functions and authentication against various providers. In the following sections, we will build a React app that has three screens: Let's create a new project on the Firebase Console . We will call our project react-firebase-auth Once the project is created, we will navigate to the 'Authentication' tab to set up sign-in methods. For now, let us enable sign-ins with a username and password. The only other thing left to do before we start building our React app, is to add it to the Firebase project. Once we add a web app to our project, Firebase gives us the app configuration, that looks somewhat like this: We will add these configuration values into the .env file in our app. Let's use create-react-app to generate a stock React app. We'll call our app react-firebase-auth . Once this is done, we need to add a few dependencies using yarn add : In the app's .env file, we need to add the values supplied by Firebase in Step 1 like so: More information about how environment variables work can be found in the Create React App documentation . In the src folder, let us create a base.js file where we will set up the Firebase SDK. In app.js , we will wrap our app with the Router component from react-router-dom which will allow us to use routes, links and redirects. In order to store the authentication status and make it globally available within our app, we will use React's context API to create an AuthContext in src/Auth.js . We will hold the currentUser in the state using the useState hook, and add an effect that will set this variable whenever the Firebase auth state changes. We also store a pending boolean variable that will show a 'Loading' message when true. In essence, the currentUser will be null when logged out and be a defined object when the user is logged in. We can use this to build a PrivateRoute component which allows the user to access a route only when logged in. The PrivateRoute component takes a component prop which is rendered when the user is logged in. Otherwise, it redirects to the /login route. We can now use this in our app.js file after wrapping our app with the AuthProvider : Let us now implement the screens that make up our app. We can start with the simplest one, which is the home screen. All it will have is the title 'Home' and a 'Sign out' button that logs the user out of the app. This is done by calling the signOut method from Firebase's auth module. Let's now move on to the signup page, which is slightly more complex. It will have the header 'Sign up', with a form that includes text inputs for email and password, and a submit button. We wrap the component with the withRouter HOC to provide access to the history object. When the form is submitted, we will use the createUserWithEmailAndPassword method from Firebase's auth module to sign the user up. We display an alert in case something goes wrong during this process. If the user creation succeeds, we redirect the user to the home ( / ) page using the history.push API. The login page is very similar to the sign up page, with an identical-looking form. The only difference is that we will log the user in rather than create a new user when the form is submitted. The component also uses the currentUser value from our AuthContext , and will redirect to the / route when the user is logged in. And there we have it - we have just implemented a React app with sign up, login and home screens that uses Firebase authentication to register and authenticate users with their email and password. We have now learned how to implement Firebase authentication with a React app. The code used in this article is available at https://github.com/satansdeer/react-firebase-auth and a video version of this article can be found on YouTube .

In this article, we will learn how to render a simple React app using an express server.Server Side Rendering (SSR) can be a useful tool to improve your application's load time and optimise it for better discoverability by search engines. React provides full support for SSR via the react-dom/server module, and we can easily set up a Node.js based server to render our React app. In the following sections, we will create a simple counter app with React and render it server-side using an express backend. Let us use create-react-app to generate a stock React app. We'll call our app ssr-example . Let us modify the App.js file to implement a simple counter component that displays the current count. It will also render buttons with which the counter can be incremented and decremented. In our app's index.js file, we have the following line which tells React where to render our app. This needs to be slightly modified to work with SSR. To be able to render our app, we must first compile it so that an index.html and the compiled JavaScript is available. You can build the app with the following command: We will use express.js to set up a simple server for our app. You can install it using the following command in your project folder: Since the server needs to be able to render JSX, we will also need to add some babel dependencies. We will also install ignore-styles since we do not want to compile CSS. Let us create a server using the express module we have just installed. To start, create a folder called server in your project folder, and create a server.js file within it like so: We have just defined an express app that will listen on port 8000 when started. With the app.use() statement, we have also set up a handler for all requests to routes matching the ^/$ regular expression. In the next step, we will add code in the handler to render our app. But before we move on to that, we will need to configure our babel dependencies to work with the server we have just defined. To do so, create an index.js file in the server folder with the following code that imports the required dependencies, and calls @babel/register : Let us now add the code that actually renders our app. For this, we will use the fs module to access the file system and fetch the index.html file for our app. If there is an error reading the file, we will return a 500 status code with an error message. Otherwise, we can proceed with the rendering. The index.html has a placeholder element, usually a div with the ID root where it renders the React app. We will use the renderToString function from react-dom/server to render our App component as a string, and append it to the placeholder div . And that is pretty much it! We're now just one step away from being able to get this up and running. Let us add an ssr script to our package.json file to run the server. You can now start the server from your terminal with the command yarn ssr . When you navigate to http://localhost:8000 in your browser, you will see the app rendered as before. The only difference will be that the server responds back with the rendered HTML this time around. We have now learnt how to implement Server Side Rendering with a React app using a simple express server. The code used in this article is available at https://github.com/satansdeer/ssr-example , and a video version of this article can be found at https://www.youtube.com/watch?v=NwyQONeqRXA .

In this article, we will learn how to handle file uploads using react-hook-form.react-hook-form is a great library that provides an easy way to build forms with React. It provides a number of hooks that simplify the process of defining and validating various types of form fields. In the following sections, we will learn how to define a file input, and use it to upload files to firebase. We will use create-react-app to generate a stock React app. We'll call our app react-hook-form-file-input . Once the app is ready, we can navigate into the folder and install react-hook-form . Let us define our form in the app.js file. We can remove all the default markup added by create-react-app , and add a form element which contains a file input and a submit button like so: We can now connect our form element to react-hook-form using the useForm hook. useForm returns an object containing a register function which, as the name suggests, connects a given element with react-hook-form . We need to pass the register function as a ref into each element we want to connect. Now that our file input has been registered, we can handle submissions by adding an onSubmit handler to the form. The useForm hook also returns a handleSubmit function with which we will wrap our onSubmit handler. The data parameter that is passed to onSubmit is an object whose keys are the names of the fields, and values are the values of the respective fields. In our case, data will have just one key - picture , whose value will be a FileList . When we fire up the app using yarn start , we will see this on screen. On choosing a file and clicking 'Submit', details about the uploaded file will be logged to the console. Now that we have learnt how to work with file inputs using react-hook-form , let us look at a slightly more advanced use case for uploading files to Firebase . You can find the code for the Firebase file upload example here . Clone the repo and run yarn to install the dependencies. You can set up your Firebase configuration in the .firebaserc and firebase.json files at the root of the project, and log into Firebase using the CLI . As we've seen earlier, we can install react-hook-form via yarn using: The App.js file contains a file input which uploads a file to Firebase. We can now switch it over to use react-hook-form like so: We have wrapped the input element with a form , given it a name and registered it with react-hook-form . We have also moved all the logic in the onChange event handler into our onSubmit handler which receives the data from react-hook-form . We can run the app using the yarn start command and it will look the same as earlier. Choosing a file and clicking 'Submit' will upload it to Firebase. We have now learnt how to work with file inputs using react-hook-form . ✅ The code used in this article is available at https://github.com/satansdeer/react-hook-form-file-input and https://github.com/satansdeer/firebase-file-upload .

An in-depth look at the Node HTTP module, and how to use it to scale up!The HTTP module is a core module of Node.js, it is fair to say it's one of the biggest responsible for Node's initial rise in popularity. HTTP is the veins of the internet, this website, any site you explore, you use the HTTP protocol to request it from a server, and the server uses the same HTTP protocol to send you back the data you requested. Let's import the module and create a basic HTTP server with it We just created an HTTP Server object, some of its methods are: For a complete list of HTTP server class properties and methods, check out the official docs . In the example below, let's use the callback function to handle HTTP requests and respond to them. req : shorthand for request, is an object from the class   IncomingMessage  that includes all the request information. Some interesting properties are: It's also good to remember that the IncomingMessage extends the <stream.Readable> class, so each request object is, indeed, a stream. res : shorthand for "response", is an object from the class ServerResponse, which contains a collection of methods to send back an HTTP response. Some of the methods are: Each time we write response data with .write(), the chunk of data we passed gets immediately flushed to the kernel buffer. If we try to .write() after .end() has been called, we will get the following error: In an HTTP post request, we usually get a body as part of the request. How do we access it using the Node HTTP module? Remember the request object is an instance of the IncomingMessage class which extends the <stream.Readable> class, in post request we can access the body as a stream of data like this: You could use an application like Postman , to launch the HTTP request to our application, and you would end up with something like this: While you are in Postman, be sure that you are firing POST request. You will also need to set the following configuration in order to set the 'content-type' headers as 'application-json' To handle HTTPS requests, Node.js has the core module https , but first, we need some SSL certificates, for the purpose of this example let's generate some self-signed certificates In your command line (use GitBash if you are on windows) lets run Now let's use the HTTPS module to create an HTTP server The main difference is we now have to read the key files and load them into an options object, that we pass to .createServer() to create our new shiny HTTPS server. Sometimes we would like to do an HTTP request in order to gather data from a third-party HTTP server. We can achieve this by using the Node HTTP module .request() function. In the following example, we will be calling the postman-echo API which returns whatever we send them. But I would suggest instead of using the core HTTP module for sending requests, you use something more sophisticated and user friendly as Axios . The pros of using something like Axios, is promise abstraction, easier to manage errors on requests, and support for really valuable plugins, like Axios retry. In a lot of situations, we can use a framework like Express to create a server instead of doing directly to the HTTP module. Install express using npm in your command line Express will give you a more elegant way to handle all your API routes, handle session data, and will provide you some plugins for authentication, Express is gonna make your life way easier! We've been through a lot, within this short post, but with these few examples, you should have a good grasp on the core functionalities of the HTTP Node core module. It's ideal to understand the inner functionalities of the HTTP module, but for more complex tasks is recommended to use an abstraction library, such as express in the case you are building servers, or Axios in the case you are creating HTTP requests. Have fun and keep coding! Check out the documentation of the modules we used in this post: If you have any questions - or want feedback on your post - come join our community Discord . See you there!

In this article, you'll learn how to create a Node CLI tool to convert a JSON file into a valid CSV file.JSON has become the most popular way to pass data around on the modern web, with almost universal support between APIs and server applications. However, the dominant data format in spreadsheet applications like Excel and Google Sheets is CSV, as this format is the tersest and easiest for users to understand and create. A common function that backend apps will need to perform, therefore, is the conversion of JSON to CSV. In this tutorial, we'll create a CLI script to convert an input JSON file to an output CSV file. If you don't need to customize the conversion process, it's quicker to use a third-party package like json-2-csv. At the end of the tutorial, I'll also show you how to use this instead of a custom converter. To get the most out of this article you should be familiar with the basics of Node.js, JavaScript, and async/await. You'll need a version of Node.js that includes fs.promises and supports async/await and also have NPM installed. I recommend Node v12 LTS which includes NPM 6. Let's now get started making a Node script that we can use to convert a JSON file to CSV from the command line. First, we'll create the source code directory, json-to-csv . Change into that and run npm init -y so that we're ready to add some NPM packages. Let's now create am example JSON file that we can work with called input.json . I've created a simple data schema with three properties: name, email, and date of birth. It'd be very handy to allow our utility to take in a file name input and file name output so that we can use it from the CLI. Here's the command we should be able to use from within the json-to-csv directory: So let's now create an index.js file and install the yargs package to handle CLI input: Inside index.js , let's require the yargs package and assign the argv property to a variable. This variable will effectively hold any CLI inputs captured by yargs. Nameless CLI arguments will be in an array at the _ property of argv . Let's grab these and assign them to obviously-named variables inputFileName and outputFileName . We'll also console log the values now to check they're working how we expect: For file operations, we're going to use the promises API of the fs package of Node.js. This will make handling files a lot easier than using the standard callbacks pattern. Let's do a destructure assignment to grab the readFile and writeFile methods which are all we'll need in this project. Let's now write a function that will parse the JSON file. Since file reading is an asynchronous process, let's make it an async function and name it parseJSONFile . This method will take the file name as an argument. In the method body, add a try / catch block. In the try , we'll create a variable file and assign to this await readFile(fileName) which will load the raw file. Next, we'll parse the contents as JSON and return it. In the catch block, we should console log the error so the user knows what's gone wrong. We should also exit the script by calling process.exit(1) which indicates to the shell that the process failed. We'll now write a method to convert the JavaScript array returned from the parseJSONFile to a CSV-compatible format. First, we're going to extract the values of each object in the array, discarding the keys. To do this, we'll map a new array where each element is itself an array of the object values. Next, we'll use the array unshift method to insert a header row to the top of the data. We'll pass to this the object keys of any one of the objects (since we assume they all have the same keys for the sake of simplicity). The last step is to convert the JavaScript object to CSV-compatible string. It's as simple as using the join method and joining each object with a newline ( \n ). We're not quite finished - CSV fields should be surrounded by quotes to escape any commas from within the string. There's an easy way to do this: It's fairly trivial now to write our CSV file now that we have a CSV string - we just need to call writeFile from an async method writeCSV . Just like in the parse method we'll include a try / catch block and exit on error. To run our CSV converter we'll add an IIFE to the bottom of the file. Within this function, we'll call each of our methods in the sequence we wrote them, passing data from one to the next. At the end, let's console log a message so the user knows the conversion process worked. Let's now try and run the CLI command using our example JSON file: It works! Here's what the output looks like: There's a fatal flaw in our script: if any CSV fields contain commas they will be made into separate fields during the conversion. Note in the below example what happens to the second field of the last row which includes a comma: To fix this, we'll need to escape any commas before the data gets passed to the arrayToCSV method, then unescape them afterward. We're going to create two methods to do this: escapeCommas and unescapeCommas . In the former, we'll use map to create a new array where comma values are replaced by a variable token . This token can be anything you like, so long as it doesn't occur in the CSV data. For this reason, I recommend something random like ~~~~ or !!!! . In the unescapeCommas method, we'll replace the token with the commas and restore the original content. Here's how we'll modify our run function to incorporate these new methods: With that done, the convertor can now handle commas in the content. Here's the real test of our CLI tool...can we import a converted sheet into Google Sheets? Yes, it works perfectly! Note I even put a comma in one of the fields to ensure the escape mechanism works. While it's good to understand the underlying mechanism of CSV conversion in case we need to customize it, in most projects, we'd probably just use a package like json-2-csv . Not only will this save us having to create the conversion functionality ourselves, but it also has a lot of additional features we haven't included like the ability to use different schema structures and delimiters. Let's now update our project to use this package instead. First, go ahead and install it on the command line: Next, let's require it in our project and assign it to a variable using destructuring: We can now modify our run function to use this package instead of our custom arrayToCSV method. Note we no longer need to escape our content either as the package will do this for us as well. With this change, run the CLI command again and you should get almost the same results. The key difference is that this package will only wrap fields in double-quotes if they need escaping as this still produces a valid CSV. So now you've learned how to create a CLI script for converting JSON to CSV using Node.js. Here's the complete script for your reference or if you've skimmed the article:

Working with dates in a Node app can be tricky as there are so many ways to format and display them. The APIs available in native JavaScript are way too tedious to use directly, so your best option is to use a date/time library. The best known and most flexible option is Moment.js . For this article, I'll presume you understand the basics of JavaScript and Node.js. To install Moment you should have Node and NPM installed on your machine. Any current version will do, but if you're installing from scratch, I'd recommend using the Node v12 LTS which includes NPM 6. Other than for simple use cases and one-offs, the JavaScript Date API will be too low-level and will require you to write many lines of code for what seems like a simple operation. Moment is an incredibly flexible JavaScript library that wraps the Date API giving you very convenient helper methods allowing you to easily perform tasks like: Moment can be used in either the browser or on a Node.js server. Let's begin by going to the terminal and installing Moment: With that done, we can now require the Moment library in a Node.js project: The first thing we'll do to use Moment is to create a new instance by calling the moment method. So what is a Moment instance, and what exactly has been assigned to the variable m in the snippet above? Think of the Moment instance as a wrapper object around a single, specific date. The wrapper provides a host of API methods that will allow you to manipulate or display the date. For example, we can use the add method which, as you'd expect, allows you to add a time period to a date: Note that Moment provides a fluent API , similar to jQuery. It's called "fluent" because the code will often read like a sentence. For example, read this line aloud and it should be immediately obvious what it does: Another aspect of fluent API methods is that they return the same object allowing you to chain additional methods for succinct and easy to read code. We said above that Moment wraps a single, specific date. So how do we specify the date we want to work with? Just like with the native JavaScript Date object, if we don't pass anything to the moment method when we first call it, the date associated with the instance will be the current date i.e. "now". What if we want to create a Moment instance based on some fixed date in the past or future? Then we can pass the date as a parameter to moment . There are several ways to do this depending on your requirements. You may be aware of some of the standards for formatting date strings (with unfortunate names like "ISO 8601" and "RFC 2822"). For example, my birthday formatted as an ISO 8601 string would look like this: "1982-10-25T08:00:15+10:00"; . Since these standards are designed for accurately communicating dates, you'll probably find that your database and other software will provide dates in one of these formats. If your date is formatted as either ISO 8601 or RFC 2822, Moment is able to automatically parse it. If your date string is not formatted using one of these standards, you'll need to tell Moment the format you're using. To do this, you supply a second argument to the moment method - a string of format tokens . Most date string formats are specified using format token templates. It's easiest to explain these using an example. Say we created a date in the format "1982-10-25". The format token template representing this would be "YYYY-MM-DD". If we wanted the same date it in the format "10/25/82" the template would be "MM/DD/YY". Hopefully, that example makes it clear that the format tokens are used for a unique date property e.g. "YYYY" corresponds to "1982", while "YY" is just "82". Format tokens are quite flexible and even allow us to create non-numeric values in dates like "25th October, 1982" - the format token string for this one would be "Do MMMM, YYYY" (note that including punctuation and other non-token values in the template is perfectly okay). For a complete list of date format tokens, see this section of the Moment docs . So, if you want to use non-standard formatting for a date, supply the format token template as the second argument and Moment will use this to parse your date string. For example, shorthand dates in Britain are normally formatted as "DD-MM-YYYY", while in America they're normally formatted as "MM-DD-YYYY". This means a date like the 10th of October, 2000 will be ambiguous (10-10-2000) and so Moment cannot parse it accurately without knowing the format you're using. If we provide the format token template, however, Moment knows what you're looking for: A Unix timestamp is a way to track time as a running total of seconds starting from the "epoch" time: January 1st, 1970 at UTC. For example, the 10th of October, 2000 is 971139600 seconds after the epoch time, therefore that value is the Unix timestamp representing that date. You'll often see timestamps used by operating systems as they're very easy to store and operate on. If you pass a number to the moment method it will be parsed as a Unix timestamp: Now we've learned how to parse dates with Moment. How can we display a date in a format we like? The API method for displaying a date in Moment is format and it can be called on a moment instance: As you can see in the console output, Moment will, by default, format a date using the ISO 8601 format. If we want to use a different format, we can simply provide a formatted token string to the method. For example, say we wanted to display the current date in the British shorthand "DD-MM-YYYY": Here's another example showing a more reader-friendly date: While it's the most popular date library, Moment is certainly not the only option. You can always consider an alternative library if Moment doesn't quite fit your needs. One complaint developers have about Moment is that the library is quite large (20kB+). As an alternative, you might try Day.js which is a 2kB minimalist replacement for Moment.js, using an almost identical API. Another complaint is that the Moment object is mutable, which can lead to confusing code. One of the maintainers of Moment has released Luxon , a Moment-inspired library that provides an immutable and unambiguous API. So now you know how to format dates using Moment and Node. You understand how to work with the current date, as well as how to use standard and non-standard date strings. You also know how to display a date in whatever format you like by supplying a format token template. Here's a snippet summarizing the main use case: Parsing and displaying dates just scratches the surface of Moment's features. You can also use it to manipulate dates, calculate durations, convert between timezones, and more. If you'd like to learn more about these features I'd recommend you start with the Moment docs: