DEV Community: benlongcp

Access Granted - ARIA Labels

benlongcp — Mon, 02 Dec 2024 11:45:18 +0000

Accessibility is an often overlooked, but critical facet of web design. Just as wheelchair ramps can allow differently-abled individuals to access a business storefront that would otherwise only be reachable by stairs, web accessiblity tools allow for differently-abled individuals who might otherwise have difficulty using a site to navigate and interact with data.

A common accessibility consideration when designing a user interface might be for users with limited or impaired eyesight. A common but simple design practice might integrate high contrast color schemes into the styling. In the event of near-total visual impairment, however, it might be necessary for a user to employ tools such as screen readers in order to meaningfully interact with a website.

Different screen reading software include: NVDA, JAWS, and WebAnywhere. Screen readers scan the page for different html elements, each of which has an implicit semantic meaning within the context of a given html page. So for example, a button element is contextually different from a span element. So the first and perhaps most important step in designing accessible websites is to use the correct html element for a given context. If it's something that a user should click on, then it should probably be a button, not a paragraph.

There are, unavoidably, times when ambiguity is necessitated given other design considerations. This is to say, sometimes there might be a need to use a div instead of a button, perhaps for stylistic reasons within a sub-menu. This being the case, somebody using a screen reader might run into issues when trying to discern (keeping in mind, they can only hear what's on the screen, not actually see it) which item they should be interacting with.

In order to disambiguate such occurrences, a standardized set of roles and attributes are used in order to contextually differentiate the actual interactive content on a page. Accessible Rich Internet Applications (ARIA) supplement HTML to extend the accessibility technology beyond the implicit DOM element contexts.

Roles are what are used to assign a specific semantic definition to an HTML element. They describe the context of the element within an Accessibility Object Model (AOM), similar to a DOM--a tree of the HTML elements with the accessibility descriptors.

Normally, a screen reader would read an element in the AOM at its default value: as a nav, button, input, etc. When, for whatever reason, the semantic html element is not used (like using divs within a list for example) the ARIA role attribute allows for specification of a different role on the element.

It might look something like this:

//no roles specified, implicit context
<select name="options">
  <option value="option 1"> pick me </option>
  <option value="option 2"> no, pick me </option>
</select>

//no implicit context, roles specified
<div name="options" role="select">
  <div value="option 1" role="option"> pick me </div>
  <div value="option 2" role="option"> no, pick me </div>
</div>

In general, it is better to default to an HTML element with an implicit contextual value. If the need arises to specify the interactive properties of an element, the property aria-label can be used to provide a description beyond the default implicit definition.

So for example, with a button on a page that maybe based on its position implies to a visually-abled user what it's function is; if there is a red button in the corner of a popup window, it might imply its purpose is to close the window. So the aria-label could be used thusly:

<button aria-label="button closes window"> close </button>

The alt attribute is another such label attribute used to describe an image in an image tag, so that a screen reader will default to reading that value rather than a long and unwieldy src attribute which has no meaning to somebody who cannot see. In addition, an empty alt attribute should be placed within image tags regardless, to cut down on proverbial visual noise, as again, the only way a visually impaired person is interacting with the page is through audio cues.

<img src="https://imgs.search.brave.com/eCoy9f72j3Mwq6O9Ame3hYwAwQJFo6c7dyDLtn2nLPI/rs:fit:860:0:0:0/g:ce/aHR0cHM6Ly9pLmt5/bS1jZG4uY29tL3Bo/b3Rvcy9pbWFnZXMv/bmV3c2ZlZWQvMDAx/LzYwMS8yMTcvZmYx/LmpwZw" alt="Frank Reynolds with two guns saying quote so anyway I started blasting"

Ultimately, accessibility is mindful design. There are no programmatic paradigmatic shifts necessary to implement features that extend usability to include people who otherwise not be able it interact with the content. Accessibility requires simply recognition of a differently-abled perspective and inclusion of those elements on top of existing features to facilitate usability for a wider range of users.

ARIA MDN
ROLES MDN
Screen Readers MDN
aria-label MDN

Access Granted - ARIA Labels

benlongcp — Mon, 02 Dec 2024 11:45:18 +0000

It might look something like this:

//no roles specified, implicit context
<select name="options">
  <option value="option 1"> pick me </option>
  <option value="option 2"> no, pick me </option>
</select>

//no implicit context, roles specified
<div name="options" role="select">
  <div value="option 1" role="option"> pick me </div>
  <div value="option 2" role="option"> no, pick me </div>
</div>

<button aria-label="button closes window"> close </button>

<img src="https://imgs.search.brave.com/eCoy9f72j3Mwq6O9Ame3hYwAwQJFo6c7dyDLtn2nLPI/rs:fit:860:0:0:0/g:ce/aHR0cHM6Ly9pLmt5/bS1jZG4uY29tL3Bo/b3Rvcy9pbWFnZXMv/bmV3c2ZlZWQvMDAx/LzYwMS8yMTcvZmYx/LmpwZw" alt="Frank Reynolds with two guns saying quote so anyway I started blasting"

ARIA MDN
ROLES MDN
Screen Readers MDN
aria-label MDN

Using Web Sockets

benlongcp — Mon, 18 Nov 2024 14:59:43 +0000

Maybe you're a little kid and you're visiting your relatives one summer. Maybe they have a basement that has been converted into a game room for your cousins. Maybe there's a tv and n64, and a pool table. And a ping-pong table.

When you're a little kid, your hand-eye coordination is mostly not great, but you really want to play some ping-pong, and since it's not often your cousins have fresh meat to play against you end up going for a few heats.

After summarily demonstrating their proficiency, they perhaps take pity on you or just become bored watching you scramble after the ping-pong ball time and again. No longer do they take Olympian slap shots, instead now, the game becomes something more tranquil, steady. It becomes about keeping the ball bouncing on the table, a steady rhythm willfully exchanged between two cooperative individuals.

This reflexive exchange of an object bears much resemblance to a mechanism in client-server architecture that allows users to exchange data with one-another in real time.

Web sockets are such a tool that allow for real-time communication between two or more separate clients connected to a server.

In a standard case, we might have two clients trying to chat with one-another. If the first client sends a message to a server rest API, the server receives the post request, and then how does the message reach the second client?

The second client must make periodic get requests to the server in order to eventually receive the first client's post. This creates the added problem of latency, in that the second client could send a message before the first client's message arrives.

Using web-sockets, on the other hand, allows for a continuous real-time connection and exchange of information. Instead of the second client having the burden of sending intermittent get requests to the server, the server itself assumes responsibility for receipt of the message and then broadcasting it to any other client to which it has an open connection.

Much like trying to keep a ping-pong ball in-play with a 6-year-old, an affirmative connection and intent must be established. The client sends the ball of information to the server who in turn ping-pongs it back to another affirmatively-connected client.

In web socket parlance, this affirmative connection is known as a handshake. Rather than with a typical get request that is finite and periodic, the handshake is a continuous open channel for information to flow and be redirected.

Practically speaking, using websockets is a combination of back-end server-side code, as well as on the client. In these examples, the library socket.io is used.

The necessary dependencies are as follows:

//after installing dependencies, import into the server
import express from 'express';
import http from 'http'
import cors from 'cors'
import { Server } from 'socket.io'

Here, we create an express instance and apply middleware

//start express instance
const app = express();
//cors is used for middleware
app.use(cors())

The websockets need to use an http server for connections, so upon the express server, we create an http server instance

//makes an http server with the express server
const server = http.createServer(app)

//creates an io server using the http server made with the express server
const io = new Server(server, {
  //some kind of cors options object, idk
  cors: {
    origin: "http://localhost:8080",
    methods: ["GET", "POST"],
    credentials: true,
  },
})

Now we define behavior for what to do with information from the clients connected to the server:

//when the server establishes a connection, it shall do the following:
io.on('connection', (socket)=>{
  //if it receives data marked send_message
  socket.on('outgoing_message', (data)=>{
    //it shall re broadcast that message back to the client
    socket.broadcast.emit("incoming_message", data)
  })
})

Finally at the bottom, we ensure the instance of the http server on the express server is listening.

//The http server listens at this port
server.listen(8080, ()=>{
  console.log("SERVER RUNNING MARATHON")
})

Now on the client side, say in a react component, we ensure we have installed and import the following:

import React from 'react';
import { io } from "socket.io-client";
import { useState, useEffect } from 'react';

With io we can connect to the server:

//creates front-end socket connection to the server
const socket = io("http://localhost:8080");

Our component would might look something like this:

export default function Messager(){

  //creates react hooks for messages sent and received
  const [messageOut, setMessageOut] = useState("")
  const [messageIn, setMessageIn] = useState("")

  //sends a message over the socket
  const sendMessage = () =>{
    //sends the message state
    socket.emit("outgoing_message", { messageOut })
  }

  //when the client socket receives a new message, the incoming message state is updated
  useEffect(()=>{
    socket.on("incoming_message", (data)=>{
      setMessageIn(data.messageOut)
    })
  }, [socket])

  //renders an input a button, and a spot for messages
  return (
    <div>
      <h1>hellooooo there</h1>
      <input placeholder='message' onChange={(e)=> setMessageOut(e.target.value)}/>

      <button onClick={sendMessage}>send message</button>

      <h1>log:</h1>
      {messageIn}
    </div>
  )
}

Visiting the client in a browser will result in the world's most basic messaging app. We input data, that data is sent to the server, the server precipitates our sent data into a broadcast message, so any other open connection to the server will receive the sent message. This, however, lays the groundwork for the capability for users to interact with each other in multitudes of ways, and to do so in real time.

Translating User Stories into Code

benlongcp — Mon, 11 Nov 2024 04:06:07 +0000

Modern software is largely designed in order to solve problems for users, whether that be making calculations for a rocket launch or helping someone decide what groceries to buy.

There are multitudes of approaches to software design. When architecting solutions to common problems, it is often enough to look at the discrete logic for a specific challenge being overcome, ie: these two big numbers need to be multiplied together, this user needs to be authorized, etc.

One other such approach is to view the scope of the implementation wholistically, that is rather than viewing a particular challenge within its own limits of operability, to assume the perspective of a hypothetical end-user through the use of user stories.

User stories can be used to lay the foundation for every decision that is made when putting together a comprehensive web application. When looking to implement a feature in the software, user stories focus on the type of user that is being served, the user's goal when using said feature, and why they might want it to work that way.

Creating user stories is a collaborative endeavor that combines aesthetic design, strategies for user engagement, and a technical understanding of the capabilities and limits of the technology being used. The stories themselves can be written very simply, but they need to convey a range of underlying capabilities.

For example, with a photo sharing website, we might say something like:

> The user can post photos to their profile

This implies several implicit faculties for the implementation of the software. There is a unique user that should presumably have access to an individualized profile. They can upload or access image data and make post requests using that data.

Similarly, another user story might be:

> The user can view their friend's photos

This includes references to capabilities that allow the user to add other users as friends, that perhaps that only users have access to view another user's photos.

From these user stories, the design team can formulate a top-down approach in order to create a pathway through implementation. Similar to how a script might be used on a film set, each feature or scene is broken down into its constituent parts. In film production, ADs and producers typically use what are called "one-liners" which is a data table with each line representing a predefined subset of pages from the screenplay that need to be completed.

A user story will generally have criteria for satisfaction that can be expressed in terms of the parts of the program that need to be written. This may further be dissected into the components or pieces needed to fulfill the criteria, and then the behavior ascribed to them. Following the initial example, of being able to post photos to a profile, we might say:

> if the user is authenticated
> given their profile url
> when the profile page loads
> display photo field component
> display post photo link input
> display post button

Then we might define the behavior of the visible components thusly:

> when the button is clicked
> if the input field has data
> the photo should be fetched
> once the photo is fetched
> photo should display in the photo field

The process of atomizing these solutions can further be translated to the actual code being written. While completion criteria may in some cases be considered subjective, user stories are ultimately validated through the implementation of the components and related behaviors.

This atomization of fulfillment criteria can now be translated into pseudocode, which might resemble the following:

//when the button is clicked
buttonClick = (event) => {

  // if the input has value
  if (input.value){

    //fetch the photo
    let newPhoto = app.get(input.value, callback)

    //append to photofield
    photofield.append(newPhoto)

  }
}

Through this process, the structure of the program can be built up iteratively but with intention, direction and momentum.

There is a certain nontechnical empathic aptitude to placing oneself in the shoes of the user and asking, "does this feel right?" Again the analogue of a film set illustrates a similar relationship. A one-liner and the 5/8ths of a page of dialogue that constitutes having "gotten" the coverage needed to edit a scene is ultimately a matter of a director placing themself in the role of an audience member watching the film for the first time. Does it all make sense together?

project management
agile project management
user stories
tips for user stories

Javascript Design Pattern Types

benlongcp — Mon, 07 Oct 2024 03:21:55 +0000

Software design patters are a ways to think about and categorize different types of solutions to common problems in software development.

At the core of design patterns is the inbuilt idea that they are reusable, that is, they are designed to encapsulate a certain set of use cases and have universal applicability within that set.

A design pattern will follow a certain structure, use certain types of code objects and relationships, but do not necessarily specify a particular syntactical format. More broadly, they represent ways to approach specific implementations to specific problems.

There does not seem to be overall consensus as to what the threshold for a type of problem-solving approach to be considered a design pattern, but generally it can be agreed that there are three primary types of design pattern: creational, structural, and behavioral

Creational design patterns categorize procedures for instantiating objects. Oftentimes code will need to create its own objects for use, and the way that it creates these objects will have significant bearing on its overall functionality.

The way an end-user interacts with an object may change they way an object needs to be created, or the way a certain part of the program interacts with that object may change what should and should not be contained in that object.

A few examples of creational design patterns in javascript:

Constructors make a function with initial input properties that is then instantiated the keyword new, passing in arguments to be set as the key values.

function Cat(name, color, isHungry){
  this.name = name;
  this.color = color;
  this.isHungry = isHungry;
}

const myCat = new Cat("Fiddlesticks", "brown", true);

console.log(myCat)

//Object { name: "Fiddlesticks", color: "brown", isHungry: true }

The builder design pattern creates objects in discrete phases. There is a main base object, on which methods or functions external to it are called upon to modify the object to have the desired properties and values. A very simple example:

const obj1 = {
  username: 'jimmy',
  password: 1234
}

const addStorage = (obj) =>{
  obj.storage = []
}

addStorage(obj1)

console.log(obj1);

//Object { username: "jimmy", password: 1234, storage: [] }

This could also include something like a maker class containing methods for construction another object and then a main class constructor that has the maker class's methods called on itself.

Other creational design patterns include prototypal (as in using object prototypes for inheritance), modules (for limiting access of certain properties to avoid polluting the global namespace, and factories to name a few.

Structural design patterns are concerned with how multiple objects and/or classes are composed and organized into larger structures. They help to define how objects relate to one another

Facade structural patterns create a uniform interface for several other unrelated sub-processes. They are designed to abstract away complex functionality of multiple other systems and provide the client with a standardized way to interact with the sub-systems.

class Donkey{
  sound(){
    console.log("hee-haw")
  }
}

class Ogre{
  sound(){
    console.log("shut up, donkey")
  }
}

class DreamworksShrekMovieFascade{
  constructor(){
    this.donkey = new Donkey();
    this.ogre = new Ogre();
  }
  bigRedButton(){
    this.donkey.sound();
    this.ogre.sound();
  }
}

const shrek = new DreamworksShrekMovieFascade()
shrek.bigRedButton()

Other structural patterns include the bridge structural pattern, which connects two systems but maintains independence such that changes to one system will not affect the other, and the decorator pattern, which makes it possible to modify the behavior of a given object by "decorating" with with a function.

Behavioral design patterns involve communication and interaction between objects and classes. It focuses on ways that functionality is delegated and the hierarchical network of object relationships.

The simplest example of a behavioral pattern is the concept of iteration through a collection of data. So structures such as for loops, and higher order functions like forEach, filter, map and reduce are all ways to traverse data uniformly and are not coupled with the particular data being iterated through.

A more involved behavioral pattern in the strategy pattern, which creates a set of algorithms that can be switched out with one-another to easily facilitate adaptational functionality.

For example:

class SpaceTime{
  constructor(timeline){
    this.timeline = timeline
  }

  enterTimeline(){
    this.timeline.enter()
  }
}

class FutureTimeline{
  enter() {
    console.log("AAAAHHHH A ROBOT IS EATING ME!")
  }
}

class PastTimeline{
  enter(){
    console.log("AAAAHHHH A DINOSAUR IS EATING ME!")
  }
}

const future = new SpaceTime(new FutureTimeline());
future.enterTimeline();

const past = new SpaceTime(new PastTimeline())
past.enterTimeline();

We create a class SpaceTime that constructs a timeline, and has a method to enterTimeline. Next we create a class pointing to the future, and onther looking to the past. Each has its own enter function. Now when we instantiate a future timeline, we do so passing it into a new SpaceTime object. This way we can re-use our same enterTimeline function on both past and future timelines.

These examples are by no means a comprehensive representation of all possible design patterns, but hopefully helped to clarify some of the different ways programs can be written to facilitate a variety of different specific functionalities.

Sources
geeksforgeeks
dofactory
Design Patterns in JavaScript: A Comprehensive Guide
JavaScript Design Patterns
The Comprehensive Guide to JavaScript Design Patterns

Promises, Promises

benlongcp — Mon, 30 Sep 2024 04:48:47 +0000

I promise to get to Promises, but first...

Let's say we are running some potentially very time intensive tasks, and because we don't want to just pause our program the moment the interpreter starts to do said task, we need to find a way to have a function that performs an operation and still allows the program to run. This is essentially what callback functions do.

When a function is passed into another function, its resolved value can essentially be stored within that function and then accessed when the outer function is called.

For example, if we wanted to describe a round of duck-duck-goose, we could do it using callbacks:

//we define two functions that take callback function parameters
function duck(cbFunc){
  let duck = "...duck..."
  //and invoke those callbacks on some value
  cbFunc(duck)
}

function goose(cbFunc){
  let goose = "...goose!"
  cbFunc(goose)
}

//now we write a function to play duck-duck-goose
function playDDG(){
  //we call duck passing in a function that...
  duck(person1 => {
    //...logs the input of the passed-in function...
    console.log(person1)
    //...and calls duck passing in a function that...
    duck(person2 => {
      //...logs the input of the passed-in function...
      console.log(person2)
      //...and calls goose passing in a function that...
      goose(person3 =>{
        //...logs the input of the passed-in function.
        console.log(person3)

      })
    })
  })
}

console.log(playDDG())

While this is an effective work-around to the issue of storing a resolved value until it is needed, the syntax of the nested functions can quickly blossom out of the bounds of readability.

This is where I fulfill my earlier promise.

The Promise object represents the eventual completion (or failure) of an asynchronous operation and its resulting value (MDN).

While difficult to state it more eloquently than the official documentation, we can maybe say some things in that are true about them to construct a more comprehensive understanding.

Promises are objects, proxies for another value that is not yet accessible by the program

Promise objects are created and given asynchronous code to execute.

New Promise objects take in up to two parameters:
A callback function for a fulfilled promise.
A callback function fora Rejected promise.

Promises have one of three states:

Pending, not resolved or rejected
Fulfilled, the promise has been resolved
Rejected, the promise has been rejected :-(

Promises are used as an alternative to callbacks because they can be chained.

Because it is an object, it has some methods. One of which is. then().

Let's say we have a Promise object:

//it takes a resolve callback and a reject callback
let mathPromise = new Promise((resolve, reject) =>{
  //we do some operation inside
  let three = 3;
  let four = 4;
  if (three + four === 7){
  //if we have met the criteria, we resolve
  resolve(`Yes it is ${three + four}`)
  } else {
  //if not we reject
  reject("...no")

  }})

The .then() method tells us what to do next should the promise be returned resolved. It's basement-dwelling fish-mutant sibling is the .catch() method, to catch that something has gone wrong somewhere and throw an error.

  //if mathPromise returns resolved, then
  mathPromise.then((thenFuncVal) => {
    //log the value of the successful resolve
    console.log(thenFuncVal)
  }).catch((catchFuncVal)=>{
    console.log(catchFuncVal)
  })

Callbacks are stored in the object .then() is called on and a new promise object is returned, thus these method invocations are chainable.

  //we make a new promise
  let wordPromise = new Promise((resolve, reject)=>{
    let word1 = "hello"
    let word2 = "HELLO"
    if (word1 === word2.toLowerCase()){
      resolve("I heard you the first time")
    } else {
      reject("WHAT?")
    }
  })

  //we verify our mathPromise
  mathPromise.then((thenFuncVal) => {
    console.log(thenFuncVal)
    //and if it resolves, we return our wordPromise object
    return wordPromise
  })
  //and then we verify that returned wordPromise
  .then((thenFuncVal) => {
    console.log(thenFuncVal)
  })
  //and if anything gets rejected, we make sure to indicate that rejection
  .catch((catchFuncVal)=>{
    console.log(catchFuncVal)
  })

If we changed a value say in mathPromise such that it was rejected, we would log the value in the reject portion of that conditional, but also we would no longer evaluate wordPromise.

While this aims only to describe the mechanical operation of promise objects, their use in asynchronous programming is indispensable. They preserve the functionality of using callbacks while being able to use object method syntax.

Great resource on promises

MDN: Asynchronous Javascript

MDN: Promises

Test-Driven Development

benlongcp — Mon, 23 Sep 2024 06:23:25 +0000

Basics of test-driven development with Mocha/chai

Writing tests is an effective way to implement code that accomplishes specific tasks. Unit testing allows a developer to create a way to ensure the program is behaving as expected.

Testing frameworks are sets of guidelines and operations that collect results of tests and provide them to the tester. Mocha is such a testing framework.

An assertion library contains sets of functions and methods to implement tests. These are what actually test the code to see if it's working. Chai is one of several assertion libraries.

Test driven development (TDD) performs specific checks on the code's functionality to see if the code behaves as expected. For example, checking to see that a function returns whether two values are equal.

Behavior-Driven Development (BDD) focuses more on what an end-user would expect the code to be able to do. For example, when they get a new email, they should see it in their inbox.

Chai has three assertion libraries that it uses. The first is Assert. Assert is a function-based assertion style, TDD as noted above, it is not chainable, and doesn't modify the object it's checking. It can include an optional message as the final parameter to indicate to the tester what the result should be.

Expect is a BDD style assertion library. It is designed to be more readable than Assert. Thus, it is a chain-able assertion style with object getters to create "sentences" with easier to understand language. They don't modify the object they're accessing. Expects can include an optional message as the final parameter

Should is also a BDD style assertion library. It uses the same chainable language as Expect, but differs in that it extends an object with a "should" property, and modifies that object's prototype. The actual function is invoked . Finally, it does not allow for custom messages

Writing a simple test for some code.

In this example, I'm using node.js to run tests with Mocha. Mocha looks for a test folder in the main directory of the project and a test.js file within that.

Here is a simple function that adds two numbers:

//here is a simple function that adds two numbers
export default function (a, b) {
    return a + b
}

I'm exporting this function for another script to be able to import. In my test/test.js, I'll import the function from the test.js in the main directory.

//test/test.js

//imports tests.js from the parent directory
import add from '../tests.js';
// import { expect } from 'chai';
import { assert } from 'chai';

    it('should return 5', function() {
      assert(add(2, 3) === 5)
    })

And indeed when we run npm test in the terminal, we get a beautiful green checkmark.

But what if we want our add function to do a little more? What if we're making a game and the numbers going into our add function are two dice rolls that will allow the character to, say, jump over a ravine. Maybe when we roll doubles we want a critical success so their chances of jumping all the way are increased. (For this example we'll presume snake-eyes is always an automatic failure.

To write a test for this, we might say the following:

//when the numbers are the same, multiply them
    it("should return a square on doubles", function() {
      assert(add(3, 3) === 9)
    })

And when we run the test...

Womp womp.

So now we have to modify the incoming function to make the test pass, which we can do thusly:

//here is a function that adds two numbers
//and squares them when they're equal
export default function (a, b) {
  if (a === b){
    return a * b
  }
    return a + b
}

And behold, the test now passes:

The real power in unit testing and testing in general is the ability to create suites of tests and so allowing the programmer to focus on the individual elements of functionality that eventually cohese into a final product. They allow for traversal of complex implementations in discrete pieces that are more manageable than a vast empty repository.

sources:
[https://www.chaijs.com/guide/styles/]
[https://medium.com/@dezsays/understanding-chai-a-comprehensive-guide-to-the-javascript-assertion-library-a382d5617832]

Spread Syntax

benlongcp — Fri, 02 Aug 2024 02:06:35 +0000

In JavaScript, spread syntax is a way to expand an indexed or iterable datatype into a iterable datatype, specifically an array or object.

Whereas rest syntax uses a similar structure to spread, rest parameters allow a function to be passed an unknown quantity of arguments. Spread syntax inverts this process such that an individual collection is protracted into its constituent elements.

This is particularly useful when an object or array needs to have its elements transferred to a new object or array. Additionally, in a function's arguments, the spread operator can be used to pass individual elements to the function's parameters.

For example, let's say we have an array of letters:

const letters = ['c', 'a', 't']

And let's say we have a function that takes three elements and does something with them:

let spell = (x, y, z) => {
  return y + x + z;
}

If we want to pass the individual elements from out letters array, we can use the spread operator when we call the function and it will automatically disperse the array elements into the arguments list:

console.log(spell(...letters));
// => logs "act"

As mentioned, we can also copy iterable elements from an array (or string).

const moreLetters = [...letters];
console.log(moreLetters);
// => logs ['c', 'a', 't']

This can also allow us to combine or concatenate arrays more easily:

const evenMoreLetters = [...letters, ...moreLetters];
console.log(evenMoreLetters);
// => logs ['c', 'a', 't', 'c', 'a', 't']

The array can also be spread into an object, where the array element is the value, and the index number is the key:

const objLetters = {...letters}
console.log(objLetters);
// => logs { 0: "c", 1: "a", 2: "t" }

Objects can also be merged using the spread syntax:

const objUno = {
  'one': 1
}

const objDeux = {
  'two': 2
}

const objDrei = {...objUno, ...objDeux};

console.log(objDrei);
// => logs { one: 1, two: 2 }

While merely scratching the surface, this demonstrates the syntactical power of the spread operator in streamlining tasks such as copying and combining iterable datatypes, as well as passing multiple arguments to a function. As always, the less code we have to write, the easier our lives as developers will be.

Citations: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax