DEV Community: Pushkar Anand

Building UI Components Correctly in the Age of AI

Pushkar Anand — Mon, 05 Jan 2026 07:34:04 +0000

Key Takeaways:
Let AI write the JSX, but you still need to understand the fundamentals: semantic HTML, defaults like type="submit", ARIA, and keyboard behavior if you want your components to be correct and reliable.

To make this concrete, I’ve also built a small learning project called no-frills-ui, and this post walks through the real problems it solves:

CSS-variable theming

promise-based confirm dialogs

centralized layer management

Today, a few lines of prompt are enough to generate a working React component, a form, or even an entire page. Tools can scaffold JSX, props, hooks, and even ARIA attributes faster than any human can type. That makes it very tempting to treat UI development as a copy–paste and glue exercise. Yet the basics still matter, because the hardest bugs are the ones where the code looks fine. Consider the humble <button>. In HTML, a <button> without an explicit type defaults to type="submit" when it’s inside a form. Click it, and the browser will happily submit the form, even if your intent was "just close the dialog", "open a drawer", or "go to the next step." This isn’t a React quirk or a library bug; it’s the platform’s default behavior.

AI tool can spit out:

<button onClick={handleClick}>Next</button>

It works in isolation. Months later, someone wraps that area in a <form> for validation, and "Next" suddenly starts submitting the form. Without knowing the default behavior of <button>, debugging this turns into superstition rather than understanding.

In this post, I want to go through a few of those fundamentals, the things AI can help you type, but not truly reason about for you. Creating a component seems simple: render some JSX, add some CSS, ship it. But in practice, even a "simple" button or input carries surprising complexity.

Let's take an example

Consider a seemingly trivial task: "Add delete functionality for list items that are rendered in a drawer". For this, the most basic component would be a button. This button needs to:

Be reusable: the same button component must work in different contexts: a table, a card, a modal, a sidebar.
Render correctly: visually consistent, right size, proper color.
Behave correctly: trigger a confirmation dialog when clicked.
Stack properly: the confirmation dialog must appear on top of the drawer, with correct z-index handling.
Work with forms: the button should behave correctly inside a form, respecting form submission.
Support theming: colors should change when the app switches to dark mode.
Support SSR: if you render your app on the server, the button must hydrate correctly on the client.
Forward refs and props: consumers might need imperative access or want to pass custom ARIA attributes.
Handle accessibility: keyboard users should be able to use it, screen reader users should understand what it does.
Support internationalization: text should adapt to different languages without modifying the component.

A single component touches concerns across styling, state management, SEO, accessibility, infrastructure, and composability. This post walks through those considerations using concrete examples: a button, an input, and a dropdown.

The examples use React, but the principles are universal and apply to component libraries built in Vue, Svelte, Angular, or any other framework. The fundamentals of semantic HTML, keyboard navigation, accessibility, and thoughtful API design transcend whatever happens to generate your JSX.

Why these details matter

When building components, you are not just building visual elements. You are building the foundation that other developers will depend on. A component that works perfectly in isolation might break in unexpected ways when combined with others, when rendered on the server, or when used by keyboard-only users.

Semantic HTML gives you a lot for free:

Keyboard navigation (Tab, Enter, Space) for buttons, inputs, links.
Screen reader semantics (a <button> is announced as a button, a <select> as a combo box).
Native form integration (labels, required fields, validation, and submit behavior).
Predictable behavior across browsers and SSR.

When you throw that away and replace everything with <div> plus onClick, you are re-implementing the browser. That means more code, more bugs, and more edge cases. Exactly the kind of work that AI is bad at validating for you.

Button – small component, big consequences

A button should:

Respond to Enter and Space keys.
Be announced as a "button" to screen readers.
Show clear focus styles.
Respect disabled state both visually and semantically.

Implementation:

interface ButtonProps extends React.ButtonHTMLAttributes<HTMLButtonElement> {
  variant?: 'primary' | 'secondary' | 'danger';
}

const Button = React.forwardRef<HTMLButtonElement, ButtonProps>(
  ({ className, variant = 'primary', type = 'button', ...props }, ref) => (
    <button
      className={`btn btn-${variant} ${className || ''}`}
      type={type}
      ref={ref}
      {...props}
    />
  )
);

Button.displayName = 'Button';
export default Button;

Key decisions:

Use real <button>: This gives you correct keyboard behavior, semantics, and form integration out of the box.
Default type="button": In HTML, the missing-value default for <button> is submit, which will submit the form when clicked if it’s inside a <form>. Defaulting to type="button" in your component prevents accidental form submissions and forces submit buttons to opt in.
Prop spreading: Extending ButtonHTMLAttributes and spreading ...props lets consumers use any native attribute: disabled, aria-*, form, name, etc.
Ref forwarding: Consumers can focus the button programmatically or integrate it with other imperative APIs.

That type="button" decision is a good example of basics that AI won’t catch for you: it will happily generate a component that works in a Storybook story, but will fail in subtle ways once someone uses it inside a real form.

Input – getting forms right

Inputs are where "div soup" really breaks things. An input should:

Be associated with a <label> so assistive tech can announce it.
Support browser validation (required, pattern, minLength, etc.).
Integrate with form libraries and password managers.
Communicate errors clearly to both sighted users and screen readers.

Implementation:

import React, { useId } from 'react';

interface InputProps extends React.InputHTMLAttributes<HTMLInputElement> {
  label?: string;
  error?: string;
}

const Input = React.forwardRef<HTMLInputElement, InputProps>(
  ({ className, error, id, label, ...props }, ref) => {
    const reactId = useId();

    const inputId = id || `input-${reactId}`;

    return (
      <div className="input-wrapper">
        {label && <label htmlFor={inputId}>{label}</label>}
        <input
          id={inputId}
          className={`input ${error ? 'input--error' : ''} ${className || ''}`}
          ref={ref}
          aria-invalid={!!error}
          aria-describedby={error ? `${inputId}-error` : undefined}
          {...props}
        />
        {error && (
          <span id={`${inputId}-error`} role="alert">
            {error}
          </span>
        )}
      </div>
    );
  }
);

Input.displayName = 'Input';
export default Input;

Why this works well:

Label is automatically associated with the input when provided.
Uses a real <input>, so you get native events, validation, autofill, and password manager integration.
Uses id plus aria-describedby to connect the error message to the input. Screen readers read them together.
Uses role="alert" so new error messages are announced as soon as they appear.

With form libraries like React Hook Form, this component plugs in with almost no extra work.

Dropdown – Native First, Custom When Needed

Dropdowns are where component complexity spikes. There are really three levels:

Native <select> (best default)
Custom dropdown / combobox (when design requires it)
Virtualized dropdown (when data size requires it)

Native `<select>` – start here

If you can get away with a native <select>, you should. It has excellent built-in accessibility, keyboard support, and form integration.

interface SelectOption {
  label: string;
  value: string;
}

interface SelectProps extends React.SelectHTMLAttributes<HTMLSelectElement> {
  label?: string;
  options: SelectOption[];
  error?: string;
}

