Forem: Ezell Frazier

How to Upload Files in 2022?

Ezell Frazier — Fri, 03 Jun 2022 18:34:28 +0000

Can we finally do away with the Input Element and FileReader API?

Disclaimer: This post involves the context of handling and reading files within a JavaScript-based web application. There's nothing wrong with using an input element for file uploads for other purposes. However, it's wonderful to have an alternative approach.

The Old Way of Uploading Files with JavaScript

So, I'm writing an application and I want to allow for users to save and load their configurations. JSON is likely the simplest approach here. Or, I'd think.

<input type="file" accept=".json" id="upload"/>

const uploadElement = document.getElementById('upload')

const reader = new FileReader();

// Two event handlers to for uploading and reading files
reader.onload = () => {
  const json = reader.result
  const data = JSON.parse(json)
  console.log(data)
}

uploadElement.onchange = (e) => {
  const [file] = e.target.files
  reader.readAsText(file)
}

The old approach involves declaring two input handlers for two asynchronous operations. The reader object can read uploaded files, however reader.result is not available in a traditional sequence, as seen below:

const uploadElement = document.getElementById('upload')

const reader = new FileReader();

uploadElement.onchange = (e) => {
  const [file] = e.target.files
  reader.readAsText(file)
  console.log(reader.result) // why is this null?
}

reader.result is null because it hasn't finished reading the file. So, a workaround involves using the reader's readAsText method in tandem with a Promise constructor.

const uploadElement = document.getElementById("upload");

const reader = new FileReader();

// Poll for changes to the filereader's state about every 25ms
const readTextAsync = (filereader, fileBlob) =>
  new Promise((resolve) => {
    let interval;
    filereader.readAsText(file);

    interval = setInterval(() => {
      if (filereader.readyState === FileReader.DONE) {
        clearInterval(interval);
        const result = filereader.result;
        resolve(result);
      }
    }, 25);

  });

uploadElement.onchange = async (e) => {
  const [file] = e.target.files;
  const json = await readTextAsync(reader, file)
  console.log(json) // We have our json string
};

There's no longer two event handlers, but there's more code.

Converting callback-based APIs into something more modern may be more tedious to write, harder to read, and possibly introduce more opportunities for bugs. Thankfully, we can use the recently introduced File System Access API to tackle this problem.

Uploading files with the File System Access API

<button id="upload">Select a File</button>

const uploadBtn = document.getElementById("upload");

// I can clearly see and understand what's happening here
uploadBtn.onclick = async () => {
  const options = {
    types: [
      {
        description: "JSON",
        accept: {
          "application/json": [".json"],
        },
      },
    ],
  };
  const [fileHandle] = await window.showOpenFilePicker(options);
  const file = await fileHandle.getFile();
  const json = await file.text();
  console.log(json);
};

There's many improvements to the developer experience here. window.showOpenFilePicker allows us to place the following all in one callback function:

File reading
File parsing
File Picker Options

However, the biggest benefit is not having tightly related implementation details within multiple places across multiple files, across multiple steps.

Lastly, the input element may introduce a design which clashes with the overall theme of the UI. It's not uncommon to see implementations of a button element for file uploading, while hiding the actual input element responsible for the file upload.

None of that is required here.

Caveats

The File System Access API is fully supported within Chrome and Edge browsers as of this post. However, Polyfills are available
The FileSystem API only works in secure, https:// environments, with the exception of localhost
The FileSystem API also won't work within iframes or other framed environments like CodePen / CodeSandbox, etc.

Learn more about the File System Access API on MDN

When is onChange not the same as onChange?

Ezell Frazier — Thu, 10 Mar 2022 17:38:07 +0000

A colleague raised a fair question, why doesn’t an input element's onchange event type behave the same as React’s onChange?

Wait, what do you mean?, was my initial thought not realizing the inherent difference between the two.

Digging deeper into the question uncovered what could be a jarring experience for a developer.

What we’d expect?🤔

The native web API `onchange` attribute

<input type=“text” onchange=“console.log(‘changed’)” />

When do we expect the string changed to appear in the console?

After a user presses a key?
After the user changes focus from the input element? ✅
After the last key is pressed?

React's `onChange` prop

<input type=“text” onChange={() => console.log(‘changed’) />} />

I think we know what happens here.

The string appears in the console each time the user inputs a new value.

The two event types behave differently by design.

The React team believes this is how the native onchange should behave.

Whenever the element's value has changed, the corresponding event should fire.

But wait, don't we already have an event type for that?

The input event

The native web API `oninput` attribute

<input type=“text” oninput=“console.log(‘changed’)” />

