DEV Community: Adam Smolenski

My first Reactions to Vue

Adam Smolenski — Sat, 27 Mar 2021 21:31:04 +0000

So the current project I am working on is in Vue. Which is similar to React but just different enough to make things slightly confusing. So here I am just going to babble and hope to sort things in my head as I go. So unorganized short thoughts, and probably more to come next week as I'm using Tailwind in the project.

Creating a component in React has made a ton of sense to me in the past but Vue seems slightly more organized.
In React you can simply do a functional with a return

import React from 'react'

function ImAComponent (props){
  return(
     <div>
       Hey I'm a Component!
       <p> {{props.message}} </p>
     </div>
  )
}

It's a function so the return is what you get out. Props are passed in as an argument, and can be rendered in {{}}.
In a class component it is slightly different where you have render() as the function that returns the JSX (html) logic. Props can be accessed through this.props.
In Vue all your HTML faked in lives in the template side. So here is the basic snippet for an empty Vue component.

<template>
  <div>
     I'm a Vue Component
  </div>
</template>
<script>
  export default {
    name: "ImAComponent",
    props: {
      message: {
          type: String,
          default: "I'm A Prop",
          required: false 
          }
     }
  }
</script>
<style scoped>
</style>

So you can see here you have the template up top, but all your real business logic is in the script area. This is also where you would import anything else that you need. But this is where all the business logic will live. Where as react you can have things all over the place. Props are part of the declared values in each component in Vue. You have to know what you expect.

TypeScript is making this more of a necessity in React but regular old React you'll get errors and not know if you have random props being passed in. You get a TypeScript light implementation with Vue, declaring what types should be expected. Since I have started in VueX instead of Vanilla Vue, I have not gone through $emitting functions as of yet, but that will handle functions a level above being passed as a prop. VueX is very similar to redux with store implementations and allowing state to be shared across components.

That brings us to something else... what about state??!?! Well with functional React components with useState and setting variables causing a rerender. as well as this.setState for a class component. This is all kept in the data portion of the script.

<script>
  export default {
    name: "ImAComponent",
    props: {
      message: {
          type: String,
          default: "I'm A Prop",
          required: false 
          }
     },
   data (): {
  return {
   current: "I'm part of the state"
      }
    }
 }
</script>

So the tricky thing to remember here is that data is a function and acts like an object. There are some weird quirks of Vue that I'm still getting the handle of. In the script to reference the data in a method you use this.current, but in the template vue you can access it in the body of the html as {{ current }}. Also binding things in the template body is also interesting.

Let's dive into what I mean by binding. I will admit this is something I have come to very much appreciate from Vue. It took some getting used to.

<div v-if="boolean here">

</div>

That will only render if the statement there evaluates to true! Oh man that is so much prettier than the ternary stuff that happens in React. You can also do v-show Which is a css display option.
Another thing is for loops are much prettier in vue
Say you have an array of people

[
  {name: "Hal', 
  id: 2001},
  {name: "ValJean",
   id: 24601},
  {name: "Jenny",
   id: 8675309}
]

<ul>
  <li v-for='person in people' :key='item.id'>
    {{person.name}}
  </li>
</ul>