const Select = React.forwardRef<HTMLSelectElement, SelectProps>(
  ({ label, id, options, error, className, ...props }, ref) => {
    const reactId = React.useId();
    const selectId = id || `select-${reactId}`;

    return (
      <div className="select-wrapper">
        {label && <label htmlFor={selectId}>{label}</label>}
        <select
          id={selectId}
          ref={ref}
          className={`select ${error ? 'select--error' : ''} ${className || ''}`}
          aria-invalid={!!error}
          aria-describedby={error ? `${selectId}-error` : undefined}
          {...props}
        >
          {options.map(opt => (
            <option key={opt.value} value={opt.value}>
              {opt.label}
            </option>
          ))}
        </select>
        {error && (
          <span id={`${selectId}-error`} role="alert">
            {error}
          </span>
        )}
      </div>
    );
  }
);

Select.displayName = 'Select';
export default Select;

Why this is often enough:

Keyboard support (Tab, Arrow keys, Home/End, typeahead) is built-in.
Screen readers know exactly how to announce it.
Works seamlessly with forms, validation, and autofill.

If your design system allows using the browser’s native select (possibly with minimal styling), this should be your default.

Custom dropdown / combobox – when design demands it

When you truly need a fully custom dropdown (multi-column options, icons, complex layout), you are essentially implementing the WAI-ARIA combobox pattern.

At a minimum, you need:

A button or input that acts as the combobox:
- role="combobox"
- aria-expanded (true/false)
- aria-controls pointing at the popup listbox
A popup with:
- role="listbox"
- Each option having role="option"
- aria-selected to track the active option
Keyboard support:
- Down/Up to move between options
- Enter/Space to select
- Escape to close
- Tab to move focus out

A simple custom dropdown (select-only combobox):

interface DropdownOption {
  value: string;
  label: string;
}

interface DropdownProps {
  label?: string;
  value?: string;
  onChange?: (value: string) => void;
  options: DropdownOption[];
  placeholder?: string;
}

const Dropdown = React.forwardRef<HTMLDivElement, DropdownProps>(
  ({ label, value, onChange, options }, ref) => {
    // States
    const [isOpen, setIsOpen] = React.useState(false);
    const [highlightedIndex, setHighlightedIndex] = React.useState(0);

    // Ref to the trigger button
    const buttonRef = React.useRef<HTMLButtonElement | null>(null);

    // Dropdown ID
    const listboxId = React.useId();

    // Currently selected option
    const selectedOption = options.find(opt => opt.value === value);

    /** Opens / closes the dropdown */
    const toggleOpen = () => setIsOpen(prev => !prev);

    /** Closes the dropdown */
    const close = () => setIsOpen(false);

    /**
     * Handler function called when an item is selected.
     */
    const handleSelect = (option: DropdownOption) => {
      onChange?.(option.value);
      close();
      buttonRef.current?.focus();
    };

    /**
     * This function is responsible for keyboard accessibility.
     */
    const handleKeyDown = (e: React.KeyboardEvent<HTMLButtonElement>) => {
      if (!isOpen) {
        if (
          e.key === 'ArrowDown' ||
          e.key === 'ArrowUp' ||
          e.key === ' ' ||
          e.key === 'Enter'
        ) {
          e.preventDefault();
          setIsOpen(true);
          setHighlightedIndex(0);
        }
        return;
      }

      switch (e.key) {
        case 'ArrowDown':
          // Highlight next item
          e.preventDefault();
          setHighlightedIndex(prev => Math.min(prev + 1, options.length - 1));
          break;
        case 'ArrowUp':
          // Highlight previous item
          e.preventDefault();
          setHighlightedIndex(prev => Math.max(prev - 1, 0));
          break;
        case 'Enter':
        case ' ':
          // Select item
          e.preventDefault();
          handleSelect(options[highlightedIndex]);
          break;
        case 'Escape':
          // Close dropdown
          e.preventDefault();
          close();
          buttonRef.current?.focus();
          break;
        default:
          break;
      }
    };

    return (
      <div className="dropdown" ref={ref}>
        {label && <div className="dropdown__label">{label}</div>}

        <button
          type="button"
          ref={buttonRef}
          className="dropdown__button"
          aria-haspopup="listbox"
          aria-expanded={isOpen}
          aria-controls={listboxId}
          role="combobox"
          onClick={toggleOpen}
          onKeyDown={handleKeyDown}
        >
          {selectedOption ? selectedOption.label : placeholder}
        </button>

        {isOpen && (
          <ul id={listboxId} role="listbox" className="dropdown__listbox">
            {options.map((option, index) => (
              <li
                key={option.value}
                role="option"
                aria-selected={value === option.value}
                className={
                  'dropdown__option' +
                  (index === highlightedIndex
                    ? ' dropdown__option--highlighted'
                    : '')
                }
                onMouseDown={e => {
                  // prevent button blur before click
                  e.preventDefault();
                  handleSelect(option);
                }}
              >
                {option.label}
              </li>
            ))}
          </ul>
        )}
      </div>
    );
  }
);

Dropdown.displayName = 'Dropdown';
export default Dropdown;

This is a select-only combobox, which matches a lot of "styled select" requirements while staying close to the ARIA Authoring Practices.

As you can see, the moment we move away from native components, we need a significant amount of code to mimic the browser.

Large lists – performance concerns creep in

"A large list would be required on an e-commerce site with 500+ brands in a filter dropdown or an analytics dashboard with 10,000+ customer options and for other such use cases. Rendering all of them at once makes page janky, keyboard navigation stutter, and the whole experience feel broken on lower-end devices."

All the patterns above assume a reasonable number of options. Once you cross a few hundred items, a naive implementation starts to hurt:

Rendering hundreds or thousands of <li> elements on every open/close or filter causes noticeable jank, especially on lower-end devices. Keyboard navigation becomes sluggish because every Arrow key press can trigger a large re-render. If each option is a complex React tree (avatars, icons, metadata), your dropdown can quietly become one of the heaviest parts of the page.

At that point you want virtualization: only render the items that are visible (plus a small buffer), and recycle DOM nodes as the user scrolls. Libraries like react-window are designed exactly for this.

It would be too complex to have this implementation in this blog post, but if you are interested you can check this codesandbox example where I have integrated react-window with a Dropdown component that I created.

Component checklist

Here’s a quick checklist you can use the next time you create or review a component.

Design:

Pick the correct semantic base element.
Decide how keyboard navigation should work.
List all meaningful states (loading, error, disabled, empty, etc.).
Identify which text should be overridable for i18n.

Implementation:

Use semantic elements (button, input, label, select, ul/li).
Implement keyboard behavior explicitly where the platform doesn’t provide it.
Wire ARIA attributes (roles, aria-expanded, aria-describedby, aria-invalid).
Extend native attribute types and spread ...props.
Forward refs for components that might need focus control.

Accessibility & UX:

Tab reaches all interactive elements in a sensible order.
Focus styles are visible and not removed.
Error messages are linked and read with inputs.
Test with at least one real screen reader.

