Add ability to get status

[amcdnl]

It would be ideal if a user could determine the status of the FS system. For example, I want to attach the fullstory url to my headers but I have no idea if FS is init'ed before I can do so.

import * as FullStory from '@fullstory/browser';

try {
    operation.setContext(({ headers = {} }) => ({
      headers: {
        ...headers,
        'x-fullstory-url': FullStory.getCurrentSessionURL(true)
      }
    }));
  } catch {
    /* noop */
  }

As a result I have to wrap it in a try catch. A simple flag like:

Fullstory.status === 'ok'

Would be awesome. I would make a string rather than boolean so you could add things like not consented/etc.

[patrick-fs]

Hey @amcdnl thanks for the feedback! We've been discussing adding some kind of lifecycle event concept to the recording process.

would something like

FullStory.ready(({ sessionUrl }) => {
  operation.setContext(({ headers = {} }) => ({
      headers: {
        ...headers,
        'x-fullstory-url': sessionUrl
      }
    }));
})

Work for you?

[amcdnl]

The event hook is nice. I would make it a bit more generic like:

Fullstory.on('ready' or 'fail' / etc, fn);

and use something like: https://www.npmjs.com/package/event-emitter under the hood.

Though I would NOT prefer that in this case since hook is used on every API request thus the handlers would be annoying - here i would prefer a simple flag.

[patrick-fs]

Though I would NOT prefer that in this case since hook is used on every API request thus the handlers would be annoying - here i would prefer a simple flag.

With Fullstory.status === 'ok': are there situations where you'd be ok skipping some operation if ``Fullstory.status !== 'ok'`

or would you poll status until Fullstory.status === 'ok' to ensure the operation always runs?

[amcdnl]

I would be skipping - sometimes it would never be ready if they block FS or things need to happen way before the app is init'd

[amcdnl]

This is kind of tied to this issue too: https://github.com/fullstorydev/fullstory-browser-sdk/issues/76

[patrick-fs]

Hey @amcdnl There is a way to get the check you want, but it isn't explicit in the API. If FullStory isn't ready, then FullStory.getCurrentSessionURL(true) (or FullStory.getCurrentSessionURL()) will return null - otherwise the functions return a string (the URL value).

Can you use this logic as a proxy for Fullstory.status === 'ok'?

[amcdnl]

Last time I tried this it threw an error.

[patrick-fs]

Last time I tried this it threw an error.

In the non-npm FullStory library (i.e. the snippet tag), getCurrentSessionURL isn't defined until the FullStory recorder is fully bootstrapped, so you would get a reference error if you tried to call the function too early. However, in the npm-distributed package, we added a guard wrapper that will return null in this case: https://github.com/fullstorydev/fullstory-browser-sdk/blob/master/src/index.js#L17

When you got the error, were you using the @fullstory/browser-sdk package? (if so, what error did you receive?)

[parifuture]

@patrick-fs I tried the way you described.

import * as FullStory from '@fullstory/browser';
import { isString } from 'lodash-es';

if (isString(FullStory.getCurrentSessionURL())) {
    FullStory.identify(`${user.principalId}`, {
      displayName: `WorkPLACE: ${user.id}`,
      role: user.primaryRole,
    });
  }

And got the following error.

Uncaught Error: FullStory is not loaded, please ensure the init function is invoked before calling FullStory API functions at ensureSnippetLoaded (index.esm.js:114) at hasFullStoryWithFunction (index.esm.js:119) at Module.<anonymous> (index.esm.js:138) at HTMLUnknownElement.callCallback (react-dom.development.js:188) at Object.invokeGuardedCallbackDev (react-dom.development.js:237)

[luser]

I hadn't looked through the full backlog of issues here, but I just filed #138 which should cover this use case.

The event hook is nice. I would make it a bit more generic like:

Thanks for the feedback! We actually have in-progress work on a redesigned API to the capture script, and one piece of that work is similar to what you've described. In the near future I'm going to add contribution guidelines to this repository to help clarify what types of changes we can make here. Changes to the FullStory web capture API itself are not in scope, but we can communicate them to the team responsible. You can also raise issues like this with FullStory's Customer Support team, which is helpful because customer feedback informs our engineering teams' prioritization.