If I understand correctly from this post the purpose of the name field in constructors and factories is not essential to the operation of the engine, but the field is currently marked as required.
As the API was written with positional arguments we can just throw a null! in there and ignore the orange squigglies, but it feels silly in some cases. For instance react-babylonjs uses codegen to create components and sees name as a required field.
//bearable, required due to positional arguments
MeshBuilder.CreateBox(null!, {size:2})
//writing code just to satisfy typescript
new StandardMaterial(null!)
//react-babylonjs can't tell its optional
<transformNode name={null!}/>
One could argue that not adding a name is an anti-pattern but I have been using the engine for years and have not come across a reason to use the field, instead using variable names for readability and source maps for debugging.
I’m interested to hear everyone’s thoughts, are there others who don’t use this feature?
That would be easy to address in react-babylonjs without changes to babylonj.s. In your example the constructor for TransformNode is actually (name: string, scene: Scene). The scene is put in there automatically by the renderer and not required. Others constructors are more involved like a shadow caster will have a deferred instantiation and will look for an appropriate light source in the tree graph (same nested branch). In the codegen the Scene was made not required despite the babylonj.js typings. The typings for the JSX are in IntrinsicElements and separate from the babylonj.js typings.
About the name parameter though - besides it being quite helpful in the Scene Inspector - I do recall that I had an issue with not supplying name props throwing errors somewhere, but I can’t think of what it was at the moment - oops. time.