Testing & Docs:

Use React Testing Library to test behavior, not implementation details.
Run a basic axe-core or similar accessibility audit in CI.
Document keyboard and ARIA behavior.

Putting it all together: `no-frills-ui`

No Frills UI is a small React component library that I built as a learning project to apply these principles in a real codebase, and to treat even a "toy" library with production discipline (tests, docs, CI, releases).

Following are few UI development challenges that I solved while building this library.

CSS variables instead of ThemeProvider

NFUI uses CSS variables for theming:

:root {
  --nfui-primary: #2563eb;
  --nfui-background: #ffffff;
}

[data-theme='dark'] {
  --nfui-primary: #60a5fa;
  --nfui-background: #1f2937;
}

Components consume var(--nfui-primary) etc., so switching theme is as simple as toggling a data attribute on <html>, no React re-render, no theme context.

i18n-ready by design

Components that render text (Dialogs, toasts, etc.) expose those strings as props. This keeps the library locale-agnostic and lets consumers plug in whichever i18n system they already use.

Dialogs with a promise-based API

A common issue I have seen across projects is when we need to confirm a delete action. Often a modal is shown for this confirmation and then the delete API is called. For this, an open state is maintained for the modal. Inside the modal click handlers for confirm and cancel buttons are wired. Finally a onConfirm and onClose callbacks are exposed as prop. When this pattern is repeated in multiple places, it leads to major code bloat.

Some of this can be moved to a reusable ConfirmDialog component. However, you still need to maintain open, onConfirm and onClose callbacks. Not to mention, the delete code flow get fragmented into multiple callbacks.

This is the issue with a purely declarative approach. And so to solve this I took an imperative approach.

Instead of wiring isOpen, onConfirm, onClose state everywhere, NFUI exposes an imperative API:

import { useRef } from 'react';
import { ConfirmDialog } from 'no-frills-ui';

const confirmDialog = useRef<ConfirmDialog>();


const deleteHandler = async () => {
  try {
    await confirmDialog.current.show();
    // Call delete API
  } catch (e) {
    // User cancelled the operation
  }
}

// render
<button type="button" onClick={deleteHandler}>Delete</button>
<ConfirmDialog
  ref={confirmDialog}
  header='Delete item'
  body={`Are you sure you want to delete this item?`}
/>

Here, an imperative ref is used for the dialog. Dialog maintains all the state and click handlers. The show function in ConfirmDialog returns a promise. The promise is resolved when the user confirms else it is rejected.

This reduces the code by a significant amount and also the entire delete logic is in one function called deleteHandler.

Similar approach is taken for AlertDialog, PromptDialog, Notification and Toast components. This reduces effort required to pass feedback to user whenever an async action completes.

LayerManager: inspired by `react-layers-manager`

Managing z-index for modals, dialogs, drawers, notifications, and toasts quickly becomes chaotic. NFUI uses a LayerManager service that:

Registers each new "layered" component (dialogs, drawers, etc.).
Assigns z-index based on open order.
Ensures only the topmost layer is interactable.
Cleans up when components close.

This idea was inspired by react-layers-manager, which centralizes layer and portal management to avoid ad-hoc z-index wars. NFUI’s version is smaller and customized, but the core concept, centralizing stacking and focus, comes from that prior work.

What this means is that developer using no-frills-ui component will never have to worry about the z-index. All no-frills-ui stackable components uses this layer manager to get their layer.

What did we achieve?

Remember that "delete button inside a drawer" from the start? By this point, you have all the pieces: a Button that won’t accidentally submit forms, a Dialog that can confirm via a simple await confirmDialog.current.show(), and a LayerManager that guarantees the dialog stacks correctly over the drawer. The point isn’t just how each component works in isolation, but how they combine into boring, predictable behavior in real UI flows.

This is what a well-engineered set of components enables: each piece does one thing well, and they compose cleanly to solve a real UI problem with very little glue code. AI can absolutely generate the JSX for a button, a dialog, or even a drawer faster than any human. But only a human can see the bigger picture, choose the right semantics and patterns, and design an API that solves the problem with fewer lines of code, fewer bugs, and better long-term maintainability.

Where to explore further

If you are interested then you can check out no-frills-ui repository or
skim through the storybook doc.

If anything in this post feels off, unclear, or incomplete, or if you have another pattern you think belongs here, please leave a comment. Component design is nuanced, and catching mistakes or blind spots is much easier when more eyes (and more contexts) are involved.

Understanding Promise Chaining

Pushkar Anand — Sun, 27 Jul 2025 15:16:08 +0000

Let's be honest, nobody needs to write a polyfill for promise these days. Most of us only look for it when we start preparing for interviews. Promise polyfill is among the most common questions asked in JavaScript interviews. As a consequence, there are endless blogs on this.

So why am I writing this?

Well, I found that most of them have implemented Promise wrong! Most common mistake that I find in these implementations is that they return this. However, if you go through MDN docs, it clearly states that then returns a new Promise.

So, in this post, I want to take you through my journey on what I feel is the correct implementation of promise.

Defining Promise

Let's start by defining a basic Promise class.

type ExecutorFn<T> = (
  resolve: (data?: T) => unknown,
  reject: (reason?: unknown) => unknown,
) => void;

class MyPromise<T> {
  constructor(executor: ExecutorFn<T>) {}

  /**
   * Called when Promise is resolved.
   */
  private resolve = (data?: T) => {}

  /**
   * Called when Promise is rejected
   */
  private reject = (error?: unknown) => {}
}

This seems simple enough to start. We have a constructor for our Promise which takes executor function as parameter. This executor function will be passed resolve and reject callbacks to fulfill or reject the promise respectively. We have two private methods for resolve and reject as well.

Before we start Implementing these methods, we must define how the Promise works. Let's list down the key behaviors:

Executor function should be run synchronously when the Promise is created.
One of the most common mistakes I see is calling the executor function inside setTimeout. When in reality the executor function is run as soon as Promise is created. This can be verified by running following snippet in browser console.
```
console.log('Start');
const p = new Promise((resolve) => {
  console.log('Executor Function Called');
  resolve('Promise Resolved');
});
p.then((value) => console.log(value));
console.log('End');

/** Result: **
Start
Executor Function Called
End
Promise Resolved
*/
```
resolve and reject should be pushed to micro task queue.
Another common mistake is using setTimeout. Promises are pushed to micro task queue where as setTimeout goes to macro task queue (or just task queue). I have seen few people describing this behavior as Promise having a higher priority. If this is something new to you and you want to understand this better, I suggest you watch this awesome talk.
then, catch and finally should return a new Promise.
Multiple then, catch and finally can be added to same promise.
Though Promise can be resolved/rejected only once. We can attach multiple then, catch, finally blocks to it.

then, catch and finally can be called on a Promise, long after the Promise has been fulfilled/Rejected.
We can verify above 2 points using following code snippet.

const p = Promise.resolve('Data');

p.then((value) => console.log('Get 1:', value));
p.then((value) => console.log('Get 2:', value));