React's `onInput` prop

<input type=“text” onInput={() => console.log(‘changed’) />} />

Here, both React and the web API behave the same, or as we'd expect. The string appears in the console when the user changes the element's value.

So, shouldn't we leverage onInput instead of onChange? Well, that's likely the way to go if one's working with other JSX-based frameworks.

When `onChange` isn't `onChange`?

Stencil.js is a neat framework for building web components. Like React, Stencil uses JSX for markup. And if we wanted to use React's onChange behavior, we'd instead need to use onInput.

Solid.js, a newer web framework which draws inspiration from React, can also use JSX for markup. And like Stencil.js, onChange behaves like the native web implementation.

So, if one were to migrate some JSX from one framework to another, note that React's subtle opinion may not carry over.

oninput may also be a good choice if one wants to avoid the onchange trap altogether. 👀

Why Doesn't React's useState Hook Merge Objects?

Ezell Frazier — Wed, 09 Mar 2022 15:18:00 +0000

I saw a question today about React's useState hook, as there is unexpected behavior compared to this.setState in class components.

Expected Behavior

A user inputs a value and this.setState merges both initial state and the dispatched object from the event handler.

So, if a user types the letter a, state is represented as the merger of,

{ name: 'a' } and { name: '', email: '', phone: '' },

as { name: 'a', email: '', phone: '' }.

export default class ControlledForm extends Component {
  constructor(props) {
    super(props);
    this.state = {
      name: '',
      email: '',
      phone: ''
    }
  }
  render() {
    return (
      <form onSubmit={e => e.preventDefault()}>
        <fieldset>
          <label htmlFor="name">Name</label>
          <input
            type="text"
            id="name"
            value={this.state.name}
            onInput={event => this.setState({ name: event.target.value })} 
            // { name: 'a', email: '', phone: '' }
          />
        </fieldset>
      </form>
    )
  }
}

Unexpected Behavior?

A user inputs a value as before. However, setFormValues dispatches an object,

{ name: 'a' }, replacing the initial state object.

function ControlledForm() {
  const [formValues, setFormValues] = useState({
    name: '',
    email: '',
    phone: ''
  })

  return (
    <form onSubmit={e => e.preventDefault()}>
      <fieldset>
        <label htmlFor="name">Name</label>
        <input
          type="text"
          id="name"
          value={formValues.name}
          // { name: 'a' }
          onInput={event => setFormValues({ name: event.target.value })}
        />
      </fieldset>
  )
}

Manually Merging Objects

setState or setFormValues in this context, is a function with a parameter that can be a plain value, an object, or a function with a parameter containing its current state.

We can leverage the function parameter to merge our objects (or arrays).

<input
  type="text"
  id="name"
  value={formValues.name}
  // { name: 'a', email: '', phone: '' }
  onInput={event => setFormValues(values => ({ ...values, name: event.target.value }))}
 />

Why though?

This may feel like a jarring developer experience for those migrating from legacy React code but, this is by design.

If you miss automatic merging, you could write a custom useLegacyState Hook that merges object state updates. However, we recommend to split state into multiple state variables based on which values tend to change together

In other words, it may be more convenient to avoid merging objects altogether. Would one need to merge objects if replacing the previous object achieved the same result?

So, if one has to merge state objects, they have a few options at their disposal.

Manual merging of objects within state
Individual useState hooks for each object property
A reducer (which may be a tad too much for this example)

When working with state, I tend to ask myself, do these variables change together? If yes, I'll go with an object, and know I'll be fine.

Low Cost Value-Adds for Any React Project

Ezell Frazier — Mon, 07 Feb 2022 15:03:56 +0000

Landed a new role? New to a React project? Just want to see if there's anything new here?

Here are a few ways to hit the ground running with minimal cost to existing codebases. Free of any package installations.

Default Props

It is not uncommon to discover legacy or current React codebases with components containing no default values for the props it consumes. Which implies the value undefined is part of expected behavior, which is risky business.

// What should we see if the message prop isn't provided?
const Greeting = (props) => <h1>{props.message}</h1>;

Leveraging React's defaultProps component property

const Greeting = (props) => <h1>{props.message}</h1>;

Greeting.defaultProps = {
  message: 'No message prop provided!'
}

Using Object Destructuring Assignment

const Greeting = ({ message = 'No message prop provided!' }) => 
  <h1>{message}</h1>;

Adding TypeScript Types via JSDoc

It's safe to assume numerous React developers are using Visual Studio Code as their text editor. Why not enhance the development experience by leveraging VSCode's Intellisense?