`
Everything is encapsulated, you're not mapping it's just all nice and tidy in that function

Hal
Valjean
Jenny

Will be how it renders... the key is still present since you have the virtual dom keeping track of updates, but hey there is a : before key, why is that. : before something means to treat it as a javascript variable or function and not a string. It's how you can interpolate which is the equivalent of react's use of {}.

The last thing I will speak of my appreciation of view is the sections of computed and methods. So again these live in the land of the script. Methods just make sure you have all your functions in one place, it's a nifty way to keep organized. Depending on sprawling you React logic is, you can get lost. Also computed is neat of you have to do math, you can have it run once and have to perform that function in the render just the load. So that has some performance value on re-renders which is kind of cool.

Anyway I'm sure I will have more to say about vue in the future but it's kind of fun.

Need to test API webhooks on local host? ngrok is a great solution.

Adam Smolenski — Sun, 21 Mar 2021 22:14:46 +0000

So recently I was trying to incorporate the mailgun api to keep track of user engagement with emails (did they just toss them out, like I usually do for certain mailing lists". So I wanted to add the built-in opened event from mailgun. But before deploying it into the real world I was trying to figure out how to get the webhook locally... You can't very well add localhost:3000 to the webhook, that just won't work.

Enter ngrok. It's a simple little tool that allows IP tunneling. So when you run the program, it will generate a secure url that will forward to your local host.

It's extremely simple and free for small use cases like mine was. It was limited to 40 connections a minute. So heck, I'd just keep my tests slow paced. The only thing I had to remember was in the end I was using a subdomain so that was just adjusting my routes on deploy. But on the $5/month plan it's quite simple.

To get started all you have to sign up. Download ngrok, on the mac I had to allow my terminal to open it. Mac has some fun security these days. But after you download you should unzip the file somewhere you will remember to access it. I put it in the base folder of the project I needed it, since it's a tool that will be commonly associated with these files.

When you finish that, ngrok will assign an auth token with your account. In the folder you threw ngrok file in you can just enter ./ngrok authtoken YOUR_TOKEN_HERE.
After that you are pretty much done. All you have to type in the terminal after that is ./ngrok http https://localhost:3000. You can throw in whatever port you want. I was using rails so 3000 was my backends default. After running that function, it will give you an informational display. It will give you the internet address in a form of https://SOMETHING.ngrok.io log request types and where they were headed. When I saw my POST request to /notification from mailgun popping in I was delightfully surprised at the ease of adding this new test tool to my arsenal. It also means I can also test outside network devices for other projects and just see how they load differently depending on networks.

For something so easy to implement it is vastly useful. Hopefully it's a useful program for you to use.

Better Heroku experience deploying a frontend only React App with a simple Express server

Adam Smolenski — Fri, 12 Mar 2021 20:17:51 +0000

So recently I was working on a portfolio project... you can see so me of my struggles in my previous post talking about my colorblindness and input from friends... Wondering how the rest of the world sees my work. Also this works into my post about google's site optimization. I still have a far way to travel with that but with one change I went from an 11 performance to 40 because I worked under the wrong assumptions for a heroku deploy. I'm going to dive into WebPack in the future for all of this.

However, to get a portfolio up and then creating a backend separately I wanted just to get a standalone React app... so I was just using the same git repository that I have my app in Github and just pushed that to heroku... Then checking out the stats on Web.dev... Javascript wasn't minified?!?! It was running start but not building before then.

With some work in Node/Express and wanting to get something up on a page and not building out a Procfile also, this would give me an easy entry point if I decided to go through Node instead of building a Rails API. Still to be determined with some experimenting with GraphQl integrations... If you're reading this and have thoughts on ORM integrations with GraphQl, I really am leaning into TypeORM over ActiveRecord but let know.

Anyway... Having used Node and Express to host a built site, where I did build since I tried to keep everything on one dyno before, I decided I could do the silly thing, move my heroku git to specific be the build folder that is contructed with the yarn build command and building my Express instance there to serve up the html.
I like separation of concerns so I made a folder with the build as a subdirectory of it, so I can build out my express instance in the base folder.
So in that base folder run npm install express and create a file called app.js.

In only a few short lines in app.js we will be able to serve up our app. Here is the entirety of the code of app.js

const express = require('express')
const path = require('path');

const app = express()
const port = process.env.PORT || 3000
app.use(express.static(path.join(__dirname, "build")));

app.listen(port, () => console.log(`Server is running on port ${port}!`))

So the key here is the express using the static files in the build folder. It will automatically look for index.html and run off of that. All your javascript and css will be minified and mapped so you can still debug if need be. It will make google so much happier to see. And you can also look at our new package.json which heroku will read off of, and in it's simplicity adding a start with a node buildpack it will run that line after deploying and you'll be all set.

{
  "name": "build",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "start": "node app"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "express": "^4.17.1"
  }
}

Also by not building it on heroku you save a ton of space and time in deploying. I was being silly before this little experiment but going forward will review previous deploys.

Any colorblind front-end developers?

Adam Smolenski — Mon, 08 Mar 2021 20:36:34 +0000

This may be a silly question... I am still working on breaking into Web Development but a common thread has been coming up. As I work on portfolio projects I share with friends, every time they mention the colors being off. I know I'm colorblind, so does this mean I should focus on backend work?
Are there folks in this line of work who are also colorblind and give me some guidance? I love working with React and other frameworks but if this would sort of cause problems down the end, I hope to find out sooner rather than later :).
Also due to this is it a bad idea to make a portfolio with mainly black white and grey which seems to be my comfort zone?

How binary search made me rethink how to debug.

Adam Smolenski — Sat, 06 Mar 2021 18:44:09 +0000

Here's the thing... My favorite part of my career on Broadway was when things went wrong. Running a show over and over again no matter how good it is you get sort of into a zone where "Wait we're in Act Two?", you go on autopilot. Maybe I can't admit it but I'm secretly an adrenaline junky, but how your mind can think of solutions and run through problems in a moment like that is really exciting. That and chatter over a walkie talkie makes you feel important. So, how does this relate to code? Well its problem solving... somethings not working, either input isn't going through, data is not being manipulated or TypeScript just hates you.

We will go through my journey, because I love to talk and just had a large cup of coffee.

My strategy in code has changed now I'm working with bigger and bigger projects. Where I started, came from my knowledge in audio but some of the basic rules still apply.

First and foremost... READ THE ERROR MESSAGE!!! or log, oh heroku how I've grown accustomed to your logs... sorry My Fair Lady joke. Most times they will tell you what line it broke on. This won't tell you why but it gives you a starting point. Most of the time it's a silly typo or just data parsed differently (thank you linters for showing my faults 90% of the time). If it goes beyond that... then what?

Usually you have an idea and work on that... move on to something else... then go back to your first idea and wonder why it still doesn't work. That's not very efficient. In audio, the practice usually is you can start at the end or the beginning and chase it down the chain. So if you don't hear anything from a speaker, you go to the speaker... is it plugged in? Yes, does the cable make another speaker work? Maybe... but you chase it from one end to the other. You can start at the console if that makes more sense... audio is passing to what point? Now here I've realized this logic has a lot to do with physicality. These are physical objects that have a linear path. In some places it's a long walk from speaker to amplifier to console so you chase it down the chain instead of having everyone wonder "Why is this person walking in circles?". With code... everything is at your fingertips more or less. You may have to log into a server or check an API call but you're seated, the circles are all in your mind.

I have a habit of trying to figure things out before going straight to google. It is a more constructive method for me to learn that way, so instead of doing the walk back from the end as I would with audio... Binary Search works amazing in this to cut down what the problem may be.

You have input and you're expecting certain output. So hopefully you have a grasp of where the ins and outs are happening. The most time efficient method would be to go to the the middle and see if you are getting what you expect there. Print statements are handy for this... Most of the time things will be fine midway through, so you jump to the next midway. There if you get an undefined or an error, you know it's before that. And again you travel... So this may sound like an odd method coming from the logical down the chain of events. Say you have an error on step 9 of 20 step process... The first place you would try is 10... no go, then 5, nope 7 or 8... nope you'll reach 9 in about 5 steps depending which side of the rounding you decide on. So that's 4 less steps than start at the beginning. and 11 less if you started at the end. Depending how much wading you need to do in the code, this seems way more reasonable and you feel like you're making progress. Instead of sitting and trying random solutions, you figure out what it isn't until you found out what it is... Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth.

So there you are... But when that fails there may be a rubber duck nearby.

Filepond in React to a Dropbox folder with an Express backend

Adam Smolenski — Sat, 27 Feb 2021 17:30:33 +0000

So a challenge I recently had to tackle was getting a file upload to go to a specific dropbox.
Some caveats are that this was behind a paywall so the security issues were not as dire as an open website and the media was personally reviewed by a human before reposting so there was no concern of inappropriate images being put back into the world. There are some APIs that can handle that but for now, let's just link an upload from react to a Dropbox folder.
So let's start with some tools we will need for the backend.There will be a few different libraries here outside of the regular old express. I used dropbox-v2-api, fs and multer to serve up the file once it reached my backend before processing and sending it to dropbox. Another thing to note, this was hosted on heroku and due to their ephemeral system I was able to utilize the tmp folder and not worry about impact on my system.
The Dropbox API is pretty self-explanatory but what is multer and fs? Multer is middleware to handle multi-part forms. Since sending a file is considered a multipart form (there are probably other part's to the form... get it?). I haven't had coffee yet so my jokes are probably awful. FS is just filesystem asynchronous promises for handling of files.
Let's go through the base imports and some of the settings on multer that we will have for express first.

const express = require("express");
const keys = require('./keys');
const fs = require("fs");
const cors = require("cors")
const dropboxV2Api = require("dropbox-v2-api");
const multer = require('multer');
const storage = multer.diskStorage({
    destination: (req, file, cb) => {
        cb(null, '/tmp/');
    },
    filename: (req, file, cb) => {
        const fileName = file.originalname.toLowerCase().split(' ').join('-');
        cb(null, fileName)
    }
});

var upload = multer({
    storage: storage,
    fileFilter: (req, file, cb) => {
        if (file.mimetype == "image/png" || file.mimetype == "image/jpg" || file.mimetype == "image/jpeg") {
            cb(null, true);
        } else {
            cb(null, false);
            req.error = 'Only .png, .jpg and .jpeg allowed';
            return cb(null, false, new Error('Only .png, .jpg and .jpeg format allowed!'));
        }
    }
});

On top we have the storage working out. To reiterate since we have heroku as an ephemeral system we store it in the tmp folder and it will be cleared out. One reason I did this is incase I wanted to implement that external API for NSFW photos I could send it through the filter before sending it to dropbox.
The filename parsing was just to protect against whitespace and standardize convention... probably could have made it a regex expression as well, but that's what came to mind first. So that first part is setting up all of our storage options locally on the server now to the upload part.
We were only looking for certain filetypes, the original intention of the project was to just take screenshots from peoples journey through the app so those typically fall into the jpg or png category depending on what tool you are using so we set up the filter there. On the else side of the clause we are creating an error message that would be sent back to the frontend to warn our users they're not sending an acceptable filetype.
Another aside... I'm importing keys so you don't see my dropbox token. I chose to link this to a specific folder.. to do this we can start by creating an app at Dropbox Developer. Create an app, change permissions so you can write files. That's extremely important since this permission is tied to the key being generated. After that is done you can generate a token that doesn't expire. Copy that over to a keys.js and do a lovely export. module.exports = { DROPBOX: your key here}
Now let's get to the upload route portion of the backend.

const app = express()
app.use(
    cors({
        origin: "http://localhost:3000"
    })
);
app.get("/", (req, res) => {
    res.send("potato")
})

app.post('/upload', upload.any(), (req, res) => {
    if (req.error) {
        return res.json({ errors: req.error })
    }
    let { path } = req.files[0]
    let filetype = req.files[0].mimetype.split("/")[1]

    let { folder, user } = req.body
    const dropbox = dropboxV2Api.authenticate({
        token: keys.DROPBOX
    });
    const params = Object.freeze({
        resource: 'files/upload',
        parameters: {
            path: `/${folder}/${user}.${filetype}`
        },
        readStream: fs.createReadStream(path)
    });
    let dropboxPromise = new Promise(function (resolve, reject) {
        dropbox(params, function (err, result) {
            if (err) {
                reject(err);
            } else {
                resolve(result);
            }
        });
    });

    dropboxPromise.then(function (resultObj) {
        console.log("fileUpload_OK")
        return res.json({ success: "Your file has been successfully added." })
    }).catch(function (err) {
        console.log(err)
        return res.json({ errors: err })
    });


})

app.listen(5000, () => {
    console.log(`Server successfully created on Port: 5000`);
});

You can ignore the send of potato... I just like having that to makesure if I'm using an API that I am able to check I didn't break anything... I should start leaving a signature on things right? As a stagehand we used to leave our marks in random ceilings in 100 year old theaters. This is easily edited but who knows.
We have upload.any(), this means we can send a number of files back. We will focus on just one, but you may adjust your code as necessary. The parameters for the upload were set up earlier. So we are just going to get the first object because on the frontend I will limit to one file upload. I am getting the filetype from the mimetype, mainly because I want to rename these files in dropbox, and want it to transfer into the right format. The path is the filepath on the users computer. Folder and user are two variables taken from the frontend. Since these files were uploaded on a per performance situation (it was the theater project I've mentioned before). The folder was actually the show schedule and user well... was the user. For something that is more open you may want to use a UUID to makesure there are no collisions, for this usecase Username was unique, so that was not a concern.
Next part we are logging into our dropbox API with our token. We establish an object with a readstream of our file to transfer while then starting a Promise to ensure we can wait for a success or failure. Once it's resolved we can return a json object to tell our users if it was a success or a failure. So this is a quick overview of what is happening. Much of the magic is handled by the dropbox API.
Let's create our frontend now to hook it up and see if it works. We will be using filepond because it has some neat features and makes drag and drop easy. We will also use axios in our react component so we can send the form to the backend. Also filepond-react and filepond, here I'm just going to use UUID instead of username, so do what you want with that.
So here is what our frontend will look like.

import React, { useState } from 'react';
import { FilePond } from 'react-filepond';
import 'filepond/dist/filepond.min.css';
import axios from 'axios'
import {v4} from 'uuid'
const Upload = (props) => {
   const [photo, setPhoto] = useState()
    const [errors, setErrors] = useState("")
    const [success, setSuccess] = useState(false)
    const onSubmit = (e) => {
        e.preventDefault()
        setErrors("")
        if (photo && photo.length > 0){
        let formData = new FormData()
        formData.append('photo', photo[0].file)
        formData.append('folder', new Date())
        formData.append('user', v4())
        setErrors("Sending File")
        axios.post(`http://localhost:5000/upload`, formData, {
        }).then(res => {
            console.log(res.data)
            if (res.data.errors){
                setErrors(res.data.errors)
            }else if(res.data.success){
                setSuccess(true)
            }
        }).catch(e=> setErrors(e))}else{
            setErrors("Please select an image file first.")
        }
    }

    const renderErrors = () => {
        if (errors !== ""){
            return (
                <div>{errors}</div>
            )
        }else{
            return null
        }
    }




    return (
        <>
        {success ?
        <div>Upload Success!</div>

:

            <div style={{height: "300px", width:"400px", margin: "auto"}}>
                <form onSubmit={onSubmit} >
                <FilePond
                    labelIdle={"Drag your file here"}
                    credits={true}
                    file={photo}
                    name="photo"
                    allowMultiple={false}
                    instantUpload={false}
                    onupdatefiles={(fileItems) => setPhoto(fileItems)}>
                </FilePond>
            {renderErrors()}
            <div >
                <button type="submit">Upload</button>
            </div>
        </form>
            </div>
}
        </>
        )
};

