Capture Frontend Logs & User Insights with Log Rocket

If you are running a web application, you will want to know if users are experiencing errors. You will want to gather logs and gather insights. There are many tools out that can help with this and today I’m going to show you LogRocket. I like LogRocket because it only takes a few lines to setup and you can have complete customizability.

Screenshot of Github Workflow Running

Setup

Sign up for an account. Most likely right away, you will probably be asked to create a new project. Give the project a name, and invite teammates. The important attribute will be the app id that Log Rocket provides you.

Vanilla JS

If you want to setup Log Rocket to be used with vanilla Javascript,:

<script src="https://cdn.lr-ingest.io/LogRocket.min.js" crossorigin="anonymous"></script>
<script>window.LogRocket && window.LogRocket.init('<YOUR_APP_ID>');</script>

That’s pretty much it to capture basic visitor data.

React

You can use the external script (like Vanilla JS) or install it with NPM.

npm i --save logrocket

For me, I’m going to place the setting of the app id in my &lt;App component. It loads on every page and wraps every page. Here is my React router:

ReactDOM.render(
  <React.StrictMode>
    <BrowserRouter>
      <App>
        <Switch>
          <Route exact path="/profile" component={Profile} />
          ...
        </Switch>
      </App>
    </BrowserRouter>
  </React.StrictMode>
)

I put the code in my ComponentWillMount:

import React, { Component } from 'react';
import LogRocket from 'logrocket';

class App extends Component {
  componentWillMount() {
    LogRocket.init('<YOUR_APP_ID>')
  }
  render() {
    ...
  }
}

Your React project is all setup.

Dashboard

I’m going to circle back to a more advance setup but I will walk through the dashboard. If you see this, you will have to navigate to your site. If you continue to see this, then you did not setup LogRocket correctly.

Screenshot of Github Workflow Running

Head to your site and click around.

Screenshot of Github Workflow Running

  1. In the top left corner, you can navigate multiple projects. This is the best way to also support multiple environments. For those with a QA or dev environment, its recommend so you don’t create errors and mistake them for production.
  2. The user is marked as anonymous. We have not setup any kind of identification method.
  3. You can click and view the users session. The play button will no longer be coloured if it has been seen.
  4. You can find all errors here. If a crash happens, it will captures the point of failure in the code, the logs, and the steps to reach that point.

Click on the actual event.

Screenshot of Github Workflow Running

To start off, I’m in the Developer view. I have circled it in the top right corner. 1. In the top left corner, you will see the current page they are on. 2. In the bottom left corner, you will find a play button and this will allow you play through your user actions. The bottom bar highlights the errors with red. 3. You can see their network requests. I switch my view to XHR. This allows you to understand what data is being sent to your servers and received from your servers. 4. This is a recreation of their DOM events. You are no recording their screen. This is a great way to get insights into user experiences. 5. This is their logs. It is also a great tool for debugging.

Levelling it

You can add a range of levels to LogRocket for it to capture different information. Each piece of the view above (a user’s session) can be turned off. Implementing a way for users to disable the level is important.

I recommend introducing:

  • Record Frontend Logging
  • Record Network calls
  • Record UI
  • Associate with User

You can change the naming. Record frontend logging would be the flag that allows you to capture at a minimum the logs. If it is turned off, Log Rocket is not even setup. Record network calls would be for capturing network calls. Record UI would capture DOM events to allow you to see what the user is doing. Associate with user would tie sessions to a user.

import React, { Component } from 'react'
import LogRocket from 'logrocket'

const LOG_ROCKET_PROJECT_ID = '<YOUR_PROJECT_ID>'

class App extends Component {
  constructor(props) {
    super(props)

    this.state = {
      user: null,
      recordUI: false,
    }
  }
  componentWillMount() {
    // TODO - Insert user fetch or pull from cookies
    const user = {
      email: "demo@keithweaver.ca",
      recordFrontendLogging: false,
      recordFrontendNetworkCalls: false,
      recordFrontendUI: false,
      associateFrontendLogsWithUser: false,
    }

    if (!user || !user.recordFrontendUI) {
      // Record nothing
      this.setState({
        recordUI: false,
      })
    } else {
      this.setState({
        recordUI: true,
      })
    }

    if (user && user.recordFrontendNetworkCalls) {
      LogRocket.init(LOG_ROCKET_PROJECT_ID, {
        network: {
          isEnabled: true,
        }
      })
    } else {
      LogRocket.init(LOG_ROCKET_PROJECT_ID, {
        network: {
          isEnabled: false,
        }
      })
    }

    if (user && user.associateFrontendLogsWithUser) {
      LogRocket.identify(user.email, {
        // Any additional fields
      })
    }
  }

  render() {
    const {
      children
    } = this.props
    const {
      user,
      recordUI,
    } = this.state

    if (!recordUI) {
      return (
        <div data-private>
          {children}
        </div>
      )
    }
    return (
      <div>
        {children}
      </div>
    )
  }
}

export default App;

Secrets

Secrets are the last portion to this. Password fields are never recorded. You can disable areas not to be recorded like this:

<div data-private>
  This data will <strong>not</strong> be recorded.
</div>

This is very specific on a per app basis. In the docs, they highlight how customize a lot of these tasks (Ex. Sanitize Network Requests with Secrets).

Conclusion

LogRocket can be very powerful. I recommend adding to gain better insights into your user’s experience and catching potential errors. As you become more confident, reduce down the permissions to record less. If you don’t need to know or need the data, don’t record it. You should also build a way for users to either opt-in/opt-out.