Design spec (classes, methods, etc)

Design API
#1

I updated the class-list, and also put a possible file hierarchy there.

Let’s try and come up with as much desired API as we can, and build top down? It may be impossible to fully predict what we want, but we already do have an idea from Famous oh-three and Engine.

I think what we should do is all work together to finish our ideal design spec over at infamous/requirements and then continue building our prototypes based on that spec (but not necessarily strictly following the spec), then after that we can decide on our merge plan.

The reason we don’t have to stricly follow the spec is because in making our prototypes we might discover we want to do something differently, and we can present our reasoning for that when we are ready to discuss our merge plan.

What is the merge game plan?
#2

So, instead of putting base classes in core, I’m grouping them with their child classes, which I think makes more sense in the file structure. So in the components folder there’s a NodeComponent class a well as extending classes. The Node class is in the nodes folder along with Scene (assuming Scene extends Node, which I’m not entirely sure of yet). I didn’t know how to group the Motor/Engine class, so I left that in core. Renderers, including the base RendererInterface class are in the renderers folder. ThreeCSS3DRendererAdapter is an adapter that extends RendererInterface. I did similar with TransitionableInterface and TweenJsTransitionableAdapter in the animations folder.

We could probably move the transitionables into a transitionables sub-folder since the animation folder might contain other things like a Timeline class, etc. Any thoughts?

#3

Alright, in order to maintain the simplest, cleanest API for end users, I think we should have build time options with hand picked defaults. If we’re going to use Three.js or Tween.js, etc, then we should pick the default libraries we’d like our classes to use, and those will be default for most people. Advanced users can change libraries using special build options, and we’ll document how to make these build time plugins (they should be compatible with all our supported build systems).

This will prevent from users having to pick between things like ThreeJsRenderer and BabylonJsRenderer in their code. Instead, they can just always use WebGLRenderer, and by default that will be Three.js (or something). This is the best way to do it without introducing runtime performance hits by loading libraries at runtime and without making the user pick certain class names (the API just needs to work without them worrying about it).

This would be a kind of big endeavor, I think it’ll come later. For now, if I use any 3r party library like Tween.js, I’m going to make sure that the adapter used around it is clearly defined so that it is easy to swap Tween.js with something else.