export default Upload;

So walking through this again... the first three variables are just setting our status, photo will be the file after it is dragged and dropped onto filepond, errors so we can show any errors that may arise like wrong filetype, no file or maybe our server went down... it happens. Success is just there to get rid of the filepond once we are uploaded.
Formdata here is the multi-part that we were talking about with multer. So each append is adding a part of the form. Those are also what we are deciphering in our backend. The rest seems pretty self explanatory. The filepond options used are labelIdle for the message on first render. Credits are for the filepond team to make some money for their good work. File is the controlled part of our previous useState photo. Allowmultiple can give you the option of uploading several files at once. Instant upload will enable filepond to upload as soon as you drop, I disabled that and added the button just because sometimes you have users who make mistakes, lets not clutter our filesystem :). On update, in case they make that mistake you want to swap that file out. Once you hit upload, it goes off to the dropbox folder for your app...

Have Fun!!!

Recursively climb an object to find it's full path.

Adam Smolenski — Thu, 18 Feb 2021 19:57:53 +0000

So recursion can be intimidating, I find myself constantly thinking of numbers and base cases, then figuring it all out from there. APIs and nested data makes me happy... It's like a scavenger hunt. Where's this data and how can I find it. So I came across a fun example of originally trying to find a file path. Given a target file and a file structure can you recreate the path as a string. Which I realized could be extremely useful if you have a JSON object and you're trying to find a specific variable. There are some APIs that are just a huge headache sifting through data. Sort of why I am enjoying GraphQL but that's another story.

For the purpose of this walkthrough and my unimaginative process let's use a file tree. I used to get lost in the Rails file tree all the time so I feel like we can recreate that with some embellishment to make it trickier to find where we are going. Here's how we can represent the path as an object.

let rails = {
    '/app': {
        '/channels': {
            '/application': {
                'channel.rb': null,
                'connection.rb': null
            }
        },
        '/controllers': {
            '/concerns': {
                '.keep': null
            },
            'application_controller.rb': null },
        '/jobs': {
            'application_job.rb': null
        }

    },
    '/config': {
        '/environments': {
            'development.rb': null,
            'production.rb': null,
            'test.rb': null
        }
    },
    '/db': {
        'schema.rb': null,
        'seeds.rb': null,
        '/migrate': {
            'create_tables.rb': null,
            'fix_columns.rb': null
        }
    }
}

If we were to just find that our file is in there that's easy just keep going through each directory an once we find it return true... That would look something like this:

function findFile(structure, target) {
    for (let subdir in structure) {
        if (subdir === target || findFile(structure[subdir], target)) {
            return true
        }
    }
    return false
}
console.log(findFile(rails, 'fix_columns.rb'))

That will return true since fix_columns is somewhere in there... but how can we come to that code in the first place?

Think of the simplest file structure given... just one directory, so let's take

folder = {
            'create_tables.rb': null,
            'fix_columns.rb': null
        }

So here we just need to iterate over the keys and check it against our target file

function findFixColumns() {
    for (let key in folder) {
        if (key === 'fix_columns.rb') {
            return true
        }
    }
    return false
}
console.log(findFixColumns())

So going back to our recursive look, how an || statement works is the left side is evaluated before the right, and will return true if just the left is true. So by diving repeatedly deeper on the right side, by the base case will return true if it has exhausted all options. So that leaves us with our simple, hey it's found on a higher level, "I'm true, get me out of here!" solution. How can we go from there into getting the file path now? Well in Javascript a string is considered true.. so in theory we can work on what we just did and compile a string, instead of just returning true. So we can build on that with two different cases in mind, finding the file and then building on folders.

function findFilePath(structure, target) {
    for (let subdir in structure) {
        if (subdir === target) {
            return `/${subdir}`
        }
        let found = findFilePath(structure[subdir], targetFile)
        if (found) {
            return `${subdir}${found}`
        }

    }
    return null
}

