This is part 3 of a 3 part series. If you’re confused, start at #1, but even then it moves very quickly through a mountain of content, with some assumed familiarity with some aspects of graphics programming in #3. Detailed knowledge about how React fiber works is a mandatory prerequisite and it would help if the posts told you what you were expected to know first.<p>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: <a href="https://gitlab.com/unconed/use.gpu" rel="nofollow">https://gitlab.com/unconed/use.gpu</a><p>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:<p><a href="https://www.youtube.com/watch?v=G6a5G5i4gQU" rel="nofollow">https://www.youtube.com/watch?v=G6a5G5i4gQU</a><p>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!
Hot (uninformed) take:<p>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.”<p>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 =)
From a quick skim and from a few Google searches I cannot find a definition of "headless React". The first sentence in this post already assumes you know what it means, as do most other sites I can find that mention it. Can anyone enlighten me?
Acko is back (not that they went anywhere, just excited to see it on HN)! This is one of my favorite personal tech blogs of all time, so many cool easter eggs and animation gems hidden in there. I especially love the Winamp visualizer projects and inspirations you can find sprinkled throughout.
> The main thing something like React provides is a universal power tool for turning things off and on again: expansion, memoization and reconciliation of effects.<p>This should be React's tagline.<p>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.<p>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.
It seems like a mis-match to me to try to use React for 3D. Like if all you have is a hammer than everything is a nail. 3D is not a tree, only the scene graph is, geometry and materials are not leaf nodes.<p>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.<p>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.<p>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.<p>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.
> So for now I have to write my code in the promise.then(…) style instead of using a proper yield.<p>Well - using ".then()" <i>is</i> the proper way of doing things. Just add do-notation and you are good.<p>Maybe eventually the javascript community will catch up :^)