setTimeout(() => {
  p.then((value) => console.log('Get 3:', value))
}, 5000);

/** Result: **
Get 1: Data
Get 2: Data
// After 5 seconds
Get 3: Data
*/

If callbacks from then, catch and finally returns a promise then the returned Promise should be chained.
This means that we can even return a Promise from callbacks passed to then, catch and finally and still receive the resolved value of the returned Promise. Following snippet will demonstrate this.

const p = Promise.reject('Bad Request');
p.then(() => console.log('What?'))
 .catch(() => Promise.resolve('Handled'))
 .then((value) => console.log(value));
/** Result: **
Handled

** Explanation **
Here the first `then` is never called and `catch` block
returns a Promise. But the value received by second `then`
block is not Promise but the resolved value of the returned
Promise.
*/

Unhandled rejection should be caught and logged in browser console.
finally should be called in both resolution and rejection of the promise.

Now we can implement our constructor

class MyPromise<T> {
  constructor(executor: ExecutorFn<T>) {
    // Call the executor synchronously
    try {
      executor(this.resolve, this.reject);
    } catch (e) {
      // Reject promise on error
      this.reject(e);
    }
  }

  /**
   * Called when Promise is resolved.
   */
  private resolve = (data?: T) => {}

  /**
   * Called when Promise is rejected
   */
  private reject = (error?: unknown) => {}
}

To ensure synchronous call to executor function, I directly call it in the constructor. However there can be case where the executor function throws an error. For this I wrapped it in try catch block and on error, simply rejected the promise with the error.

Resolve and Reject

Next let's implement the resolve and reject function. For this we need do define few variables in our class. Since a Promise can be only one of the three state (Pending, Fulfilled, or Rejected) we need a status variable. And since we know that Promise value can be used long after it has settled, we should also store the value. For this I will create 2 variables, successData and failureError.

class MyPromise<T> {
  /** Status of the Promise */
  private status: 'pending' | 'fulfilled' | 'rejected' = 'pending';
  /** Stores value of the promise if it is resolved */
  private successData?: T;
  /** Stores error returned by the promise if it is rejected */
  private failureError?: unknown;

  constructor(executor: ExecutorFn<T>) {
    // Call the executor synchronously
    try {
      executor(this.resolve, this.reject);
    } catch (e) {
      // Reject promise on error
      this.reject(e);
    }
  }

  /**
   * Called when Promise is resolved.
   */
  private resolve = (data?: T) => {}

  /**
   * Called when Promise is rejected
   */
  private reject = (error?: unknown) => {}
}

Now let's focus on resolve. As we know, we need to push the execution of resolve in a micro task queue, we will have to use queueMicrotask function. Inside this, we will have to update the status to fulfilled and also save the value passed to resolve function. It is also a good idea to check that Promise is in pending state, so that we don't override the value if resolve is called twice. Thus we can write our resolve function as described below:

class MyPromise<T> {
  /** Status of the Promise */
  private status: 'pending' | 'fulfilled' | 'rejected' = 'pending';
  /** Stores value of the promise if it is resolved */
  private successData?: T;
  /** Stores error returned by the promise if it is rejected */
  private failureError?: unknown;

  constructor(executor: ExecutorFn<T>) {
    // Call the executor synchronously
    try {
      executor(this.resolve, this.reject);
    } catch (e) {
      // Reject promise on error
      this.reject(e);
    }
  }

  /**
   * Called when Promise is resolved.
   */
  private resolve = (data?: T) => {
    queueMicrotask(() => {
      // Promise can be resolved only once
      if (this.status === 'pending') {
        // Update status and store data
        this.status = 'fulfilled';
        this.successData = data;
      }
    });
  }

  /**
   * Called when Promise is rejected
   */
  private reject = (error?: unknown) => {}
}

Similarly implementing reject as:

class MyPromise<T> {
  /** Status of the Promise */
  private status: 'pending' | 'fulfilled' | 'rejected' = 'pending';
  /** Stores value of the promise if it is resolved */
  private successData?: T;
  /** Stores error returned by the promise if it is rejected */
  private failureError?: unknown;

  constructor(executor: ExecutorFn<T>) {
    // Call the executor synchronously
    try {
      executor(this.resolve, this.reject);
    } catch (e) {
      // Reject promise on error
      this.reject(e);
    }
  }

  /**
   * Called when Promise is resolved.
   */
  private resolve = (data?: T) => {
    queueMicrotask(() => {
      // Promise can be resolved only once
      if (this.status === 'pending') {
        // Update status and store data
        this.status = 'fulfilled';
        this.successData = data;
      }
    });
  }

  /**
   * Called when Promise is rejected
   */
  private reject = (error?: unknown) => {
    queueMicrotask(() => {
      // Promise can be rejected only once
      if (this.status === 'pending') {
        // Update status and store error
        this.status = 'rejected';
        this.failureError = error;
      }
    });
  }
}

Implementing `then`

The main challenge in implementing Promise Polyfill lies in then. Rest can be easily implemented using this then function. Since adding the entire class for each small addition would make this post unnecessarily long, I will only add the relevant changes in each snippet. If you want to follow along, I suggest copy the above snippet in a code editor and keep adding the delta in your file.

While implementing then, we should take care of the following things:

then function takes both success and failure callbacks.
It should return a new Promise.
then can be called on already settled Promise.
A promise can have multiple then calls.

For point #4, I will add two arrays in my class successCallbacks and catchCallbacks. I will simply push callbacks passed to then function in these array and call them when the promise is settled from the resolve/reject method.

class MyPromise<T> {
  /** All success callbacks for the promise */
  private thenCallbacks: ((value?: T) => unknown)[] = [];
  /** All failure callbacks for the promise */
  private catchCallbacks:  ((reason?: unknown) => unknown)[] = [];

  /**
   * Called when Promise is resolved.
   */
  private resolve = (data?: T) => {
    // Push to microtask queue
    queueMicrotask(() => {
      // Promise can be resolved only once
      if (this.status === 'pending') {
        // Update status and store data
        this.status = 'fulfilled';
        this.successData = data;

        // Call all success callbacks
        this.thenCallbacks.forEach(cb => cb(data));
        // Clear callbacks to avoid memory leaks
        this.thenCallbacks = [];
        this.catchCallbacks = [];
      }
    });
  };

  /**
   * Called when Promise is rejected
   */
  private reject = (error?: unknown) => {
    // Push to microtask queue
    queueMicrotask(() => {
      // Promise can be rejected only once
      if (this.status === 'pending') {
        // Update status and store error
        this.status = 'rejected';
        this.failureError = error;

        // Call all failure callbacks
        this.catchCallbacks.forEach(cb => cb(error));
        // Clear callbacks to avoid memory leaks
        this.thenCallbacks = [];
        this.catchCallbacks = [];
      }
    });
  };
}

Here the first 2 points are easy to implement as shown below:

class MyPromise<T> {
  /**
   * Promise then chain
   */
  public then = (
    onFulfilled?: (data: T) => unknown,
    onRejected?: (reason: unknown) => unknown
  ) => {
    // Success Callback, default fn would simply return the data
    const successCallback = onFulfilled ? onFulfilled : (data: unknown) => data;

    // Failure Callback, default fn would simply throw the error
    const failureCallback = onRejected ? onRejected : (err: unknown) => { throw err };

    // Return a new Promise
    return new MyPromise((resolve, reject) => {});
  };
}

I just took two callbacks, both of these are optional, so defined a default function for them. For success default function, we just return the value passed and for failure default function we just re-throw the error (This is as per what is described in MDN Doc then parameters). And return a new Promise.

For point #3, we need to check the status of the Promise and act accordingly. Since, the things we need to do in each scenario is quite similar, I have extracted out the main logic in a common handler function.

class MyPromise<T> {
  /**
   * Promise then chain
   */
  public then = (
    onFulfilled?: (data: T) => unknown,
    onRejected?: (reason: unknown) => unknown
  ) => {
    // Success Callback, default fn would simply return the data
    const successCallback = onFulfilled ? onFulfilled : (data: unknown) => data;

    // Failure Callback, default fn would simply throw the error
    const failureCallback = onRejected ? onRejected : (err: unknown) => { throw err };

    // Return a new Promise
    return new MyPromise((resolve, reject) => {
      /**
       * Common handler for both success and failure
       */
      const handle = (callback: Function, arg: unknown) => {
        try {
          // Resolve the returned promise with callback value
          resolve(callback(arg));
        } catch(e) {
          // Reject the returned promise in case of error
          reject(e);
        }
      }

      if (this.status === 'pending') {
        // Push to success callbacks
        this.thenCallbacks.push((data) => {
          handle(successCallback, data);
        });

        // Push to failure callbacks
        this.catchCallbacks.push((error) => {
          handle(failureCallback, error);
        });
      } else if (this.status === 'fulfilled') {
        // Promise is already resolved, pass the data to callback
        queueMicrotask(() => {
          handle(successCallback, this.successData);
        });
      } else {
        // Promise is already rejected, pass the error to callback
        queueMicrotask(() => {
          handle(failureCallback, this.failureError);
        });
      }
    });
  };
}

The handle function is quite simple. We try to call the callback function with the arg. If it succeeds then we resolve the Promise with the callback's returned value. If we encounter any issue then we reject the Promise with the encountered error.

Creating the handle function simplified the remaining logic a lot. For pending case we just push the callback functions in their respective array and when the promise settles, the appropriate callback should be called by our resolve/reject functions.

In case the promise is already settled, then we need to pass the respective callback and data to our handle function. We wrap this inside a queueMicrotask as we don't want to execute the callbacks synchronously. Because as per then specifications, the callbacks are executed asynchronously.

And this completes our then implementation. 🎉

If you have followed along till now, you should give yourself a pat on the back! It may not seem like much but trust me there are many pitfalls and confusing scenarios that we have overcome. Rest of the journey would be fairly simple.

Though there is one important thing that we haven't implemented till now.

Chaining Promise

What if, from my callback I return a promise? Our current implementation would return this Promise as value to Our success callback and that would require us to put another then on the value received by our then. Something like:

new MyPromise((resolve) => {
    resolve(Promise.resolve('Hello World!'))
}).then(value => {
    value.then(finalValue => console.log(finalValue));
});

But we know, this isn't how we are supposed to use Promise. Instead we should get the final value in the outer then function itself. Well this may seem complicated, but quite easy to solve. In our resolve function, we just need to check if the value is thenable. If so, we will just chain our resolve and reject function to this then function.

Something like:

class MyPromise<T> {
  /**
   * Called when Promise is resolved.
   */
  private resolve = (data?: T) => {
    // Check if value is another promise
    if (data && typeof (data as any).then === 'function') {
      (data as any).then(this.resolve, this.reject);
    } else {
      // Push to microtask queue
      queueMicrotask(() => {
        // Promise can be resolved only once
        if (this.status === 'pending') {
          // Update status and store data
          this.status = 'fulfilled';
          this.successData = data;

          // Call all success callbacks
          this.thenCallbacks.forEach(cb => cb(data));
          // Clear callbacks to avoid memory leaks
          this.thenCallbacks = [];
          this.catchCallbacks = [];
        }
      });
    }
  };
}

Unhandled Rejection

Another commonly ignored part about Promise is unhandled rejections. When a Promise's rejection is not handled, a unhandledrejection Event is emitted on window. It will also contain reference to Promise and error.

We can emit this event in our reject method when catchCallbacks is empty. However, I got lazy and didn't want to resolve globalThis for different environments JavaScript can run. So instead added a console.error instead. 😬 Maybe I will implement it in future. 🙈

class MyPromise<T> {
  /**
   * Called when Promise is rejected
   */
  private reject = (error?: unknown) => {
    // Push to microtask queue
    queueMicrotask(() => {
      // Promise can be rejected only once
      if (this.status === 'pending') {
        // Update status and store error
        this.status = 'rejected';
        this.failureError = error;

        // Check for unhandled rejections
        if (this.catchCallbacks.length == 0) {
          console.error("Unhandled Reject");
        }

        // Call all failure callbacks
        this.catchCallbacks.forEach(cb => cb(error));
        // Clear callbacks to avoid memory leaks
        this.thenCallbacks = [];
        this.catchCallbacks = [];
      }
    });
  };
}

Implementing `catch` and `finally`

Now we have then implemented in place along with chaining and unhandled rejection in place. We can easily implement catch and finally function to complete our Polyfill. For these we can simply reuse our then function, as shown in the snippet below.

class MyPromise<T> {
  /**
   * Promise catch chain
   * Implement using then chain
   */
  public catch = (onRejected: (reason?: unknown) => unknown) => {
    return this.then(undefined, onRejected);
  }

  /**
   * Promise finally chain
   * Implement using then chain
   */
  public finally = (onFinally?: () => unknown) => {
    // Using a promise to wrap `onFinally` in both success and failure.
    // This way, if `onFinally` returns another promise, that is also
    // automatically chained.
    return this.then((data: unknown) => {
      return MyPromise.resolve(onFinally?.()).then(() => data);
    }, (reason?: unknown) => {
      return MyPromise.resolve(onFinally?.()).then(() => { throw reason })
    });
  }
}

For catch we simply pass the callback to then.

For finally we wrap it inside a Promise. And since finally doesn't override the value for the Promise. It just calls the callback passed to it. We chain then and return the original data or re-throw the original error.

As always, you can also verify this using the following snippet.

const p = Promise.resolve('Original Value');
p.finally(() => 'Override Value')
 .then(value => console.log(value));

/** Result **
Original Value
*/

Static methods in Promise

I never implemented MyPromise.resolve! Lets implement it right away!

class MyPromise<T> {
  /**
   * Return a Promise and resolve the Promise immediately
   */
  static resolve = <T>(data?: T) => {
    return new MyPromise<T>((resolve) => {
      resolve(data);
    });
  }
}