So here, our basecase is finding the target file. It will return a string, which will translate to true. If that isn't the top level, we will continue on in our function and search the filepath in the subdirectories, since found is our basecase return we build off of that and apply our subdir which is the directory it is found in... so when we try this for our fix_columns.rb friend, the return would be:
/db/migrate/fix_columns.rb.
Woooo, we've recursively found our file by figuring out the base case and building up.

For me these word problems seem way less stressful than dealing with numbers and fibonacci but that may be my love of puns. Not all recursion is scary. One of my favorite recursive functions for a production app was with the Eventbrite API being very cranky and only giving 50 results at a time when I needed 200... So recursively called and added to an array... such fun times. APIs have so much data that manipulating it into what you want may be stressful, but just think of it as wordplay and you might just enjoy it.

TypeScript. She's crafty, just my Type....Script. Breaking down tsconfig

Adam Smolenski — Sat, 13 Feb 2021 21:13:39 +0000

Ok maybe the Beastie Boys are not the best introduction to TypeScript, but bad jokes make me happy. Errors do not, so I have decided to dive into the settings of tsconfig.json, that could make or break your day. I will be honest, at first I was resistant to TypeScript. I liked Ruby and Python originally but felt way more free in Javascript. But TypeScript saves time in the end. A lot of your testing is done for you in the compiler, the errors make right before you pour your next cup of coffee are highlighted before you refill (no offense CoffeeScript). It really is a handy tool. Also, it seems to be one of the directions we are headed in, so when you start a TypeScript project you need this thing called a tsconfig.json file. This will enable you to manipulate what angers the TS gods, and what you can get away with. With this, let's go through the compiler options... and there are a few, we will separate them into Basic Options, Strict options, Additional Checks, Module Resolution Options, Source Map Options, Experimental and advanced... Why? Because that's how they separate them as you type tsc --init. Clever I know. Here's what generates when you type that:

{
  "compilerOptions": {
    /* Visit https://aka.ms/tsconfig.json to read more about this file */

    /* Basic Options */
    // "incremental": true,                   /* Enable incremental compilation */
    "target": "es5",                          /* Specify ECMAScript target version: 'ES3' (default), 'ES5', 'ES2015', 'ES2016', 'ES2017', 'ES2018', 'ES2019', 'ES2020', or 'ESNEXT'. */
    "module": "commonjs",                     /* Specify module code generation: 'none', 'commonjs', 'amd', 'system', 'umd', 'es2015', 'es2020', or 'ESNext'. */
    // "lib": [],                             /* Specify library files to be included in the compilation. */
    // "allowJs": true,                       /* Allow javascript files to be compiled. */
    // "checkJs": true,                       /* Report errors in .js files. */
    // "jsx": "preserve",                     /* Specify JSX code generation: 'preserve', 'react-native', or 'react'. */
    // "declaration": true,                   /* Generates corresponding '.d.ts' file. */
    // "declarationMap": true,                /* Generates a sourcemap for each corresponding '.d.ts' file. */
    // "sourceMap": true,                     /* Generates corresponding '.map' file. */
    // "outFile": "./",                       /* Concatenate and emit output to single file. */
    // "outDir": "./",                        /* Redirect output structure to the directory. */
    // "rootDir": "./",                       /* Specify the root directory of input files. Use to control the output directory structure with --outDir. */
    // "composite": true,                     /* Enable project compilation */
    // "tsBuildInfoFile": "./",               /* Specify file to store incremental compilation information */
    // "removeComments": true,                /* Do not emit comments to output. */
    // "noEmit": true,                        /* Do not emit outputs. */
    // "importHelpers": true,                 /* Import emit helpers from 'tslib'. */
    // "downlevelIteration": true,            /* Provide full support for iterables in 'for-of', spread, and destructuring when targeting 'ES5' or 'ES3'. */
    // "isolatedModules": true,               /* Transpile each file as a separate module (similar to 'ts.transpileModule'). */

    /* Strict Type-Checking Options */
    "strict": true,                           /* Enable all strict type-checking options. */
    // "noImplicitAny": true,                 /* Raise error on expressions and declarations with an implied 'any' type. */
    // "strictNullChecks": true,              /* Enable strict null checks. */
    // "strictFunctionTypes": true,           /* Enable strict checking of function types. */
    // "strictBindCallApply": true,           /* Enable strict 'bind', 'call', and 'apply' methods on functions. */
    // "strictPropertyInitialization": true,  /* Enable strict checking of property initialization in classes. */
    // "noImplicitThis": true,                /* Raise error on 'this' expressions with an implied 'any' type. */
    // "alwaysStrict": true,                  /* Parse in strict mode and emit "use strict" for each source file. */

    /* Additional Checks */
    // "noUnusedLocals": true,                /* Report errors on unused locals. */
    // "noUnusedParameters": true,            /* Report errors on unused parameters. */
    // "noImplicitReturns": true,             /* Report error when not all code paths in function return a value. */
    // "noFallthroughCasesInSwitch": true,    /`* Report errors for fallthrough cases in switch statement. */
    // "noUncheckedIndexedAccess": true,      /* Include 'undefined' in index signature results */

    /* Module Resolution Options */
    // "moduleResolution": "node",            /* Specify module resolution strategy: 'node' (Node.js) or 'classic' (TypeScript pre-1.6). */
    // "baseUrl": "./",                       /* Base directory to resolve non-absolute module names. */
    // "paths": {},                           /* A series of entries which re-map imports to lookup locations relative to the 'baseUrl'. */
    // "rootDirs": [],                        /* List of root folders whose combined content represents the structure of the project at runtime. */
    // "typeRoots": [],                       /* List of folders to include type definitions from. */
    // "types": [],                           /* Type declaration files to be included in compilation. */
    // "allowSyntheticDefaultImports": true,  /* Allow default imports from modules with no default export. This does not affect code emit, just typechecking. */
    "esModuleInterop": true,                  /* Enables emit interoperability between CommonJS and ES Modules via creation of namespace objects for all imports. Implies 'allowSyntheticDefaultImports'. */
    // "preserveSymlinks": true,              /* Do not resolve the real path of symlinks. */
    // "allowUmdGlobalAccess": true,          /* Allow accessing UMD globals from modules. */

    /* Source Map Options */
    // "sourceRoot": "",                      /* Specify the location where debugger should locate TypeScript files instead of source locations. */
    // "mapRoot": "",                         /* Specify the location where debugger should locate map files instead of generated locations. */
    // "inlineSourceMap": true,               /* Emit a single file with source maps instead of having a separate file. */
    // "inlineSources": true,                 /* Emit the source alongside the sourcemaps within a single file; requires '--inlineSourceMap' or '--sourceMap' to be set. */

    /* Experimental Options */
    // "experimentalDecorators": true,        /* Enables experimental support for ES7 decorators. */
    // "emitDecoratorMetadata": true,         /* Enables experimental support for emitting type metadata for decorators. */

    /* Advanced Options */
    "skipLibCheck": true,                     /* Skip type checking of declaration files. */
    "forceConsistentCasingInFileNames": true  /* Disallow inconsistently-cased references to the same file. */
  }
}

Basic Options

"incremental": boolean
Already starting with a TS joke, so Incremental is a boolean and it's how we are starting this post... incrementally. For large projects this is a nice thing to have. It will refer to a buildinfo and only compile things that have to be compiled or changed. Essentially it's watching and not running all the compilations over again. So it's efficient use of memory... why wouldn't you want to do this? If it's a small project, this is annoying on first start up because it's kind of slow, there have also been reported bugs with its use (not truly compiling everything), that have been mostly been sorted out. Good to be aware of though.
"target" : 'ES3' | 'ES5' | 'ES6' | 'ES2015' | 'ES2016'| 'ES2017' | 'ES2018' | 'ES2019' | 'ES2020' | 'ESNEXT'
This is probably one of the most widely used compiler options, you want to tell typescript in what version of ECMAscript to compile to. ES3 is the default, probably ill-advised if you're starting a new project. This makes sure you are following the rules of that version as well as compiling in a manner that it will play nicely with other non-typescript files of that generation.

