Recreating the Chrome Console in React – LogRocket

  • Since a session could potentially have thousands of logs, we knew that we’d need to build a virtual list where DOM nodes are unmounted when they leave the viewport.User-interactive JSON treeExpanding objects in the Chrome ConsoleLike the Chrome javascript console, users should be able to expand objects that were logged.
  • Simply knowing the length of the list and having a rowRenderer function that can render a given row is all it needs!Our ImplementationI’m not going to describe every detail of our console implementation since much of it is a standard application of react-virtualized, but there are a few bits where we diverged that are interesting.Row HeightsAs I described earlier, react-virtualized takes a prop rowHeight which is a function that returns the height of a row at a given index.In this screenshot of the LogRocket log viewer, notice that there are 2 states for each row: default, and expanded.
  • However, when a row is expanded, its height varies as the user expands different subtrees of the object.We needed a way to write a rowHeight function that handles dynamic height rows- something like this:In order to implement getExpandedRowHeight in the above psuedo-code, there were two potential options.Guarantee deterministic height of an expanded objectTo achieve this, we would have needed to design the object tree view component from the ground up to make its height a pure function of the subtrees that are expanded.
  • Also, making this guarantee would make it difficult to iterate on the look and feel of the log viewer since changes to things like margins and padding would need to be adjusted for.Use react-measureInstead, we opted to use a library called react-measure which provides a helpful abstraction for writing components that are aware of their own height.react-measure wraps a given component and takes a prop, onResize which is a function that is called whenever the component’s size changes.In our case, whenever the size of a given row changes, we dispatch a Redux action which stores the height of that row in Redux.
  • Then in our rowHeight function, we simply get the height of the row from Redux, and react-virtualized can render it properly.There is a small performance penalty to this approach, since react-measure uses the DOM resize-observer API which isn’t implemented natively in all browsers, but in practice this is fairly minimal.Apollo ClientTo handle data fetching, we use apollo-client which is a GraphQL client that works nicely in React apps.

One of the core features of LogRocket is the replay of console and Redux logs in production web apps. To do this, you add the LogRocket SDK to your app which sends logs to LogRocket. Then, when…

@LogRocketJS: Recreating the Chrome Console in React using react-virtualized @brian_d_vaughn #ReactJS #Redux

One of the core features of LogRocket is the replay of console and Redux logs in production web apps. To do this, you add the LogRocket SDK to your app which sends logs to LogRocket. Then, when triaging a bug or user issue, you can replay the logs in LogRocket to see what went wrong.

When we first designed the log viewer, we went through a number of design iterations, but eventually settled on replicating the look and feel of the Chrome console. After all, developers are already used to working with this interface, so why reinvent the wheel?

to build a performant and maintainable log viewer.

The high-level design concerns for our log viewer were as follows:

Smooth scroll performance

Building a long list that scrolls smoothly isn’t trivial, but it’s crucial for a pleasant user experience. Since a session could potentially have thousands of logs, we knew that we’d need to build a virtual list where DOM nodes are unmounted when they leave the viewport.

Like the Chrome javascript console, users should be able to expand objects that were logged. This was an important interaction to get right since developers are used to the mechanics of the Chrome console.

API, LogRocket makes it possible to log anything in JavaScript. This means that we needed to support arbitrarily large objects or arrays. It was clear that we couldn’t load all of a session’s logs at once, since this query could be massive. Instead, we have to load log data on demand when a user expands a log entry.

This is a departure from how the Chrome console works (where all data is already in memory), which meant that we would need a loading state and error handling for failed queries.

The state of the log viewer should be persisted when the component unmounts and re-mounts. Basically, the state can’t be kept at the component level and should be stored in Redux.

When rendering a very long list, it is often prohibitively expensive to keep all items in the DOM, since each node requires a fixed amount of memory. To solve this problem, you can build a virtual list, where each item is only rendered when it is actually visible.

. It provides a host of utility components for building virtual lists, grids, and tables. It has an active community of contributors and a slack group that is very helpful for discussing issues.

bypasses the browser’s layout engine to determine where to arrange items. As you scroll through a list, it looks at the current scroll position, and determines which items are in the viewport. It then renders those items, and uses absolute positioning to place each row in the correct place. As such, it can freely mount and unmount rows without affecting the positioning of subsequent rows.

positioning of subsequent items.

component:

width, height

needs to know the width and height of the list viewport in order to do its calculations. If your list isn’t fixed in width or height, there are helper components for hydrating these values.

rowCount

The number of rows in the list.

rowHeight

If all rows in the list have a fixed height, this value can be a number. If the height of each row is different, rowHeight can be a function which returns the height of a given row by index. More on this later.

rowRenderer

(and some other non-essential props) and returns the row to render. A simple implementation might look like this:

function that can render a given row is all it needs!

, but there are a few bits where we diverged that are interesting.

which is a function that returns the height of a row at a given index.

tall. However, when a row is expanded, its height varies as the user expands different subtrees of the object.

function that handles dynamic height rows- something like this:

in the above psuedo-code, there were two potential options.

Guarantee deterministic height of an expanded object

To achieve this, we would have needed to design the object tree view component from the ground up to make its height a pure function of the subtrees that are expanded. Put another way, we could write a function that takes in a list of the expanded subtrees in an object, and have it return the height.

In theory this is doable, but there are number of complications. It is difficult to account for text that overflows to the next line, as this increases the height of the object. Also, making this guarantee would make it difficult to iterate on the look and feel of the log viewer since changes to things like margins and padding would need to be adjusted for.

which provides a helpful abstraction for writing components that are aware of their own height.

which is a function that is called whenever the component’s size changes.

can render it properly.

uses the DOM resize-observer API which isn’t implemented natively in all browsers, but in practice this is fairly minimal.

which is a GraphQL client that works nicely in React apps. When a user clicks on a log entry to see the full object, the log entry goes into a loading state which has a fixed height.

to update and the row height changes when the data is filled in.

. This library includes a host of components for logging objects and DOM nodes. We did, however, end up forking the library in order to build a controlled version (so we could keep state in Redux).

LogRocket is a frontend logging tool that lets you replay problems as if they happened in your own browser. Instead of guessing why errors happen, or asking users for screenshots and log dumps, LogRocket lets you replay the session to quickly understand what went wrong. It works perfectly with any app, regardless of framework, and has plugins to log additional context from Redux, Vuex, and @ngrx/store.

Recreating the Chrome Console in React – LogRocket