Dominik Groński

Yes. A quote should carry a version and an expiry, and on acceptance you revalidate server-side. If the rules moved, show “quote expired” with the new total instead of silently recalculating. Silent recalculation is how you lose trust.

Good catch, that race is real. I abort the in-flight request on every change with AbortController and tag each response with the config it belongs to, so stale answers get dropped. Probably worth its own follow-up post.

Recompute on confirm is the key line. And pricing as data instead of deploys was half the reason I wrote this, good to hear it maps to real pain. No more Friday releases just to change a number.

Exactly this. “Treat the submitted number as untrusted” is the whole game. Keeping one public price for display is fine, the sin is letting that number decide what actually gets charged. Sounds like you landed in the right spot.

For a single product I honestly don’t bother being clever, recalculating the whole batch is cheap. With 40 or 120 louvers the JS loop is noise, the only real cost is the buffer re-upload when you flip instanceMatrix.needsUpdate, and that fires once no matter how many you touched. Your scale flips it though. 30 pergolas of static geometry shouldn’t get re-uploaded because one tilt slider moved, so I’d split it: static parts in their own InstancedMesh I write once and never touch, the animating louvers in a separate one so only that buffer goes up per frame. If you want to push it further, newer three.js lets you set updateRanges on the instance attribute and upload just the slice that changed instead of the whole thing. And yeah, you’re right about picking, the instanceId from the raycast maps back to the component through a lookup array I build when I place the instances, that’s what makes a clicked louver actually mean something.

Yeah, the way you’re testing it is basically what I landed on too. Cold cache, treat the first render and the first interaction as two separate things, and watch if anything new compiles when you poke it. That warm initial scene is exactly what fools you. The thing that unlocked it for me was realizing I was thinking about it wrong. I was trying to cover configurations and there are thousands of those. But the GPU doesn’t care about configurations, it cares about programs, and there’s only a handful. Twenty wood finishes that are all the same MeshStandardMaterial with a different texture are one program, not twenty. So I stopped enumerating configs and started enumerating the stuff that actually changes the shader: the material types I switch between, the lighting presets that change light count or the env map, and whether the post stack with bloom and tone mapping is on or off. That list is short. During the loading screen I just step through it, set each combo, call compileAsync. The one that bit me was the EffectComposer passes. renderer.compile doesn’t touch them, you have to actually render a frame through the composer with the passes enabled, otherwise they compile on the first interaction and you get exactly the hitch you’re describing. And to your real question, how do you know you covered them without brute forcing every config, I just watch renderer.info.programs.length. Warm up, then click around like an annoying user, switch finishes, flip lighting. If that number goes up, you missed one, add it. When it stops moving no matter what you click, you’re done. Never had to render the whole matrix. One more that caught me once, if you use onBeforeCompile or a custom cache key anywhere those are their own programs too, so they need to be in the warm-up or they’ll surprise you on first interaction.