"module" : 'none | 'commonjs' | 'amd' | 'system' | 'umd' | 'es2015' | 'es2020' | 'ESNext' If you weren't aware before modules are a new thing to Javascript... go figure you can organize your code better. Each generation of JS has a different method of importing and exporting modules, and this nifty little guy is what tells the compiler how to do it. So you can write modern TS and have it work with older systems by just setting this to their level of specificity. The battle of require vs import is strong.

"lib": string[] Ok there are a lot of options here, so I'm going to be lazier than before. Here is where you can specify what Javascript libraries you want. Say you're not working in a browser, you don't need to have "dom" definitions. This will minimize bloat of your application if that is essential to your process. Similar to target, but this is telling your typescript what it wants to know and what it doesn't from certain javascript APIs.

"allowJs": boolean Why are we allowing Js? We're working in TS right? Well sometimes you are working with older libraries and don't have the time to convert them, by setting this to true you can still import javascript files into your typescript project. Otherwise watching over your typescript you'll get an error.

"checkJs": boolean Working with its friend allowJs, this will throw errors if there is something wrong with compiling the javascript. It type checks functions that are part of your library. If you only want certain .js files compiled you can also put a // @ts-check at the top of them.

"jsx": 'preserve' | 'react-native' | 'react' So here's where you get into some fun things when you are doing frontend work. How do you want to compile your JSX? This can change your .tsx file into react where it will compile to a React.createElement and go through the motions there, the preserve mainly does not change the JSX just parses through the types. So here you can either skip babel or continue with babel transpiling.

"declaration": boolean If set to true this will generate a .d.ts for exported components so others can integrate those modules.

"declarationMap: boolean This will allow text editors to go back and find the declarations to it's original .ts sourcefile. Actually very helpful when troubleshooting or just trying to figure where the types are declared. While learning TypeScript I have used other libraries implementations of this to figure out how I was ruining their work :).

"sourceMap": boolean Maps what the heck you did wrong in the compiled js and points you to where it is in your typescript files. Handy when those errors pop up so you can follow it all the way back to its source.

"outFile": string In case you are generating one javascript file this is where you would name the destination file in your repo.

"outDir": string Similar to the above but preserves file structure and just compiles all the javascript into a mirrored directory.

"rootDir": string Root directory of input files... helps your compiler traverse the files and make sure everything is in the right place.

"composite": boolean When set to true this will change some default settings, it will set the rootDir to where the tsconfig.json is, you will also have to make sure the patterns in your files line up or you will get some unhappy build errors.

"tsBuildInfoFile": string This is where your build file will be referenced, so if you have incremental set to true, this is where it will check for information on what has been created and what it needs to update.

"removeComments": boolean Well, just like the variable says, when compiling this will remove any comments you have left in your code.

"noEmit": boolean This will not compile output files, normally used if you are using Babel or swc to convert typescript and just have TS locally for a text editor checker.

"importHelpers": boolean So the ts library has some functions that make it's compiled code slightly more readable. So if you have our next variable of downlevelIteration on but helpers off, the syntax for-of, spread and a lot of the newer JS tools will get real funky. There was a reason that these weren't in the original JS, it took some time to write them out and make them work, and after looking at what it compiles to, I can't blame them... for hilarities sake the example below.

export function shiftLuckyNumber(arr: number[]) {
  const arr2 = [13, ...arr];
}

becomes

var __read = (this && this.__read) || function (o, n) {
    var m = typeof Symbol === "function" && o[Symbol.iterator];
    if (!m) return o;
    var i = m.call(o), r, ar = [], e;
    try {
        while ((n === void 0 || n-- > 0) && !(r = i.next()).done) ar.push(r.value);
    }
    catch (error) { e = { error: error }; }
    finally {
        try {
            if (r && !r.done && (m = i["return"])) m.call(i);
        }
        finally { if (e) throw e.error; }
    }
    return ar;
};
var __spreadArray = (this && this.__spreadArray) || function (to, from) {
    for (var i = 0, il = from.length, j = to.length; i < il; i++, j++)
        to[j] = from[i];
    return to;
};
export function shiftLuckyNumber(arr) {
    var arr2 = __spreadArray([13], __read(arr));
}

The helpers are just that top bit being imported from the tslib

"downLevelIteration": boolean
Similar to what I said above, but this provides support for those operations when targeting ECMAscript versions that don't necessarily have these options built in. So it allows the silliness you see above.
"isolatedModules": boolean
So depending if you are using other transpilers. Some only can operate on single files and not understand some dependencies from other files. Setting this to true will give you a warning if when using those transpilers will break. Also if this is set to true, everything TS is reading has to be treated as a module, since that is how it is going to read it. So no global script files.

Strict

Now on to a section where nuns and rulers come to mind... So many rules to follow, and here is where I have been finding most of my errors, and making things more lax depending on what libraries I'm integrating. Setting things to the any type just doesn't feel right.

"strict": boolean Well... yeah, this enables all strict type-checking. So everything that follows until our additional checks section would be enabled. You can piecemeal the rest of the options to better suit your needs, especially if you're transporting a JS project into TS

"noImplicitAny": boolean So this one is probably the simplest to get around. You have to give it some sort of declaration. You have to provide to typescript some sort of expectations otherwise you will get yelled at

"noImplicitThis": boolean Similar to the above but this... hehehe. has to do with class's and constructors when you are declaring this, you have to say what it is.

"strictNullChecks": boolean This is actually something I really appreciate, go figure. TS will raise an error if it thinks there is a possibility you may get null or undefined. If that is behavior you want, you can tell the function that hey maybe there's nothing here. It safeguards against a lot of assumptions which leads to more logic and safety. I find this most useful in react when implementing API returns, sometimes you may not have any information, and this will let you know right away.

"strictBindCallApply": boolean This option checks function arguments to make sure the parameters given line up with the expected values. So if you are passing a function a string and declare it to be a string, you can't give it a number instead. When regular JS would just try to make everything play happily.

"strictPropertyInitialization": boolean When creating classes this will ensure that your constructor will contain the variables that the class expect to be there by default. Just double checks that you make things in the proper way and all variables that are expected to be there live in the right place.

"noImplicitThis": boolean You have to tell TS what this is. It can't be implied to be any. Just double checks that if you call this somewhere else that it is following the right syntax whether you are in ES6 or before.

"alwaysStrict": boolean Just like the nuns... Basically it adds the "use strict" to all it's emitted files.

Additional Checks

Well these things are slightly more lenient, and helpful, less yelly unless you want that.

"noUnusedLocals" boolean Makes sure that you use variables that have been declared.

"noUnusedParameters": true Makes sure when you pass in arguments to a function that you are indeed using them.

"noImplicitReturns": boolean Ok... so also another one of my favorites. Sometimes when working in Ruby where returns just happen on the last executed line of code, this check makes sure you are returning something and checks that it the type you expect.

"noFallthroughCasesInSwitch": boolean Ensures that you have a break or a return when using switch statements, also makes sure you have a default fallback so everything gets evaluated.

"noUncheckedIndexedAccess": boolean Enabling this will add undefined to type not specifically declared in the interface but attempted to be accessed through the object.

Module Resolutions Options

"moduleResolution": 'node' | 'classic' TS even admits you probably won't ever use classic, but this is a setting that will tell the compiler how to figure out where imports are. Node and classic have different ways of checking for dependencies. Remember modules are relatively new, so node ensures that if it can't find a module specifically it knows to go into node_modules. When importing relative modules, they have similar strategies but it is typically the npm installed or yarn added requirements that may cause it to be confused.

