I wrote the underlying 3D library, but React isn't my specialty, so I don't know if this is deemed best practice. Seems to work though and is nice and extensible, allowing the API to be proxied if and when the component changes
Oh boy, this brings back some fond memories from around 2013-2015.
Around that time I wrote very similar 3D map library (using three.js and cdlod-type approach for terrain rendering) and created custom AngularJS directives for similar purposes like your React library.
Sadly, my code was closed source and the startup I was working in went bankcrupt and my code went with it.
I don't mean to pick on you here, but seems to work is about the best anybody can do these days when talking about Javascript libraries. It's a little depressing at times.
Does this always work, or is there a better way now? It’s been a little while since I used React, but I remember being confused about how a canvas that needs to retain state was supposed to be handled in React. At the time it seemed to me like React wasn’t designed to handle WebGL.
It's always worked. The way to do it with function based components is slightly different but the effect is the same. But this class based component method has worked forever.
I think people think because they are using React it's horrible if they let something else change the DOM. But in reality I do this all the time with D3. Yes you can render SVG with React and get it to work with D3 that way. But honestly I found it a lot cleaner to just let D3 takeover the rendering. This let me work directly from samples on the web without much translating to get it to work in React.
It seems to be a nice little trick to translate state from the React lifecycle to a non-React library.