As you can see its quite simple. We just create a new instance of MyPromise and resolve it with the passed data. Similarly we can implement MyPromise.reject.

There are other static methods on Promise as well like all, race, any, allSettled, withResolver, and try. If we implement all these then the post would become too long. So let's look at only all and remaining will have similar implementation.

class MyPromise<T> {
  /**
   * Wait for all promises to resolve. Return array with resolution
   * of each promise or value.
   * Reject if any promise fails.
   */
  static all = (arr: Iterable<unknown>) => {
    const array = [...arr];
    let result = new Array(array.length);
    let counter = 0;

    return new MyPromise((resolve, reject) => {
      if (array.length === 0) {
        resolve([]);
      }

      const updateResult = (data: unknown, index: number) => {
        result[index] = data;
        counter++;
        if (counter === array.length) {
          resolve(result)
        }
      }

      [...arr].forEach((item, index) => {
        if (item instanceof MyPromise) {
          item.then((data) => {
            updateResult(data, index);
          }, (reason) => reject(reason))
        } else {
          updateResult(item, index);
        }
      });
    });
  }
}

Here we take an array as input. We keep a counter for resolved values. If the item of the array is not a Promise then we add it to our result immediately (at the position of its occurrence in the given input). Else, we wait for it to resolve and then add the resolved value in the result. Once we have all the values, we resolve with the result.

If any promise is rejected then we reject the entire promise.

Full implementation

If you are looking for complete implementation in one place, then checkout my git repository. Here I have implemented the
remaining static methods.

My 2 cents

After this exercise, my appreciation for Promise API has increased manyfold. I also discovered many new things about Promise. However, I still can't say that my implementation is 100% correct and there can be some inaccuracy or edge cases that I missed.

If you spot any such error do let me know by raising an issue.

In case, you still have questions, please don't hesitate to leave a comment. If you like to share your implementation or share your experience with some edge case, I am all ears.

And in case you are thinking whether Promise Polyfill is a good interview question? I am too wondering the same. While your opinion may vary. But my 2 cents would be that this is not a good question for interview. There are too many edge cases to get right in 45 minutes. And the more a candidate knows about Promise, the more disadvantage they are at. If some candidate miraculously does it in 45 minutes, I would have doubt that they have just memorized it.

Anyway you are free to disagree with my points and if you are one of the interviewer who ask this question in interview. My only suggestion would be to define what is required clearly before asking the candidate to write the polyfill.

Creating an End-to-End Encrypted alternative to Google Photos

Pushkar Anand — Sat, 13 Mar 2021 00:00:00 +0000

It all started when my friend approached me for a web app. You see, he was spooked by the fact that all our photos are automatically uploaded to some cloud storage application without any encryption. And so all our private moments are available for corporate companies to train their ML models. Thus he set out to create an end-to-end encrypted photo storage application. He already had a native iOS and Android app in place (which he created using Fluter) when he approached me. So, all APIs and backend systems were already in place. Even a working native application was there to play around. I liked the idea and agreed to help him out. Putting my 6+ years of experience in development to use, I grossly underestimated the size of the project. 😝

As soon as I started working on it, I realized that this isn't a trivial web app where you can call a few APIs, show nice pictures to the user and call it a day. Since it is an end-to-end encrypted application, I had to decrypt everything after downloading them and then present it to the user. I can not rely on a blob/object storage to resize the images. All of this has to be done on the client-side without compromising on the speed. To make things worse, videos were also part of MVP! 😓

Challenges 😪

Most of the problem was solved for the app and the only re-implementation for the web was required. However, since web apps don't have access to the filesystem (without using an experimental API), and encryption / decryption of photos and videos would be a taxing process, I had to use every tool that I had to ensure performance.

Very early on I offloaded all encryption and decryption to a web worker. Thus, the main thread was free of the most taxing part of the application. It also reduced the time it took to encrypt/decrypt a file. I also used Comlink to communicate with the web worker. Initially, we were using AES encryption but later switched to libsodium. The code for this was quite simple.

First, we create a worker as follows.

// Worker File
import * as Comlink from 'comlink';

export class Crypto {
    async encrypt(data, key) {
        // Encryption Logic
    }

    async decrypt(data, nonce, key) {
        // Decryption Logic
    }
}

Comlink.expose(Crypto);

Then we simply load and instantiate the worker using Comlink.

// Application File where the worker is used.
import * as Comlink from 'comlink';

const CryptoWorker = Comlink.wrap(
    new Worker('worker.js', { type: 'module' })
);
const worker = await new CryptoWorker();

await worker.decrypt(data, nonce, key);

Then, we decided that we would cache any thumbnail that we load on UI in a CacheStorage. This way we don't have to re-download and decrypt the image. Improving our second load time. CacheStorage was ideal for this as it is accessible everywhere (main thread, webworker and service workers) and also responds with a Response object. We implemented the entire thing just using following few lines.

// Open cache named `thumbs`
const cache = await caches.open('thumbs');

// Check if we already have thumbnail for the file in cache
const cacheResp: Response = await cache.match(file.id.toString());

if (cacheResp) {
    // Return cached response
    return URL.createObjectURL(await cacheResp.blob());
}

// We don't have it in cache. Lets fetch and decrypt it
const fileData = await fetch(`https://sever/path/to/file?id=${file.id}`);
const decrypted = await worker.decrypt(fileData, file.nonce, file.key);

// Put it in cache for future use
await cache.put(
    file.id.toString(),
    new Response(new Blob([decrypted]))
);

// Return the object URL
return URL.createObjectURL(new Blob([decrypted]));

Also, a good UX for the gallery was a must-have. This is the part where users would interact most often. We wanted it to support all gestures available on a native application like swipe, pinch zoom, and pan, etc. And should also scale to the desktop as well as mobile. For this, we looked at many open-source libraries but found out that we didn't like the UX on most of them and all of them come with some sacrifices. Finally, we settled for PhotoSwipe. It fit most of our use cases. The only part missing was the infinite loading of pages.

Though they have it listed as a feature on their website, we found out that the already loaded images are not removed from the DOM, instead, new pages are just added. This wouldn't be ideal for us as a user can have thousands of images and we would want him to be able to scroll through them quickly. Thus we used react-window and CSS grid to create our gallery layout and let PhotoSwipe handle the interaction once the user clicks on an image. Making our app performant.

We used NextJS for the sweet out of the box SSR.

But we weren't done yet 😶

Everything was going great and we even rolled out a beta version for some users to test, when we started seeing random tab crashes on browser. Definitely there was some memory leak somewhere in the application.

After analyzing the behavior, I noticed that it was happening when my friend tried to open a few video files. Then it hit me, all our encryption and decryption were happening in memory! Which was good enough for small files on which I had tested. But for a large file, the tab would crash as it would run out of the memory limit.

We quickly checked the file sizes and found it was anywhere from 400MB to 1GB. This was not going to work on web. On app we had access to filesystem and so we can process it chunk by chunk and append to file. But on web we don't have access to filesystem and so a different approach was required. Putting everything behind an experimental API that would work only in Chrome is not the experience we wanted to deliver.

