Forem: RobbieGM

What does the frontend dev world need to make better applications?

RobbieGM — Thu, 28 Jul 2022 21:47:01 +0000

I finished a side project web app recently and am about to come upon a chunk of free time before uni starts again. It struck me how difficult it was to do things like:

Make an animation performant (lots of CSS properties trigger paint or layout unexpectedly)
Make components with good keyboard accessibility (not just tabbing), common mobile gesture support, etc.
Do styling properly (CSS modules aren't quite cutting it, and on the perf side sometimes recalculating styles takes up to 50ms!)

I'd particularly like to improve the performance story in the frontend world but I'd be interested in creating or contributing to anything (build tools, libraries, linters, etc.) that makes it easier for devs to make a nice user experience. I was going to experiment a bit myself with things like shadow DOM, wasm, and web workers to see if those things might be suitable for the mainstream web (for wasm we have yew, for example, but it's niche). I thought that first, I should get the opinion of web devs more experienced than myself.

To repeat the title question: What does the frontend dev world need to make better applications?

16 Underused Web Platform Features

RobbieGM — Fri, 14 Aug 2020 00:56:22 +0000

What follows is a list of APIs and features that are uncommon to see in the wild, but have use cases nonetheless and the potential to greatly improve the experience your users have while visiting your website. Each feature below has a link to a demo so you can try it out in your browser. Without further ado...

App shortcuts

This feature allows your PWA, when installed on the home screen, to show shortcut options when the app icon is long-pressed by the user. It is often used by messaging apps to provide shortcuts to frequently messaged users, though dynamically updating the shortcuts in your app manifest for a use case like that is not easy.

Web Share API

Alright, this one is more well known but I feel like it is important enough that it should be included anyway. This API allows web apps on mobile devices to use the native share dialog.

Web Push API

This is different from the notifications API. It's used to send notifications, but the important addition here is that the website does not need to be open in the browser in order for notifications to come through.

Credentials Management API

This API allows web applications to store and retrieve credentials such as username/password pairs or federated login data. This could be used to provide a quick way to use saved logins without visiting a login page and clicking the log in button with autofilled credentials.

Web OTP API (aka SMS Receiver API)

The Web OTP API provides a simple way to use SMS for two-factor authentication. It lets the web application intercept certain text messages (ones which contain its origin) and use them to authorize the user if given permission. Definitely simpler for the user than having to type in a code!

content-visibility CSS Property

The content-visibility property allows browser engines to render content much quicker by only rendering what is above the fold and waiting to render other content. This property has three possible values:

visible - no effect
hidden - similar to display: none but the browser does not discard the previous rendering state, so changing from content-visibility: hidden to visible is more performant than changing from display: none to block.
auto - turns on "containment" - a way for the browser to estimate the size of an element in various ways without rendering descendants (for performance).

More information is available in the link above or in the spec.

Keyboard Lock API

Allows web apps in fullscreen mode, such as games or remote desktop applications, to listen to the activation of certain key combinations which would otherwise be trapped by the browser or OS (such as Alt + Tab or Ctrl + W).

Native Filesystem API

Provides a way for web apps to open files and save them directly to the user's file system. This kind of thing is very useful for file editors. If you want to try the demo above, make sure to use Chrome and enable the experimental web platform feature chrome://flags/#native-file-system-api.

Wake Lock API

Wish the screen wouldn't go to sleep while your web app is being used, even if not actively in a way which would normally keep the screen on? The Wake Lock API can be used to keep the user's device from going to sleep while they are, say, reading a recipe. This API helped Betty Crocker achieve a 300% increase in purchase intent indicators on their website.

Periodic Background Sync API

Sorry I couldn't find a demo for this one. The background sync API is similar to the Push API in that it requires a service worker and receives information in the background. The app will periodically receive a periodicsync event on the service worker which allows it an opportunity to fetch data. This API is most useful when you want to save content for offline use, but could be used to keep content cached and fresh so it is loaded instantly when the site is opened. More information can be found on the web.dev blog post about this feature.

Web Share Target API

The flip side of the Web Share coin is that not only can you share content to other apps, your app can be a target to receive shared content. First, however, the PWA must be installed. The demo above, as well as the API itself, only work in Chrome for Android at the time of this writing.

Contact Picker API

This API lets users select contacts to upload to a website through a contact picker widget. Names, emails, telephone numbers, addresses, and icons can all be requested.

Image lazy loading

The loading attribute on an HTML img element, when set to "lazy", instructs the browser not to load the image until it is in view or about to be scrolled into view. This results in bandwidth savings for users.

Payment Request API

The payment request API is undoubtedly the most streamlined method to integrate payments into your website. It can show the user what they are buying, show how much it will cost, and even ask for shipping information. The user can pay with their saved credit card information or third party payment processor.

App Badging API

As a less intrusive (and permissionless) alternative to showing notifications is app badging. This API allows your app to set a badge number, such as a number of new unread notifications, on its icon.

Vibration API

Activates vibration hardware in the user's device, but must be in response to a click. (Vibration for notifications can be done through the notifications API.) Use sparingly--vibration is often more annoying than helpful, which may explain the API's absence in iOS Safari.

How to reload a Next.js page's initial props without reloading the whole page

RobbieGM — Mon, 18 May 2020 14:08:25 +0000

If you have made a Next.js page that loads data in its getInitialProps function, you may have wanted to reload it in order to fetch the newest data after making some mutating API call. Hard-reloading the page will reset the user's scroll position and take extra time, so clearly that is not the best solution. You could also make some fetchData function that gets called in getInitialProps, passes its data into the default value of a useState hook, and then gets updated by calling fetchData again followed by setting the state. But wouldn't it be convenient if you could just have a function that reloaded your initial props?
I made a higher order component to wrap Next.js pages that does exactly this. Here it is in TypeScript:

import { NextPage, NextPageContext } from 'next';
import React, { useState, PropsWithChildren, ComponentType } from 'react';

export interface SoftReloadProps {
  /**
   * Reloads the page's initialProps without causing a real browser "hard" reload.
   */
  softReload(): void;
}

type OmitSoftReloadProps<T> = Omit<T, keyof SoftReloadProps>;
type SoftReloadablePageInitialProps<TProps> = OmitSoftReloadProps<TProps> & { context: NextPageContext };
export type NextPageWithInitialProps<P, IP = P> = NextPage<P, IP> & Required<Pick<NextPage<P, IP>, 'getInitialProps'>>;

/**
 * Removes never-used context values to reduce bloat. Context values may come from server but then
 * be used client-side because they are saved in initial props.
 */
function minifyContext(context: NextPageContext): NextPageContext {
  return { ...context, req: undefined, res: undefined };
}

const withSoftReload = <TProps extends SoftReloadProps>(
  Page: NextPageWithInitialProps<TProps, OmitSoftReloadProps<TProps>>
): NextPage<SoftReloadablePageInitialProps<TProps>> => {
  async function getInitialProps(ctx: NextPageContext): Promise<SoftReloadablePageInitialProps<TProps>> {
    return { context: minifyContext(ctx), ...(await Page.getInitialProps(ctx)) };
  }
  const omitContextFromProps = ({
    context,
    ...props
  }: SoftReloadablePageInitialProps<TProps>): OmitSoftReloadProps<TProps> => props as any;
  const NewPage: NextPageWithInitialProps<SoftReloadablePageInitialProps<TProps>> = props => {
    // set inner page initial props to wrapper initial props minus context
    const [initialProps, setInitialProps] = useState(omitContextFromProps(props));
    async function softReload() {
      setInitialProps({ children: null, ...(await Page.getInitialProps(props.context)) });
    }
    return (
      <Page
        {...(({ ...initialProps, softReload } as Omit<TProps, keyof SoftReloadProps> & SoftReloadProps) as TProps)}
      />
    );
  };
  NewPage.getInitialProps = getInitialProps;
  NewPage.displayName = `withSoftReload(${Page.displayName})`;
  return NewPage;
};

export default withSoftReload;

You can use this HOC like this in your pages:

interface InitialProps {
  data: string;
}

const MyPage: NextPageWithInitialProps<InitialProps & SoftReloadProps, InitialProps> = ({ data, softReload }) => (
  <div>
    {data}
    <button onClick={softReload}>Refresh</button>
  </div>
);

MyPage.getInitialProps = async (ctx) => {
  // fetch data
};

export default withSoftReload(MyPage);

Hope you enjoy!

Design Principles of Crank.js and React

RobbieGM — Thu, 07 May 2020 16:43:12 +0000

On April 15, 2020, a new frontend JavaScript framework was released. Yes, I know. I can already hear the groans of developers who have had to learn PHP, then Angular, then React, and now worry that they may have to learn this. The author of the framework apologized for the release, but thought that his framework would meaningfully impact the way that user interfaces are made in a way that benefits developers and users. In his article he explains the need for Crank.js and how he thinks React’s features are becoming more and more hacky and arcane. One example of this is React’s somewhat recent hooks API. While many React fans hail the release of hooks as the greatest feature of the framework, the author of Crank.js did not agree, describing his distaste for the “strangeness and pitfalls” of the hooks API. Anyone who has used React’s functional components with hooks will be familiar with how everything must be memoized to avoid unnecessary re-renders, requiring dependencies of functions to also be memoized, and so on and so forth until your every function is wrapped with useCallback and every variable with useMemo. The creator of the new framework also seemed less than enthusiastic about the upcoming release of React’s Suspense API, which is designed to avoid data-fetching waterfalls. Suspense detects that components need to load by having those components throwing promises during render time (yes, with the throw keyword as if throwing an error) which understandably seems weird. He complains that “it doesn’t even matter what the thrown promise fulfills to; instead, it’s an elaborate way to notify React that your components are ready to try and render again.” Furthermore, a cache must be maintained in order to avoid fetching the same data again and again on each re-render. In order to cache async calls, you must be able to uniquely key each one and know when to invalidate its results. The author expresses his disinterest for having to manage cache invalidation, and references the well-known joke that cache invalidation is one of the hardest problems in computer science. He eventually felt alienated by where React was going. He envisioned a world in which asynchrony was managed by JavaScript alone instead of by strange framework hacks. Why can’t components just return promises instead of JSX when they’re not done loading yet?

In Crank.js, they can. Components can be plain functions, async functions, generators, and async generators. When a component needs to wait to render, it can simply return a promise instead of JSX. To add state to a component, you can simply add local variables and make the function a generator that yields JSX infinitely. The library also allows you to dispatch and handle custom events, similar to Vue.js. While the Crank framework makes use of numerous design principles shared by nearly all frontend frameworks, such as lifting state up and using composition over inheritance, it eschews the notion that all renders must be pure and side-effect free, a core principle of React’s design that the author of Crank.js describes as “dogmatic” and impractical.

Not everyone is totally on-board with the principles of this new framework though. One day after the release of Crank.js was announced on Reddit, Dan Abramov, a lead React contributor, came out in defense of React. He explained that React’s component-purity-driven philosophy is only a means to solving a problem of the end user: it’s nice to be able to render components before they appear on screen so that they paint faster. He said that one “can only really do those things safely when rendering is pure and safe to try at any time or interrupt”. Dan also argued that caching is not an ugly side effect of the Suspense API: Suspense was built around the use of a cache because caches improve the user experience by speeding up data fetching. However, he ultimately said that he “totally agrees with [the author of Crank.js] it’s great to have more options that explore various tradeoffs.”

A quick question for people who use version control

RobbieGM — Thu, 13 Feb 2020 17:40:45 +0000

In my team, we use git branching to keep different features separate (of course). However, one co-worker insists on keeping these features in different files as well to avoid merge conflicts. For example, we may have a FormView.java on master, but in have both a FormView.java and a ValidatedFormView.java on the form-validation branch. I suggested that rather than duplicating files to "work around" git, we should let git do its thing and merge features when we want to. He also wants to keep duplicates in order to be able merge some parts of a feature into other branches without having to deal with merging the FormView.java file itself.

What should we do? If he is right, why? If I am right, how can I convince him as such?