Adding types via React Prop Types or TypeScript may face some resistance, but it doesn't mean we can't use types with comments.

/**
 * @description defaults to "No message prop provided!"
 * @param {{ message: string }} { message }
 * @returns {JSX.Element} Greeting component
 */
const Greeting = ({ message = 'No message prop provided!' }) => (
  <h1>{message}</h1>
)

Learn more Here

Explanatory Comments

I admit, this is a piece of advice for myself as much as it is for anyone else. Also, this is a general good habit for any project.

Ideally, we want to write comments explaining why we're adding a component or a highly re-used module.

If we can't explain it in a line, try to include a reference to the ticket.

Received a hard-to-understand piece of code from the internet? Include a link to where it was found.

Your teammates and future-self will greatly appreciate this.

// Wanted a concise way to compose the props for a hairy view
// See ticket #4207 for details
export const pipe = (input, ...fns) =>
  fns.reduce((output, fn) => fn(output), input);

Have any more tips? I'd love to know more!

How to Make Any Method Chainable in JavaScript

Ezell Frazier — Mon, 20 Dec 2021 16:40:37 +0000

TLDR;

jQuery pushed the web and JavaScript forward, but its method chaining is greatly missed
What if I told you ther is a way to bring this back?
This may be a representation of something that I'm not here to talk about 👀

Why Should Anyone Care About This?

Regardless of one's experience with JavaScript, they may have heard of jQuery. During the early-to-mid 2000's, the web had reached a level of maturity allowing developers to create fluid user experiences compared to a collection of web pages.

But, this was a tedious task given how bare bones JavaScript and web browser APIs were compared to other programming languages. Imagine not having fetch or document.querySelector. That's pretty rough right? Well, jQuery filled in all the gaps, and then some. For some, jQuery was the standard library of client-side web development. But, that was then; JavaScript and the web has evolved.

However, with all the significant improvements enhancing JavaScript and web APIs, jQuery's method chaining was largely left behind. And because of this, jQuery isn't leaving the tool-belt of some developers. Can one blame them for that? jQuery provided a clean developer experience, while providing tools for building similarly clean user experiences. What's a relatively quick and painless way to bring this back?

What's Method Chaining?

$("#p1").css("color", "red").slideUp(2000).slideDown(2000);

Chaining methods like .css, .slideUp, and slideDown is highly expressive and concise. jQuery's implementation represents a Fluent Interface, providing a level of expressiveness where code almost reads like plain English.

Wouldn't Native Method Chaining be Neat?

document.querySelector("#p1")
  .setCss({ transition: 'height 2s', height: '0px' })
  .setCss({ height: '100px' });

This could be achieved, but one would need to know and care about implementation details between the DOM and one's app, which may introduce far more complexity than is required for most use cases.

Introducing Generic Method Chaining with The Box

Box(document.getElementById('p1'))
    .modifyContents(slideUp(2000))
    .modifyContents(slideDown(2000, '100px'));

The objective is to place whatever one wants inside of a Box. Its two methods replaceContents and modifyContents allows one to temporarily take an item outside of the Box, perform an action, and place it into another Box.

This approach allows one to have a clear separation between what's desired (method chaining) and what one's already writing (DOM manipulation). Additionally, highly modular, and independent code is easier to compose and test.

import { Box } from './box' // highly modular
import { slideUp, slideDown } from './dom' // bring your own implementation details

Is this Form of Method Chaining Really Generic?

Numbers

const four = Box(4);
const eight = four
  .replaceContents((num) => num * 2)
  .modifyContents(console.log); // 8

const ten = eight
  .replaceContents((num) => num + 2)
  .modifyContents(console.log); // 10

Arrays

const nums = Box([1, 2, 3, 4, 5]);
const evens = nums
  .replaceContents((numArr) => numArr.map((x) => x + 2))
  .modifyContents(console.log) // [3, 4, 5, 6, 7]
  .replaceContents((sums) => sums.filter((x) => x % 2 === 0))
  .modifyContents(console.log); // [4, 6]

Mixed Types (Map, Array)

const gteTo2 = Box(new Map([["a", 1], ["b", 2], ["c", 3]]))
  .replaceContents((table) => [...table.entries()])
  .replaceContents((arr) => arr.filter(([, value]) => value >= 2))
  .replaceContents((arr) => new Map(arr))
  .modifyContents(console.log); // Map { 'b' => 2, 'c' => 3 }

Yes!

The Box works with any type. Its two methods replaceContents and modifyContents have a single parameter, which is whatever item is inside of The Box.

The Box can contain a primitive or an object. The difference between its two methods is that replaceContents must return a value, and modifyContents does not. In other words, replaceContents is great for ensuring immutability.

