Couple friction points I have had with Perspective 3 early lifecycle tasks in the browser

[brianblakely]

Putting this out as a discussion to correct my understanding, or see if these may potentially be issues worth addressing.

1. As part of Perspective's initialization process, the perspective-viewer custom element gets registered. However, if multiple sources are initializing Perspective (say, an app which displays viewers and a library which fetches data and creates tables), this will throw because an element can only be registered once in a single page session. Currently, the workaround for this is to always check for the element's registration status before attempting to initialize Perspective, but this is still imperfect. I believe it would be more resilient if Perspective initialization was idempotent, as it pertains to tasks which are intended to affect global state.
2. Creating a Perspective Table appears to always require a <perspective-viewer> already present in the DOM, even if that viewer won't be used to load said table. Usually, I don't need a viewer until I already have a table to render, so right now I must create a dummy viewer just to satisfy that requirement. Is there a "headless" way to accomplish table creation?

[texodus]

However, if multiple sources are initializing Perspective (say, an app which displays viewers and a library which fetches data and creates tables)

Don't re-evaluate JavaScript modules. It is CPU expensive at runtime, wastes memory, and will functionally break any library that has state.

The only way a JavaScript module even can be evaluated more than once, is if you've misconfigured your bundler or intentionally re-loaded the module dynamically. Either way, this is an issue with your application architecture, not Perspective.

Creating a Perspective Table appears to always require a <perspective-viewer> already present in the DOM

No, you have misconfigured your bundler. Bundler docs and similar question previously.

To re-iterate what I told you at Prospective Office Hours last week: the tenor of your questions indicate some systemic design issues with your application overall. If you cannot share your implementation or a repro with us, you're not going to get much help here.

[brianblakely]

If that was your impression, it was lost on me. 😄

I'll try to get you an example of what I'm seeing. Just using the default Next.js config and Perspective's build guide, boilerplate stuff.

[texodus]

We're unable to help you with this. next.js is a server-side rendering framework, it's at best a poor design choice for Perspective and quite non-trivial and application context dependent to implement correctly.

If you are required to use this framework due to e.g. your Enterprise environment - this is not an issue for Open Source.