Headless React

Most importantly there is working code if you actually click on the links. I didn’t at first and missed it because it’s not obvious which are crucial to click on. Here it is: https://gitlab.com/unconed/use.gpu

Post #2 about “data flow graphs (DFGs)” and post #3’s brief treatment of the double-tree sowing and reaping thing might be easier to understand if you have watched this talk about Jane Street’s Incremental, specifically how the various iterations address the dynamic complexity introduced by the `bind` function:

https://www.youtube.com/watch?v=G6a5G5i4gQU

The whiteboard drawings there are fantastic. Yaron starts very near zero and builds steadily from there. Acko’s posts start at 900 in about five different domains and zoom to 4900 in each. Of course at 4900 you have a pretty cool and way out of my league declarative and reactive GPU render pipeline but maybe slow down for us a bit!

The effect system described in the first post immediately reminded me of re-frame, a Clojurescript library that uses React under the hood. I don’t know how similar this flow is to that, but they share the key axiom that “declaring an effect should be orthogonal to running it.”

I kind of hate generators, so I’m deferring the rest of the article/series until I’m not heat-angry and can read it more in the spirit of curiosity =)

This should be React's tagline.

Once you see React this way, it becomes a tool to design an application architecture rather than just a UI library. The hierarchical nature of React makes it easy to picture the ownership and lifetime of a state.

I'm wondering if Headless React can be used, for example, as a side-loaded app to control systems in ECS in plug-and-play manner.

Think about HTML and Images. Image tags `<img>` live inside the DOM tree but the image itself, the actual pixels, are referenced only by name and those resources are managed outside of React. From React's POV doesn't know about the actual images. It only knows about these HTML tags called `<img>` that are references to the actual image. Two or more img tags can reference the same image by using the same src and something outside of react loads, frees, and otherwise deals with them.

In 3D you have the same problem a geometry, or mesh-data, like a cube or human, might be referenced 2 or more times. If you want to cover a globe with cubes you might have 1000 cubes. But, like an image, all you want is references to a single cube and that single cube, following React's example with HTML, would live outside of React. It can't be part of the DOM hierarchy because it doesn't fit the definition of "hierarchy". Its references do but its data does not.

The same with materials. In React, if you want 2 elements to share a style you use className="nameOfStyle" and the actual style lives outside of React in CSS. You have the same issue with materials in 3D. You might want 247 of your 1k cubes above all to share the same material as they represent the same area so that you can highlight them collectively, but now you're creating something that doesn't live in a tree, just like in className="nameOfStyle", nameOfStyle doesn't live in the tree.

I'm not saying they're aren't solution, just that off the top of my head, declaring <Scene><Cube/><Cube/><Cube/></Scene> is wrong. It should be <Scene><Renderable geo="cube"><Renderable geo="cube"><Renderable geo="cube"></Scene> and now you're left figuring out how to declare what the string "cube" represents but it will look nothing like React JSX. I get that react-three-fiber does the former but it's arguably wrong as it's pretending something is a hierarchy that's not a hierarchy. See the image example above.

Well - using ".then()" is the proper way of doing things. Just add do-notation and you are good.

Maybe eventually the javascript community will catch up :^)