"baseUrl": string Where to start looking for non absolute modules, so base relative path. Must use if you are going to use custom paths

"paths": {} This can map out dependencies if they differ from the baseUrl, also can provide some shortcuts in case your file tree gets really deep.

"rootDirs": string[] This tells the compiler that there can be multiple base directories on compiling, if you are generating css it may have a different relative path, so this ensures that TS will check both places before it gets cranky.

"typeRoots": string[] This is where the compiler will look for your d.ts files. Normally TS will look for @types files, but declaring this will overwrite that and have TS check that directory ignoring the @types.

"types": string[] Declaring certain libraries in here will only allow what you type in to be referenced globally. In which case you would have to locally import the types you need for certain modules.

"allowSyntheticDefaultImports": boolean If false you TS will not generate a default export, you will have to go to the file and specifically declare one.

"esModuleInterop": boolean This checks that you are requiring or importing modules appropriately based on their generation. So importing * as bob from 'bob' with work similarly to import importing bob from 'bob, and const bob = require("bob"). Also adds some stability for libraries that specifically require .default.

"preserveSymlinks": boolean This will change the behavior of referencing linked files. If it's true it will go to the location of the relative file instead of the location where your link resolves to.

"allowUmdGlobalAccess": boolean Exports from UniversalModuleDefinition files are allowed globally. So your bundler can allow access to that module everywhere instead of explicitly having to require it. Libraries like jQuery will be there when you're up and running but you're not necessarily importing it.

Source Map Options

"sourceRoot": string Instead of the relative path, you can specify the direct location for typescript files.

"mapRoot": string Tell the debugger where to find your map files, all so you can go back to where your error began.

"inlineSourceMap": boolean Embeds your mapping into the compiled js file instead of creating a separate file for it.

"inlineSources": boolean Setting this with the above configuration will also generate the ts source code at the bottom of the .js file

Experimental options

"experimentalDecorators": boolean Decorators are not implemented universally yet which is why they are experimental. It's how you can effect the output of a function with simply putting @ImADecorator() above the function or class. Something from python originally, but a lot of newer libraries are using this. Recently using ORMs with Graphql mikro-orm and typeorm really make life easier with the decorators.

"emitDecoratorMetadata": boolean Gives the metadata of what is going on with the decorator, works with the library reflect-metadata. It will give the information from the surrounding method.

Advanced Options

"skipLibCheck": boolean This bypasses checking your declaration files for following certain rules. You may want to do this to speed up compilation time. In reality if one type file depends on another it won't ensure the imports are of the specified type. Not skipping Lib check would also make you aware if you are doubly importing somewhere.

"forceConsistentCasingInFileNames": boolean If you're reading this, I'm sure you have bounced between languages and frameworks and possibly OSs'. They all have unique naming schemes, snake case, camel case, pascal case. If this is set to false you can find a file ./thisone.ts to be the equivalent to ./ThisOne.ts. Some areas of work are more sensitive than others so turn this off with caution.

Oh my that was a lot. Typescript has a lot of variables to make your life easier or more difficult. In the end it's your friend. As browsers across devices change, TS allows you to write in one standard and export it to different generations that may be friendlier to browsers you never really use.. Not looking at you Internet Explorer... Anyway, it is a challenge sometimes but TS seems like it is here to stay and is also here to help.

Google recommendations changing... for a better User Experience? Web.dev to the rescue.

Adam Smolenski — Fri, 05 Feb 2021 19:00:59 +0000

So recently I had an interview with a company that is hiring a bunch of new developers to tackle a problem that's coming up in what is estimated to be a change in April. Google is shifting it's recommendation system based on a user's interaction with a website.... wha?!?!?!?! They have our data now they want us to be content? Personally I'm amused by the google cards on my android phone, so I won't go into all of that.

As someone who cooks and constantly uses their phone for recipes, I love some of their metrics. Layout shift being a huge one to tackle. Constantly I'm hovering over ingredients and then a new ad loads... Wait, how many cups of flour!??!?!! How dare you load something that allows you to pay for this website!! Anyway long story short, I went on a hunt to find out where you can get these metrics and then get some advice on how to fix it. Sadly, I don't believe I got the position so I won't mention any names of companies but I will be using their site response as a diagram of what changes could be implemented based on the metrics provided by Web Dev, A website now I will be using rather frequently through out my projects. Lighthouse is a plugin that also has some nifty tools to measure all of this. Web Dev seems more critical of things, Lighthouse will give you the specifics for that page though. So in conjunction these two tools will probably give you an idea of what to improve and how.

They break down the measurements into 4 sections; Performance, Accessibility, Best Practices, and SEO. Some of these are minor fixes, some would involve a major overhaul. We will only go over a few but ones that come up frequently.

Many of the sites that bulk load bootstrap or jquery. It's hard to pick and choose from libraries that have become so essential for quick develop of apps. As frameworks take away some of this library load it becomes easier to move away from that. The quick fix for this would be to load essential styles inline and defer loading to later in the application. Basically a triage of rendering. And this effects the original content paint of your site.

Properly sizing images. Now this here is a tricky one. Next.js and Gatsby are essentially making this a thing of the past. They have plugins to make images responsive, saving on size and load time. Some CDN's can also meet this problem. This is serving up an appropriately rendered image where you don't have a 4000X8000px image rendered to 40X80. SVGs can also help because they require minimal resources in their resizing.

Unused Javascript is also another big one. React already throws errors if you are declaring unused variables or components. How are you tackling the rest of your app? I feel like this metric will drive people further and further into TypeScript. TypeScript is something I currently in the midst of learning and see a lot of benefits to compiling the code and figuring out what is essential and where you will have an error in production. There's a bit extra setup but the amount of headscratching caused by the Javascript attitude of inferring what you mean when you add a string and an integer. Setting types will limit the extraneous javascript you have and insure it's minimal.

Along these lines minification is also a benefit. I had a whole blog explaining its history which was fun. But there are certain frameworks where you just need to throw in a config setting and on build it will minify, as well as when using outside libraries they sometimes have a minified library to add if you are not reading through it. Another javascript issue is importing the same library several times. This is a common occurrence when you have several devs on a project. I've had TypeScript yell at me about this before, so that's a possible solution.

Avoid multiple page redirects. This is essentially when you pull a resource from a different location than what is being rendered. Everytime you hit a redirect to render you are adding time to slow down your original view.

There are even easy changes to up your score for the new metrics. Making sure you have Alt tags for images (accessibility and SEO optimization), accessible names for buttons.

Being color blind one of the accessibility measurements is foreground and background contrast. This is a huge one for me, as someone who used to work with Yamaha Audio equipment, blue text on a purple background is not good!!! Why would you even do that!??!! One way as someone who has no idea about color can go about checking this is this lovely tool. You can put in the hex codes of the colors you are using and it will generate an assessment.

Again these are just a few. As the metrics for google rankings change to make sure the user lands on a website they enjoy, developers should be checking their work against these tools. There are plenty more docs on web.dev, and many other websites that will measure your work. In case you were wondering though. Dev.to has some of the best scores I've seen while Medium's performance is 20/100 :)

Time to time

Adam Smolenski — Fri, 29 Jan 2021 23:07:24 +0000

So last time I was returning socket information through a custom hook... Not even telling you what a custom hook was or why I was using it... silly me. So here we will cover that.
So why a hook? Well These are functions that I was going to need across components that do entirely different things. As mentioned there were different levels of Time Control, but they all needed to be monitored from different components. By creating a custom hook I can have those functions available to me in all sorts of places. Think of it as a reverse Higher Order Component. I'm not imprinting a component on it, but taking a function from below.