And so we kept looking. By luck, I stumbled on this awesome podcast.

Streams was the answer! Instead of putting everything in memory and then encrypting/decrypting the file, we can do it with Readable Streams. However, axios (the library that we were using for making API calls) didn't have support for this. So, we had to resort to fetch APIs. Not a bad compromise I would say.

Finally, I refactored my code to something like below:

// Get the file
const resp = await fetch(`https://sever/path/to/file?id=${file.id}`);

// Get reader to be used in readable stream.
const reader = resp.body.getReader();

// Create a readable stream.
const stream = new ReadableStream({
    async start(controller) {
        // The following function handles each data chunk
        function push() {
            reader.read().then(async ({ done, value }) => {
                if (!done) {
                    // Decrypt chunk
                    const decryptedData = await worker.decryptChunk(value);

                    // Add decrypted data to stream
                    controller.enqueue(decryptedData);

                    // Is there more data to read?
                    push();
                } else {
                    // All done, rest!
                    controller.close();
                }
            });
        };

        push();
    }
});
return URL.createObjectURL(await new Response(stream).blob());

I still had doubts whether this would work. However, once the video loaded without the tab crashing, I was in the seventh heaven.

And miles to go before I sleep 🚶‍♂️

I am happy with the progress that we have made with the project. I was aware that these technologies existed and how they can be used. But implementing them was a completely different ball game. Multiple times I had to rewrite or look for better ways to implement the same thing, as bare metal implementation was tough to maintain. I learned about WebWorkers, Comlink, CacheStorage, and ReadableStream. Worked with multiple libraries and filled in where ever they fall short. All this without sacrificing on UX, usability and performance.

Still, there are few things that I would like to solve. Right now the entire video needs to be downloaded before it can be played. Ideally, I would like it to be able to stream. For this I experimented with MediaSource. MediaSource requires codecs to be specified explicitly, which I don't have. Hence, I am stuck. Please let me know if you have any ideas on how I could work around this. I would love to hear from you. 😊

Sharing is a feature which I feel is also very essential for this application. Just API integration is left for this. I would also like to add Service worker with Workbox for offline caching and convert it to a PWA which can then be installed on mobile and desktop.

The source code for all of this is available here. If you're curious about the product, check out ente.io.😊

Learning SVG animation to spice up my GitHub Profile

Pushkar Anand — Sun, 19 Jul 2020 07:28:34 +0000

TLDR: I created an animated SVG for my GitHub profile, check it out here.

So it all started with GitHub releasing a feature to add a Readme to your profile to showcase all the awesome work that you have done / been doing. And lo and behold, people figured out that it can be used to add GIFs to their profile. 🥳

But I was like, GIFs are so 2010 and SVGs are the new 💩. Only one problem, I don't know a thing about SVGs. I mean yes I have used it for icons and some illustrations. Sometimes generated one from some utility and snapped it onto a page. But I have never delved into how to create one from scratch and add animation to it.

With nothing better to do, I started googling and was surprised to find that MDN has elaborate documentation on SVG elements. Turns out, it is quite simple to add basic shapes. There are tags like rect, circle, polygon, line, and polyline, etc. Then simply write CSS to animate it.

Neat! 👍

So now I can just move a logo on the screen and have boomers look at it for hours! 💪

But I digress. Back to animating SVG. Above mentioned shapes might be more than sufficient for a creative person to come up with some really cool illustration. But my creativity is fairly limited and so I decided to do a moving wave. And to compensate for my lack of creativity, I learned another tag called path, which will help me create this wave. 🌊

The Idea 🤓

The idea was simple. Create multiple moving waves, each at a different speed, and make them a little see-through. The transparency will make the area darker where the waves intersect and thus there will be multiple shades of the color.

For the size of the banner, I settled for 1440 x 320 as I like the aspect ratio. It's not too big but is big enough to add context. Given that on GitHub it would show up in a smaller area, I can be sure that there is enough space left for other things that I might want to add.

<path />

So, I started by learning how to create a path. Which was quite simple. The path tag has a d attribute. It was not hard to get 😉. There are 6 different types of commands.

MoveTo
LineTo
Cubic Bézier Curve
Quadratic Bézier Curve
Elliptical Arc Curve
Close path

We only need to learn the first three. Each command is denoted with a letter followed by attributes which are
points (x-y coordinates).

MoveTo command is denoted by letter M or m followed by the point. So a M10,10 would move the current position to the point 10,10.

Similarly, LineTo has three commands.
L or l creates a line from the current position to the given point. For example, L10,10 would create a line from the current position to 10,10. H or h would create a horizontal line to the given x coordinate. And lastly, V or v would create a vertical line to the given y coordinate.

Cubic Bézier Curve is slightly more complex. It is denoted by letter C or c and takes 3 points as arguments.

So, the current position is the start point. The line from the current position to x1 y1 point defines the tangent to the curve at the start position. And the line from x2 y2 to x3 y3 defines tangent at the finish position. And x3 y3 is the endpoint. To know more about Cubic Bézier Curve refer to this blog post which I find short but descriptive. You can also refer MDN Tutorial on the SVG path to learn more.

To solidify what we learned right now, lets decode the following SVG.

<svg
  viewbox="0 0 100 100"
  width="100" height="100" 
  xmlns="http://www.w3.org/2000/svg">
  <path
    d="M10,10 V50 C10,90,90,90,90,50 V10 H10 V50"
  />
</svg>

The code above results in SVG shown below. For clarity, I have put a green border around the image.

Our path starts at 0,0 and the first command M10,10 moves our point to 10,10. Then the second command V50 creates a vertical path to 10,50. Next C10,90,90,90,90,50 create a curve with 10,90 and 90,90 as our reference points and 90,50 is the endpoint. Then V10 creates a path to 90,10. Next, H10 creates a path to 10,10 and finally V50 closes the path and we get our final image. Simple right? 👌

Implementation ✍️

I divided the image into four quadrants and then planned to have a curve in the second and third quadrants, as shown in the first section in the image above. Then I can slightly move the tangents inwards to dampen the curve. Finally, I closed the path using lines. I moved the center point slightly to have curves that are slightly different. But making sure that the angle the tangents make with the vertical axis is the same. This ensures that the curve looks continuous when I animate it. Finally, I ended up with the path as described below.

<path d="M0,160 C320,300,420,300,740,160 C1060,20,1120,20,1440,160 V0 H0" />

If you are having trouble with understanding the path described above, look at the last section in the image above. I have colour-coded each part of the path to make it more clear. You can also compare it with the section just above it to get an understanding of the points. If you were able to follow me till now, then we already sailed through the difficult waters. 😁

<defs /> and <use />

Although, we can now just copy-paste the above path and create other waves with slight variations and call it a day. I want to introduce defs and use tag, that will help us do all these in a much more readable way. defs can be used to store graphical elements like path and then can be used later using use tag.

All we need to do is give an id to our path and put it inside defs tag and then use it using href attribute in use tag as described below.

