Discussion: Improvement on `Utility` documentation

[Justin McMurdie]

I've been spending some time explaining single-spa to people at Workfront and I've some potential areas for improvement in the documentation around utilities. There has been a decent amount of confusion around this point in the documentation.

Right now we describe a utility as something with no routes, no single-spa api, that doesn't directly render ui, and has no lifecycles.

I'm wondering if it would be better to describe it as: "An external javascript module that implements one or more aspects of a shared context outside of single-spa, but accessible to single-spa applications."

In our recommended approach a Utility has no direct interface with single-spa. It's just a singleton js module that exports methods that can be used by single-spa applications/parcels through SystemJS. A few examples of utilities at Canopy that would be in violation of how we describe them in the documentation:

1. toast-service: it directly renders ui, IIRC it isn't even initialized by the root-config it initializes itself when it is imported.
2. sentry-error-logging-ui: this has lifecycles, but the lifecycles don't match the normal single-spa lifecycles because it doesn't have it's own UI, but it does have a conceptual bootstrap lifecycle.
3. feature-toggles-ui: Before leaving canopy we added some features to this around users being able to temporarily opt-out of feature-toggles and it had ui.

I'm hoping we can have a discussion about this because I'm not sure how to describe a utility as an external js module without leading to more confusion.

[Joel Denning]

Sure I'm open to reworking the languaging to clarify