Here's the interface for TypeScript or other languages.

interface IBox<T> {
  replaceContents: <V>(fn: (item: T) => V) => IBox<V>;
  modifyContents: (fn: (item: T) => void) => IBox<T>;
}

How Does The Box compare to Fluent Interfaces?

	The Box	Fluent Interfaces
Method Chaining	✅	✅
Highly Expressive	✅	✅
Supports immutability	✅	✅
Debugger-friendly	✅	❌
Logging-friendly	✅	❌
Works with any data type	✅	❌
Module-friendly	✅	❌

Sold? Here's What The Box Looks Like

function Box(item) {
    const replaceContents = (fn) => Box(fn(item));
    const modifyContents = (fn) => {
        fn(item);
        return Box(item);
    };
    return { replaceContents, modifyContents };
};

Wait a Minute, Is The Box a You-Know-What?

👀

Job Descriptions JavaScript Developers Should be Weary of in 2019

Ezell Frazier — Wed, 25 Sep 2019 00:17:49 +0000

Recently, a thread over at r/javascript has me a bit fired up.

JavaScript today is not JavaScript of 2006, 2004, or prior. I repeat.

Modern JavaScript is not "just" JavaScript

Recruiters, and HR, please take note.

Lead devs,

I understand this language may have burned you, chewed you up, and made your life utterly miserable a decade ago.

This is not an acceptable excuse for attempting to hire a developer and stagnating their career progression with your outdated tech stack.

If Internet Explorer 11 and below are a required target, you better prepare to offer higher compensation for outdated technology.

Junior devs to-be,

Please take in consideration of where you see yourself in the future. If you've been building applications with technologies such as Ember, React, Angular, and Vue, please be cautious of job listings containing jQuery or "JavaScript" with no context.

If you are working heavily with ES2015 syntax and front-end frameworks, you are no longer just a 'front-end web developer'. You are an application developer. Don't let anyone try to cut corners with job descriptions.

However, job descriptions are just the beginning. You need to press the topic during the interviewing process if you have any doubt.

Legacy code is real, and you need to ask if you'll be spending 90% of your time in jQuery-land or what you thought you signed up for instead.

"I saw jQuery and React on the job posting, are you transitioning to React"?

"The interview question/tests are using some older syntax, is this indicative of your current codebase"?

Anyways, I scoured a job board to find a list of good and questionable job descriptions. Notice a common key-word in each of the good descriptions. If there is no mention of ES2015 (ES6) or higher, then you need to go on the offensive during the interviewing process.

Good Job Descriptions

Senior Level

Expert level programming knowledge in Javascript (ES6), including writing cross-browser code, writing testable code.

Knowledge of best practices & patterns for large scale applications in javascript .

Efficient DOM manipulation.

Component architecture using AngularJS or ReactJS/Redux.

Less dependent on third party ibraries.

Web: HTML(5), CSS(3), BootStrap/Foundation,

Intermediate Level

2+ years of professional JavaScript experience, including concepts like asynchronous programming, closures, types, and ES6

2+ years of professional HTML/CSS experience, including concepts like layout, specificity, cross browser compatibility, and accessibility

Broad understanding of the JavaScript ecosystem Experience with React, Angular, Vue.js, or other modern frontend frameworks

Direct experience with professional software development practices, including coding standards, source control (Git), code reviews, build processes, and testing

Junior Level

Passionate and fast learner

Knowledge and experience with one or more Javascript frameworks such as AngularJS or React

Experience and opinions about one or more of the animals in the JavaScript zoo: Webpack, ES6, TypeScript, ClojureScript, Grunt, Elm, Redux

Expert with HTML5, CSS and modern web design standards

Questionable Job Descriptions

Intermediate - Senior Level

Must have excellent background and understanding of HTML5, CSS3, SVG, ReactJS, Web Socket and Canvasas as well as Client-side Java Script.

Several client-side frameworks and build tools (ReactJS, jQuery, Less/Sass, Grunt/Gulp, etc).

Server-side development (JavaScript/Node.js, PHP, etc) and architecture (Apache/Nginx/etc.)

Database-driven web applications

REST APIs.

Git

Bash (linux or Mac)

Security best practices & familiarity with:

Relational Databases (SQL & PL/SQL)

Web Services

3rd Party APIs: Twitter,Facebook, Google Maps, etc

Knowledge of common content management systems iOS and/or Android native development experience a plus

Comfort with Agile and Waterfall development methodologies

Intermediate Level

Minimum of 3 years work experience as a web developer/programmer

Solid exposure to front-end technologies is required:

JavaScript-3+ years of experience

HTML-3+ years of experience

CSS-3+ years of experience

PHP-3+ years of experience

Netsuite SuiteCommerce Development Certification a plus

Junior-Intermediate Level

Proficient in HTML5, CSS3, JavaScript/jQuery. Comfortable writing native JavaScript from scratch.

Proficient in bootstrap and/or other responsive frameworks.

WordPress development (Installation, customization, and updating) a must-have.

Comfortable in Photoshop/Illustrator to slice and create images. 1 – 3 years of experience.

Bachelors degree in Computer Science or similar, preferred but not required.

How to Learn Fast

Ezell Frazier — Thu, 22 Aug 2019 11:30:23 +0000

TLDR;

Focus on what you need to know and filter out unrelated information

How to find out what you need to know? Test what you think you know.

Summarize everything you think you know about what you've read

If summarizing what you know is tough, focus on the where you're struggling and repeat the earlier steps.

Does reading a book from cover to cover qualify the book as being read?

Definitely so for fiction.

How about textbooks? News articles? Tutorials?

I've been doing it wrong for almost three decades.

I didn't catch on until my senior year in college. I graduated from a commuter school, or a school with no campus-life. My grades were slightly above average. Juggling heavy-work hours and being a full-time student was no easy feat.

In my senior year, I began to wonder, "how"? How are some students able to work 40 to 60-hour workweeks and still ace exams and projects? What's the science? The witchcraft? I wanted in.

I know some readers right now are probably saying, "oh they cheat, everyone cheats". Yeah, well, some might, but I'm always willing to give the benefit of a doubt. In my quest for answers, I've stumbled across many books, how-to's, and personalities with fancy cars and book collections.

One common message stood out:

'Get what I need to know and get out'.

I'm going to compare how I used to study and how I studied after learning this new technique.

I'm assuming most textbooks are structured in this fashion:

A chapter is ~35 pages
Takes about two hours to "read" one chapter (longer with note-taking)
Summary section at the end of the chapter (with review questions)

Old Me Studying a Textbook Chapter:

Attempt to read the entire chapter from start to finish
Take notes along the way
If I haven't burned out, try to answer the review questions
Return to class with little to no understanding of what I "studied"

New Me Studying a Textbook Chapter:

Jump straight to the end of the chapter
Test my existing knowledge based on review questions
Note the review questions I got incorrect
Jump to each section of the chapter related to my incorrect answers
Take notes on those sections
Return to the summary and look for any gaps in my understanding
Repeat the earlier steps if necessary
Return to class and start a conversation on the chapter to confirm my knowledge

I was able to shorten what used to take about two to five hours to roughly 40 minutes to an hour on average. I'm looking at a 90% reduction in time invested (at best) while increasing knowledge retention, and preventing burn-out. An all-around win-win.

So, these top students were able to study for multiple courses in the same amount of time I barely studied one.

Why did I take the chapter review before reading anything about the chapter?

I needed to know what I need to know. I am literally wasting time reading about something that I already understood.

So, if there is an assessment available, take it before diving in. I'm always surprised at what I may already know. Sometimes I get everything wrong. And that's perfectly fine. Now I know what I need to review. I never go in without a map of what I need to go.

Know What to Know

This is the key to fast learning. Who'll win a scavenger hunt first? The player with a map or the player without the map?

Unfortunately, every article, book, or piece of learning material is not structured like a college text-book. So, how would I be able to apply this same practice?

I learned of two basic writing principles which apply to just about every piece of non-fiction:

Thesis statements
Supporting information

The thesis statement is exactly what the author wants the reader to understand. Everything else is supporting information.

Sometimes a thesis statement is a sentence. Maybe a paragraph. If we're lucky, the author will explicitly start off with a summary of everything he or she will discuss.

My thesis statement for this article is one sentence. It's bold and in large text. It's hard to miss. If it makes sense to the reader, they can stop there and continue with their day.

Sometimes a book's title is the thesis statement. Maybe it's the title of the chapter. Sometimes the thesis statement tucked away midway through the opening paragraphs.

If any part of the thesis statement is vague or does not make sense, make note of it and parse out the chapter or book for related information. Sometimes another book or article explains it better. Don't limit the learning process to the current document or book.

The goal isn't to read the book for prestige or achievement, but to actually gain practical knowledge.

However, the learning process is the same.

Read the thesis and try to explain it in my own words
If I'm unable to, make note of what doesn't make sense
Scan the book/chapter/article for what I need and note it
Repeat if necessary

If there's anything I've missed or other techniques you've acquired which works for you, let me know!