Warning.. same rules apply to regular hooks, you need to be using them in functional component, they can be part of any conditional logic and they have to start with "use". Useful rules aren't they?

Everyone needed a baselevel connection but needed different functionality from this component as well. Stage Managers, assistants, audience members as well as the production team all needed to be able to view the time but only certain people can manipulate time, whether or not for production or test. So the whole thing looked like:

import { useEffect, useRef, useState } from "react";
import socketIOClient from "socket.io-client";

const START_TIMER = "startTimer"
const PAUSE_TIMER = "pauseTimer"
const SET_TIMER = "setTimer"
const RESET_TIMER = "resetTimer"
const GET_TIMER = "getTimer"
const RESET_STORAGE = "resetStorage"
const RESET_TRACK = "resetTrack"
const SOCKET_SERVER_URL = `/`;

const useTimer = () => {
    let [browserTimer, setBrowserTimer] = useState({})
    const socketRef = useRef();

    useEffect(() => {
        socketRef.current = socketIOClient(SOCKET_SERVER_URL, {
            query: {roomId:"Info"}
        });

        socketRef.current.on("startBrowserTimer", (data) => {
            setBrowserTimer(data)
        });
        socketRef.current.on("resetBrowserTimer", (data) => {
            setBrowserTimer(data)
        });
        socketRef.current.on("pauseBrowserTimer", (data) => {
            setBrowserTimer(data)
        });
        socketRef.current.on("setBrowserTimer", (data) => {
            setBrowserTimer(data)
        });

        socketRef.current.on("getBrowserTimer", (data) => {
            setBrowserTimer(data)
        });

        return () => {
            setBrowserTimer({ })
            socketRef.current.disconnect();

        };
    }, []);

    const startTimer = () => {
        socketRef.current.emit(START_TIMER)
    }

    const setTimer = (minutes, seconds) => {
        let intoSeconds = (parseInt(minutes)  * 60) + parseInt(seconds)
        socketRef.current.emit(SET_TIMER, {body:{newTimer: intoSeconds }})
    }

    const getTimer = () =>{
        socketRef.current.emit(GET_TIMER)
    }
    const pauseTimer = () => {
        socketRef.current.emit(PAUSE_TIMER)
    }

    const resetTimer = () => {
        socketRef.current.emit(RESET_TIMER)
    }



    return ({ startTimer, setTimer, resetTimer, pauseTimer, browserTimer, getTimer });
};


export { useTimer };

Boy that's a lot of info. Let's start from the top... you are probably wondering why I'm in a room called info... Well I wanted to know who was connected to the timer, so that is a different component that gets the userlist to make sure our audience is in sync. Also why am I adding the accuracy check? Due to not re-rendering the hook unless new information is set, in the React component I set it to false after the Timer is read and set. That way, if the component re-renders it doesn't reset to false info.

All the socket.current.on are on the incoming messages, so this is all information generated from the backend which we will get to momentarily. The browser timer information is what we will be processing. It's based on the timer on the server with some extra information.

So let's look at the returns now since those house most of our functions. Everyone will have access to browserTimer and getTimer, that's we return these as a hash so we can destructure in react.

On the backend we add on from last time.

const startTimer = () => {
            clearInterval(timerInterval)
            delete (timerInterval)
            timerInterval = setInterval(() => {
                timer = timer + 1
            }, 1000)
            io.sockets.emit("startBrowserTimer", { timer, rolling: true, accurate: true })
        }
        const getTimer = () => {
            let rolling
            if (timerInterval && timerInterval._destroyed){
                rolling = false
            }else if(!timerInterval){
                rolling = false
            }else{
                rolling = true
            }
            io.sockets.emit("getBrowserTimer", { timer, rolling, accurate: true })
        }

        const resetTimer = () => {
            clearInterval(timerInterval)
            delete (timerInterval)
            timer = -1
            io.sockets.emit("resetBrowserTimer", { timer, rolling: false, accurate: true  })
        }

        const pauseTimer = () => {
            clearInterval(timerInterval)
            delete(timerInterval)
            io.sockets.emit("pauseBrowserTimer", { timer, rolling: false, accurate: true })
        }

        const setTimer = (newTime) => {
            timer = newTime
            if (timerInterval && timerInterval._destroyed) {
                rolling = false
            } else if (!timerInterval) {
                rolling = false
            } else {
                rolling = true
            }
            io.sockets.emit("setBrowserTimer", { timer, rolling, accurate: true })
        }

        socket.on("getTimer", (data)=>{

            getTimer()
        })

        socket.on("startTimer", (data) => {
            startTimer()
        })
        socket.on("pauseTimer", (data) => {
            pauseTimer()

        })

        socket.on("setTimer", (data) => {
            setTimer(data.body.newTimer)

        })

        if (timer > 7800) {
            resetTimer()
        }

        socket.on("resetTimer", data => {
           resetTimer()
        })

So here we have a bunch more info to go through, startTimer is the best place to.... start. We are clearing on the beginning to ensure there is not a double Go. Otherwise it is setting our server timer and sending that information back through sockets for our users to then process further in React once it is passed back from the hook. But you can now see that the information sent back mainly consists or telling us if the clock is rolling where we are at, and that this information is up to date (accurate). Get timer just receives the data, reset sets the timer to -1 (this was done because that is outside of the cuing which goes up to 2 hours and 10 minutes, or 7800 seconds), you can also see that is called if the time is over that 7800 second mark, that way our server isn't randomly counting once the show is over. Set timer on the frontend (the hook) you can see is converted to seconds, SMs are too busy to think in seconds while processing show info. However, our server handles seconds best so we make that conversion in the Frontend and just change the timer in the backend.

So these are all the basic commands that I used to control time through sockets in order to sync up the audience. We will continue putting it all together next time.

Socket to Me

Adam Smolenski — Sat, 23 Jan 2021 14:55:27 +0000

So last time we talked about a simple timer with the use of setInterval. Great... so we have the stopwatch for the show. But how is that going to travel to our audience? The solution is sockets. My Express backend is integrating a socket server on the same port as the app so everything can co-exist happily. So basically everything is wrapped up nicely in emit events. We will go over the chat functionalities in this blog and how I created the timer scenario next time.

The project called for multiple chatrooms and private rooms (however these private rooms became multi-purpose as actors swapped in at different times from different computers). The basic set up in the backend is very reminiscent of React hooks. This gave me a warm fuzzy feeling if I can be completely honest, since this was a new technology for me. I will not go through in depth on how to make sure the server talking to the app in Node, this is more of a review of the interior for this use case. Feel free to reach out for other information

So the first thing you need to do is make sure there's a connection... makes sense... the last thing you need to do is make sure there's a disconnect... ooo basically useEffect with a return... and funny enough these will be mimicked like this in the front end.

So backend in it's simplest use.


module.exports = (function (app, port) {
    const server = require('http').createServer(app);
    const options = {
        cors: {
            origin: '*',
        }
    };

    const io = require('socket.io')(server, options);
    server.listen(port);

    io.on("connection", (socket) => {

        const { roomId, username } = socket.handshake.query;

        socket.join(roomId);

socket.on("disconnect", () => {
            socket.leave(roomId);
        });
    })

}
)

Some quick questions that may pop up... what is app, and port... Those will be passed in from your main app.js (I chose to keep sockets in a separate file thinking it may get a little messy), app is just your express call and the port will vary, I set mine to default at 5000 but in deployment on heroku it changes with the deployment. Cors for sanity sake is set to * so it can come wherever in your development environment in production you will set this to where you are being hosted.

