SolidJS•3mo ago

solid-plotly.js a new wrapper for Plotly.js

I could use some more experienced eyes to check the SolidJS implementation details. Eventually I'd like to get this into the official plotly.js distributions. https://github.com/ralphsmith80/solid-plotly.js/tree/main I've posted on there support forum about that as well. https://community.plotly.com/t/solidjs-version-of-plotly-could-use-some-eyeballs/87761

I want to use Plotly with SolidJS. The closest match would be React, but they’re fundamentally different. I used the React project to build a similar wrapper using SolidJS. ralphsmith80/solid-plotly.js: A plotly.js SolidJS component from Plotly (github.com) It’s a monorepo using pnpm. The solid-plotly.js packages is under packages and the demo app is under apps. I’d like to see about getting this included into the available plotly packages. I could use some eyes on the project and there’s still some work around testing and documentation that needs to be done. In particular I’m struggling to get the same tests working that are in the react repository. The differences revolve around the expectPlotlyAPICall test function and I’m sure it’s related to the fact that I wrote the solidjs version using TS which I’m not very good at yet. For docs the README pages need to be updated.

GitHub

GitHub - ralphsmith80/solid-plotly.js: A plotly.js SolidJS componen...

A plotly.js SolidJS component from Plotly. Contribute to ralphsmith80/solid-plotly.js development by creating an account on GitHub.

Plotly Community Forum

SolidJS version of Plotly - Could use some eyeballs

I want to use Plotly with SolidJS. The closest match would be React, but they’re fundamentally different. I used the React project to build a similar wrapper using SolidJS. ralphsmith80/solid-plotly.js: A plotly.js SolidJS component from Plotly (github.com) It’s a monorepo using pnpm. The solid-plotly.js packages is under packages and the demo...

53 Replies

bigmistqke•3mo ago

i had a quick look at it, i don't know plotly and haven't run your code so take my words with a grain of salt. code looks pretty good, don't see any immediate big issue. some suggestions: - you have a lot of el?. type code and have even a check at some point where you throw. if you don't want to have code run that depends on el you could either add that code in an onMount and just null assert, or what I like to do sometimes is to pass a function to ref like this - you are manually diffing the event-listeners with syncEventListeners, maybe this could be written more declaratively, like this. with your method you have more control over when exactly the event listeners are added tho.

Solid Playground

Quickly discover what the solid compiler will generate from your JSX template

Solid Playground

Quickly discover what the solid compiler will generate from your JSX template

bigmistqke•3mo ago

last point also counts for syncWindowResize o also

createEffect(() => {
      const { data, layout, config, frames, revision } = props;
      let prevFramesLength = frames?.length ?? 0;

    return () => {
      const numNextFrames = frames?.length ?? 0;
      const figureChanged =
        data !== props.data ||
        layout !== props.layout ||
        config !== props.config ||
        numNextFrames !== prevFramesLength;
      const revisionDefined = revision !== undefined;
      const revisionChanged = revision !== props.revision;

      if (figureChanged || (revisionDefined && revisionChanged)) {
        prevFramesLength = numNextFrames;
        updatePlotly(false, props.onUpdate, false);
      }
    };
  });

createEffect(() => {
      const { data, layout, config, frames, revision } = props;
      let prevFramesLength = frames?.length ?? 0;

    return () => {
      const numNextFrames = frames?.length ?? 0;
      const figureChanged =
        data !== props.data ||
        layout !== props.layout ||
        config !== props.config ||
        numNextFrames !== prevFramesLength;
      const revisionDefined = revision !== undefined;
      const revisionChanged = revision !== props.revision;

      if (figureChanged || (revisionDefined && revisionChanged)) {
        prevFramesLength = numNextFrames;
        updatePlotly(false, props.onUpdate, false);
      }
    };
  });

returning a callback in an effect in solidjs is not a cleanup-function, you should use onCleanup for that instead. not super sure what the intention is of that code ye that code looks pretty fishy

agentsmithOP•2mo ago

Thanks! I tried to keep it as close to the React implementation as possible because I thought it might have a better chance of getting into the main project. And secondly I didn't want to spend a lot of time on it. Good catch on the clean up code. I'll see if there's something to be done there. That looks like a fundamentally wrong aspect for solidjs. I had to make some updates based on the info that @bigmistqke pointed out, but have been using the library without issue for a couple of weeks now. I ran into some issues with the built version that I didn't see in the test app within the monorepo for the library. I thought it might be related to pnpm linking and I published a few alpha versions to npm while testing. Ultimately I ended making two changes to get this working for running the dev server, local built server, and via npm package. 1. replacing import Plotly from 'plotly.js/dist/plotly' with import Plotly from 'plotly.js-dist-min' in the index.tsx 2. Add a single tick delay (await new Promise(resolve => setTimeout(resolve, 0))) in the factory when updating Plolty in factory.tsx (2) seems like a bad solution, but I couldn't figure out why el was undefined in this context since it's a reference and the first invocation is from the onMount lifecycle method which happens once all initial rendering is done per the docs.

<div
  id={props.divId}
  style={props.style}
  ref={elRef => {
    el = elRef as unknown as PlotlyHTMLElementWithListener
  }}
  class={props.class}
/>

<div
  id={props.divId}
  style={props.style}
  ref={elRef => {
    el = elRef as unknown as PlotlyHTMLElementWithListener
  }}
  class={props.class}
/>

It seems that in some contexts (non-dev env) there is a single tick delay between mounting/rendering and when el is set based on the reference.

Refs can also take the form of a callback function.

Maybe it would be better for the initial updatePlotly call to be done in the ref function than in onMount. 🤔 testing ....

agentsmithOP•2mo ago

Based on the logs being printed it looks like it is possible for onMount to be called before the ref function has fired.

agentsmithOP•2mo ago

This doesn't happen in the monorepo test app and Plotly throws an internal error if I try to to invoke it from the ref function in the case when the ref function fires before onMount even though the element is present. GPT suggest a solution like this which I expect should work and will be more robust than a single tick await, but it's still icky.

const retryUpdatePlotly = () => {
  if (el) {
    updatePlotly(true, props.onInitialized, true)
  } else {
    setTimeout(retryUpdatePlotly, 0) // Retry after 1 tick
  }
}

onMount(() => {
  console.log('####solid-plotly on mount:')
  retryUpdatePlotly()
})

const retryUpdatePlotly = () => {
  if (el) {
    updatePlotly(true, props.onInitialized, true)
  } else {
    setTimeout(retryUpdatePlotly, 0) // Retry after 1 tick
  }
}

onMount(() => {
  console.log('####solid-plotly on mount:')
  retryUpdatePlotly()
})

Any other ideas on how to handle this? Maybe el can be a signal.

Gaming

Programming

solid-plotly.js a new wrapper for Plotly.js