<svg
  viewbox="0 0 1440 320"
  width="1440" height="320" 
  xmlns="http://www.w3.org/2000/svg">
  <defs>
    <path
      id='sineWave'
      d="M0,160 C320,300,420,300,740,160 C1060,20,1120,20,1440,160 V0 H0"
    />
  </defs>
  <use href="#sineWave" />
</svg>

Right now a black wave is being rendered. To fix that we use fill and fill-opacity attribute in path. So our updated path becomes as described below.

<path
  fill="#0099ff" fill-opacity="0.2"
  id='sineWave'
  d="M0,160 C320,300,420,300,740,160 C1060,20,1120,20,1440,160 V0 H0"
/>

Animation 🤤

If you are already familiar with CSS animation, this section will be a cakewalk for you. So the idea is very simple. Have two of the waves (that we created above) stacked horizontally and then simply translate them from 0 to 100%. Rinse and repeat. Something like below.

Here the black box represents the viewport of the user.

To achieve this, we add another use tag but with x attribute set to -100%. Apply, wave class to both of these use tags. And create an animation where we translate x from 0% to 100% and apply this animation to our wave class.

<svg
  viewbox="0 0 1440 320"
  width="1440" height="320" 
  xmlns="http://www.w3.org/2000/svg">
  <defs>
    <style type="text/css">
      .wave {
        animation: wave 8s linear infinite;
      }
      @keyframes wave {
        0% {
          transform: translateX(0%);
        }
        100% {
          transform: translateX(100%);
        }
      }
    </style>
    <path
      fill="#0099ff" fill-opacity="0.2"
      id='sineWave'
      d="M0,160 C320,300,420,300,740,160 C1060,20,1120,20,1440,160 V0 H0"
    />
  </defs>
  <use class="wave" href="#sineWave"/>
  <use class="wave" x="-100%" href="#sineWave"/>
</svg>

Finally, I added two more similar waves, the only difference is that I used scaleY in transform CSS property to have a different amplitude of the waves. You can check out the final SVG on CodePen.

Bonus Tips 🤗

I also added a few texts on the banner. This could have been simple as SVG supports Google Fonts but the content security policy of GitHub doesn't allow fonts to be downloaded from external sources. Thus, I used this utility to create an SVG path for me which I copied in my final SVG. Check it out on my GitHub Profile.

Conclusion 👨‍💻

I barely scratched the surface of SVG animation but was able to create something which I think is cool. Was there a better way to do it? Is there some other interesting thing that I should explore? Do let me know by commenting below or send me a tweet on twitter.

Update

My friend showed me SVG Path Visualizer which I find quite useful to visualize the change path.

We also found that there are many example SVGs present online which we can easily tweak using defs and use tags. To test this out, I tweaked this codepen example and created a banner for him which you can checkout on his GitHub profile.

Fullstack Serverless App Template (React + Apollo + GraphQL + TypeScript + Netlify)

Pushkar Anand — Sat, 09 May 2020 17:19:56 +0000

What I built

I created a template that will enable developers to quickly bootstrap an Apollo GraphQL + TypeScript project, which can be deployed in a serverless fashion on Netlify. Also, with the FaunaDB addon, it will enable developers to have a stateful app. Thus, developers can concentrate on core application logic and scale the application as their app grows at the same time they don't have to sacrifice on security.

Netlify functions enable developers to deploy lambda functions. They have a template for Apollo GraphQL as well. However, this template doesn't support TypeScript. Limiting the advantages of GraphQL to just querying and mutating data. Having TypeScript helps developers to change code with reliability. This also enhances overall experience with GraphQL as schema defined in GraphQL can be directly exported to TypeScript types.

For such cases, Netlify recommends using legacy command netlify-lambda command. But people ran into other issues using it.

Submission Category: Foundational Technology

Demo

Application: https://apollo-graphql-typescript.netlify.app/
GraphQL PlayGround: https://apollo-graphql-typescript.netlify.app/.netlify/functions/graphql

Link to Code

pushkar8723 / apollo-graphql-typescript

Template for serverless Apollo + GraphQL + TypeScript app deployed on Netlify

apollo-graphql-typescript

Template for serverless typed GraphQL app deployed on netlify.

Demo: Application | GraphQL PlayGround

How it works

The client side of the app is deployed as static code on netlify. The GraphQL side of the application is developed using apollo-server-lambda and is deployed as netlify function. Netlify deploys each function as AWS lambda. You can read more about it here.

Although, there is a default template which can be quickly bootstraped using the command netlify functions:create, it doesn't support TypeScript and requires developer to use legacy netlify-lambda command. But using the legacy command further complicates the application and also has a few issues which you can read here.

In this template, I transpile the lambda directory using tsc command during the build process. Thus eleminating the need to use netlify-lambda. And I find this is a much more cleaner approach.

Dev Landscape

netlify dev command…

View on GitHub

How I built it

I integrated TypeScript at the build time itself. Thus there is no need to use the legacy command.

Additional Resources/Info

https://community.netlify.com/t/getting-typescript-to-work-with-netlify-functions/6198
https://community.netlify.com/t/does-netlify-dev-support-typescript/3842

UPDATE:

I further integrated graphql-codegen to automatically generate TypeScript types for GraphQL schema. And also integrated eslint and husky to introduce lint checks and validate them before each commit.

UPDATE 2:

I created a demo project using this template and also integrated FaunaDB addon on GitHub.

DEV Community: Pushkar Anand

Building UI Components Correctly in the Age of AI

Let's take an example

Why these details matter

Button – small component, big consequences

Input – getting forms right

Dropdown – Native First, Custom When Needed

Native <select> – start here

Custom dropdown / combobox – when design demands it

Large lists – performance concerns creep in

Component checklist

Putting it all together: no-frills-ui

CSS variables instead of ThemeProvider

i18n-ready by design

Dialogs with a promise-based API

LayerManager: inspired by react-layers-manager

What did we achieve?

Where to explore further

Understanding Promise Chaining

Defining Promise

Resolve and Reject

Implementing then

Chaining Promise

Unhandled Rejection

Implementing catch and finally

Static methods in Promise

Full implementation

My 2 cents

Creating an End-to-End Encrypted alternative to Google Photos

Challenges 😪

But we weren't done yet 😶

And miles to go before I sleep 🚶‍♂️

Learning SVG animation to spice up my GitHub Profile

The Idea 🤓

<path />

Implementation ✍️

<defs /> and <use />

Animation 🤤

Bonus Tips 🤗

Conclusion 👨‍💻

Fullstack Serverless App Template (React + Apollo + GraphQL + TypeScript + Netlify)

What I built

Submission Category: Foundational Technology

Demo

Link to Code

pushkar8723 / apollo-graphql-typescript

Template for serverless Apollo + GraphQL + TypeScript app deployed on Netlify

apollo-graphql-typescript

How it works

Dev Landscape

How I built it

Additional Resources/Info

Native `<select>` – start here

Putting it all together: `no-frills-ui`

LayerManager: inspired by `react-layers-manager`

Implementing `then`

Implementing `catch` and `finally`