Define role and name for the `WebGLPreview` class

[sophiedeziel]

The WebGLPreview used to be the god class that handled everything. Now that we've extracted a ton of responsibilities out of it, maybe it's time to give it a new name that actually represents what it does (and decide what it should not do).

We are referring to it as the renderer, but it does much more than rendering. There's some code that is pretty easy to extract out because it just does not belong there anymore (drag and drop for example). But it's at the same time a parsing interface, an object builder, an animator, an options manager, and a three.js scene manager.

If we extract out everything but the object building and the three.js scene managing, we're in a very good spot. I would refrain from separating the two too early though because rendering modes will give us plenty of insights on how to get it right. For names, I think it's too early to call it a renderer because of rendering modes. They will probably need a whole new definition of what a renderer is as opposed to what we have right now. Previewer sounds right to me. SceneManager too.

I like to ask ChatGPT for naming ideas. Here's what it came up with:

It sounds like you're looking for a name that reflects the core responsibilities of the class without prematurely locking it into a narrow role like "renderer." Given that it's involved in object building, scene management, parsing, and animation, but you're stripping away certain non-core functions like drag-and-drop, here are a few name suggestions that could fit its role:

1. ScenePreviewer – Combines both the idea of scene management and previewing, acknowledging the class's wider role without narrowing it down to just rendering.

2. VisualComposer – Emphasizes its role in assembling and managing 3D objects and scenes, with "composer" hinting at its role in organizing elements.

3. SceneOrchestrator – A slightly more sophisticated term, implying the coordination of different elements within a scene, including objects, animations, and rendering modes.

4. ObjectManager – If the focus is more on the management of 3D objects within the scene (after other responsibilities are stripped out), this could work.

5. StageDirector – Implies a more dynamic role, orchestrating how objects and scenes come together, while allowing room for future functionalities like different rendering modes.

6. SceneAssembler – Suggests that the class is responsible for assembling and managing the scene components, leaving room for future refinements as more tasks are extracted.

7. Visualizer – This name is abstract enough to allow for both scene management and rendering without tying it down to any one function too early.

8. SceneArchitect – If you want to imply that this class is responsible for designing and structuring the scenes, this could be fitting.

Since rendering modes will impact the definition of a renderer later, these names aim to remain flexible enough to evolve with the project. What do you think of these options?

I kinda like VisualComposer and SceneAssembler.

[remcoder]

Nice! We might also separate the scene building from drawing the model. I'm fact, multi-gcode will require it.

[remcoder]

Honestly, isn't 'defining and naming class' something that is the result of our work? Not the start of it. I'd say this will fall into place during the refactor and we might change the name a few times or even replace/remove it completely. I'm not married to WebGlPreview at all 😉

[sophiedeziel]

Honestly, isn't 'defining and naming class' something that is the result of our work? Not the start of it.

Yes and no. It's a different approach of designing systems and primitives and it depends on your definition of "our work". In our case, it's actually the result because the code is there! But I'm questioning if the concepts implemented are cohesive or too much coupled. Trying to name them is a way to get some clarity. If we can name the different components easily, it's because the system makes sense. And we'll have an easier time defining the boundaries and APIs.

"our work" may also mean an exercise like event storming, if no code is written yet. That can help identifying what primitives need to be built and we can name them before the actual implementation.