Component Anti-Patterns

[calebjacob]

Our team has been building BOS components for almost a year now and we've come across a few anti-patterns that can lead to poor UX and/or performance issues. Grab a cup of coffee (or your alternative beverage of choice) and let's dive in!

Cascading HTTP Requests

One of the biggest performance bottlenecks for websites is the number of HTTP requests required to load the page. It's important to focus on keeping the number of requests as low as possible whenever implementing new features.

Here are two components that can quickly cause a large number of cascading requests:

• AccountProfile
• TimeAgo

This following example would trigger 2 additional HTTP requests for every post rendered:

const [posts, setPosts] = useState([]);

// Some logic to fetch posts from Social.DB...

return (
  <div>
    {posts.map((post) => (
      <div key={post.id}>
        <Widget
          src="near/widget/AccountProfile"
          props={{ accountId: post.accountId }}
        />
        <Widget
          src="near/widget/TimeAgo"
          props={{ blockHeight: post.blockHeight }}
        />
        <p>{post.message}</p>
      </div>
    ))}
  </div>
);

If we look at these two components, we'll discover the following:

• AccountProfile has to call Social.get(${props.accountId}/profile/**, "final") to render the account's avatar and display name
• TimeAgo has to call an endpoint to calculate a timestamp based on the passed prop.blockHeight

So what's the solution here? In most examples like this, the best solution is to use Query API to fetch all of the required data in a single request. We can then pass this data down to our components through props. If we look at AccountProfile and TimeAgo, we'll notice we can pass in profile and blockTimestamp props to avoid these extra requests:

const [posts, setPosts] = useState([]);

// Some logic to fetch posts from Query API...

return (
  <div>
    {posts.map((post) => (
      <div key={post.id}>
        <Widget
          src="near/widget/AccountProfile"
          props={{ accountId: post.accountId, profile: post.accountProfile }}
        />
        <Widget
          src="near/widget/TimeAgo"
          props={{
            blockHeight: post.blockHeight,
            blockTimestamp: post.blockTimestamp,
          }}
        />
        <p>{post.message}</p>
      </div>
    ))}
  </div>
);

If our example was rendering 50 posts, we'd now be making a single request instead of 101 (+1 for the initial fetch, +50 for each AccountProfile, and +50 for each TimeAgo)! Although 101 is a reasonable number of Dalmatians, it's an outrageous number of HTTP requests for a single feature.

Re-rendering Expensive Components

When developing more complex features, we can end up with large components that have many state updates and HTTP requests. Every time a piece of state is updated, a re-render will occur for the entire component (which can also re-trigger the HTTP requests depending on our logic). Due to the complexities of how the VM parses and runs JavaScript in a secure environment, these re-renders can be more expensive than you would expect compared to working within a typical React environment.

The best solution for avoiding expensive re-renders is breaking up large components with multiple features into separate components that implement each feature separately.

Here's an example of a component that could be refactored:

const [data, setData] = useState({});

const loadData = () => {
  const newData = fetch(...);
  setData(newData);
};

return (
  <div>
    <Widget src="near/widget/ReallyComplexComponent" />

    <div>
      <p>Lots of JSX that renders {data}</p>
    </div>
  </div>
);

In the example above, the entire component and ReallyComplexComponent will have to re-render whenever setData() is called. If ReallyComplexComponent doesn't need access to data then we can refactor to reduce the impact of calling setData():

return (
  <div>
    <Widget src="near/widget/ReallyComplexComponent" />
    <Widget src="near/widget/DataComponent" />
  </div>
);

Then DataComponent would become:

const [data, setData] = useState({});

const loadData = () => {
  const newData = fetch(...);
  setData(newData);
};

return (
  <div>
    <p>Lots of JSX that renders {data}</p>
  </div>
);

This allows DataComponent to re-render as much as it needs to without impacting ReallyComplexComponent.

We can also utilize hooks like useMemo() and useCallback() in special scenarios as needed - though they should be used sparingly. Before reaching for those hooks, we should first see if we can simply restructure our existing component logic. Hooks like useMemo() and useCallback() can be helpful to reduce re-renders, but they also introduce a layer of complexity and potential for bugs. There's always a tradeoff. For more information on these two hooks, please give this a read: https://kentcdodds.com/blog/usememo-and-usecallback

Links Triggering Full Page Refresh

Our component gateway is rendered by a Next JS application. Next provides a Link component that implements an <a> tag. When clicked, it performs client side routing to avoid a full page refresh. This Link component is provided globally by the VM via customElements.

Whenever we need to render an anchor that links inside of our application, we should always use the <Link> component instead of rendering a standard <a> tag:

return (
  <p>
    Please click my <Link href="/near/widget/CoolPage">cool link!</Link>
  </p>
);

When you need to apply styles to the link, you can pass a className or use Styled Components:

const CoolLink = styled("Link")`
  color: red;
`;

return (
  <p>
    Please click my <CoolLink href="/near/widget/CoolPage">cool link!</CoolLink>
  </p>
);

The exception to this rule is when you need to link to an external website. In those cases, you can simply use a regular <a> tag since a full page refresh is necessary anyways:

return (
  <p>
    Please click my <a href="https://aurora.dev/start" target="_blank">cool link!</a>
  </p>
);

---

Wrap Up

Please feel free to ask questions, make suggestions, and add your own thoughts on anti-patterns we should watch out for. Thanks for reading!