Next questions, where the heck are roomId and username coming from? Well that's a more complicated story for the rest of the app that we won't dive too much into here. Username comes from their signup and travels through redux, and roomId is actually their location in our little play but you can repurpose those for right now. The handshake.query is the important part. The handshake is initiated on the React side and the query is where we are throwing our information.

For our frontend... I hilariously built my own hooks, but there are many standardized libraries out there use-socket and use-immer. But the begginning of our hook will look like this:

import { useEffect, useRef, useState} from "react";
import socketIOClient from "socket.io-client";



const SOCKET_SERVER_URL = `/`;

const useChat = (roomId, username) => {
    const socketRef = useRef();

    useEffect(() => {
        socketRef.current = socketIOClient(SOCKET_SERVER_URL, {
            query: { roomId, username }
        });
 return () => {
            socketRef.current.disconnect();
        };
    }, [roomId]);
}
export {useChat}

Here we are using the React library of socketIOClient. It does much of the work for us.
The socket server url is set to "/" since it will be based off our server (works for localhost and deployed versions) but here is the handshake we were talking about. In that socketIOClient call, we are querying with our roomId and username, this happens on connection. Also you may be asking why socketRef is part of useRef(), well useRef() does not force a re-render, which could send us into a nasty little spiral if one of the socket calls emits something in particular. And mentioned earlier the unmount (really why don't they call it dismount?!?!) has the disconnect which closes us out just in case. You may ask why I have roomId in there as a dependency. The fact is we are having multiple rooms because there are several acts, so we don't want someone in Act 3 talking to Act 2 people, spoilers!

Due to this being a hook, this is called in a React component which is really what has my chat room set up. So that means we need to return some information for it to be rendered in it's host component. And we also need there to be some sort of functionality in the backend. To get the chat up and running we need a send and receive on both ends... and then the socket functions in react need to return that to the component.

So in the React side, lets get messages and add a send message function. The entire file would look something like this:

import { useEffect, useRef, useState } from "react";
import socketIOClient from "socket.io-client";

const NEW_CHAT_MESSAGE_EVENT = "newChatMessage"; 
const SOCKET_SERVER_URL = `/`;



const useChat = (roomId, username) => {
    const [messages, setMessages] = useState([]); 
    const socketRef = useRef();

    useEffect(() => {
        socketRef.current = socketIOClient(SOCKET_SERVER_URL, {
            query: { roomId, username }
        });

        socketRef.current.on(NEW_CHAT_MESSAGE_EVENT, (message) => {

            const incomingMessage = {
                ...message,
                ownedByCurrentUser: message.senderId === socketRef.current.id,
            };

            setMessages((messages) => [...messages, incomingMessage]);
        });

        return () => {

            socketRef.current.disconnect();
        };
    }, [roomId]);

    const sendMessage = (messageBody) => {
        socketRef.current.emit(NEW_CHAT_MESSAGE_EVENT, {
            body: messageBody,
            senderId: socketRef.current.id,
        });
        return {
            body: messageBody,
            senderId: socketRef.current.id,
        }

    };

    return { messages, sendMessage};
};


export {useChat};

We return all the messages as they get added and have the ability to send a message as the message body. The senderId is generated by sockets, which I had some issues with later on with reconnection and how I was rendering... so that's where the username came in but we will get to that another time.

So taking a look we are both on socketRef.current (this is the channel) but we have two functions following that, .on and .emit. ".on" means when the current used hears that socket call and .emit is sending it. Both of these are encapsulated in our room since we have joined it in our socket query.

Now let's look at how the backend is handling this.

const NEW_CHAT_MESSAGE_EVENT = "newChatMessage";

socket.on(NEW_CHAT_MESSAGE_EVENT, (data) => {

            io.in(roomId).emit(NEW_CHAT_MESSAGE_EVENT, data);

        });

Wait that's only one function... Exactly. We are not optimistically rendering the chat item and we are emitting in the channel. So every time the backend receives a message it sends it out. There are other socket functions that send to all but the sender but I opted against that since I was testing it on my home network and thought that would give too many false positives. So everytime this gets a message it sends it out to all sockets in that current room that we have joined. Since the room names are specific we can be sure they are going to the right places. This gets updated into the messages array which is returned by our custom hook, and since we had a useRef, it is keeping everything happy and no re-rendering.

To quickly gloss over the chat component, as long as you have a submit or click handler receiving the sendMessage function and give it the body of the message you are set, in mine I added the username to the beginning instead of the id which is basically a hash. Then rendered that information. Use cases may vary. Next time we will get into the silliness of sending time this way.

Set Interval

Adam Smolenski — Thu, 14 Jan 2021 17:59:14 +0000

So the last post was establishing that... I was creating a real time theatrical experience. We will start simple... creating a simple timer, as I mentioned the most pivotal part of keeping a show running is the SM's control of timing. So starting with a shared clock is important, actors will know where they are, cues will be on a standby and hopefully everything flows together.

After we go through the process of establishing how to set the timer, I will discuss how that syncs with everyone but will get into that code another time.

So setInterval is an easy function with a callback and then a delay in milliseconds. Say you want to say hi every second (I have young nieces and nephews so I have experienced such a thing in real life).
setInterval(()=>{console.log("Hi")},1000)
So there is an anonymous function at the start and it triggers every 1000 milliseconds. Great easy enough. Not so fast... well one second to be exact. This will keep happening and can cause a memory leak due to the fact that function may continuously run in the background.

To fix that up you can assign the interval to a variable name.
let myInterval = setInterval(()=>{console.log("Hi")},1000)
Setting it to a variable will still start the interval, to stop it all you have to do is clearInterval(myInterval) and it will stop.

Fun thing to note if you console.log(myInterval) it is a number kept as a reference to enable cleanup. You may have many timers going on a page, so it is important to have them accessible.

Alright now that the basic rules have been established let's talk about the timer. Easy transition,

let time = 0 
let countUp = setInterval(()=>{timer +=1}, 1000)

This will go up every second, if you clearInterval(countUp) the time will remain the same but you can then create another countUp just by running the line countUp.

React adds a whole different layer of complexity to something like this. Due to re-renders you could accidentally double up on a timer. That's not good when you're trying to keep consistency among remote browsers.

So to do this you add some logic to mounting and unmounting (really why don't they call this dismount? always has bothered me). State travels along with re-renders, so you can add a value of clockRunning, and set it to true or false based upon what is happening. We will do this is a functional component for now.

import react, {useEffect, useState} from 'react'

function Counter(props) {
    let [time, setTime] = useState(0)
    let [clockRunning, setClockRunning]= useState(false)
    let myInterval
    clearInterval(myInterval)

    useEffect(()=>{
        if (clockRunning){
            myInterval = (setInterval(() => { setTime(time += 1) }, 1000))
        }


        return ()=> clearInterval(myInterval)},[clockRunning]
    )
    return (
        <>

            <button onClick={()=>setClockRunning(true)}>
               Count up
            </button>
            <div>
               {time}
            </div>
            <button onClick={()=>setClockRunning(false)}>
                Stop
            </button>
        </>
    )
}

export default Counter

So here the we clean up the interval on render just in case. It doesn't cost us anything but is a nice safeguard to have. We are defaulting the clock to not run on first render but our buttons can change that. In our useEffect, it runs every time counting changes. The return on the bottom is the clearing of the interval on a rerender, however since we are starting a new interval on render if clockRunning is true, we don't lose anything.

This isn't fancy by any means but this is the basis of a lot of running a show. This information and more will travel over Websockets so everyone has the same experience. The timer, however, is kept on the server. That is a huge part of this trick. We were worried about the stage managers computer crashing or they lost internet connection so we needed to figure out a way to communicate all this information. By keeping the timer on the server and communicating through websockets, if you are logged in to the site, that means you have access to the timer. More on that another time though. We are beginning to build our show control though!