Hey, everybody. I have a sprawling application and need some advice. How to properly build the architecture of the application. Any good architecture building practices or project examples?
if you use react pair three to fiber GitHub - pmndrs/react-three-fiber: 🇨🇭 A React renderer for Three.js you now can build your app with the same component patterns you already know, the same state model, reactivity, context, suspense, error boundaries and so on. you want encapsulate logic and make it self-contained and re-usable. going further you can consider also extending these principles to your models and assets, for instance GitHub - pmndrs/gltfjsx: 🎮 Turns GLTFs into JSX components
you find lots of examples with good structure here Examples - React Three Fiber
the best advice i’ve found over the years is that applications revolve around state. your state flows top down, the app is merely the reflection of state. if state changes, so will your app. you don’t cross boundaries, reach internals up, traverse, mutate indiscriminately, etc. you will end up with clean architecture.
1 Like
And if you don’t use React Three Fiber?
that would not make any sense. it would be the same as using querySelectors and domnode.addChild in a part of your react app. you would be mixing imperative three with declarative three and thereby loose all the benefits of react, reactivity, shared state, context, suspense and components. components especially are what give your app structure.
fiber is a react renderer just like react-dom. it does not wrap or bind three. it does not require updates when three changes. it has no limits or regressions. it’s a small form that tells react about three semantics. it is fundamentally what react was made for: express imperative platforms declaratively.
it is a difficult and complex topic
but i agree with paul that r3f is the way to go.
App architecture will vary from project to project - and always be changing as the project involves.
IMO, a lot of r3f projects will always have
export type Project = {
id: string;
title: string;
scene: SceneElements;
unsavedChanges?: boolean;
};
Then, each item on the scene would almost always have
export type BlueprintItem = {
id: string;
type: ItemType;
position: [number, number, number];
scale: [number, number, number];
rotation: [number, number, number];
};
Then, you would pass child data types as needed.
IMO it is a complex topic and rarely discussed in the 3js community, because most people are making websites, and fewer are making webapps.
For me, the right app architecture is not possible to fully predict from the start, nor get 100% correct.
Even if you make a mistake, you can fix people’s save files or use versioning.
I would just start and let the architecture develop naturally.
If you are using a traditional JavaScript framework (React, Vue, Angular, Svelte, …) then this will affect the type of architecture you’ll have in significant ways, as described above: using React would generally imply you should strongly consider React Three Fiber.
If you’re not using such a framework, you might consider patterns like ECS, coroutines, model-view-controller, etc.
If you’re not sure about a framework, or even if you are — the question of architecture also depends heavily on whether you’re building a game, a 3D-centric application (like a CAD tool), something that behaves more like a website or web application, etc. And then, is there a server-side component? Multiplayer? Realtime collaboration? Persistence?
three.js is primarily a rendering layer; the choice to use three.js should not determine your architecture, the type of application you’re building should, instead.
1 Like