Improve the way custom shapes are instantiated

[ghost]

Currently the only way to use custom graphics is to customize a graphics class and inherit the mojs.CustomShape class, and then add it to mojs using the mojs.addShape() method. Then you can set and use custom graphics in the shape attribute.

One disadvantage of this method is that the added custom graphics class is global, and sometimes the added custom graphics will only be used in a certain module. My feeling is'this pollutes the global attributes'. For example, I want to use custom graphics menu and close in the Menu component. But in other components, I don't want to use the two custom graphics menu and close.

So one way I recommend is to support the use of the class type attribute value for the shape attribute. e.g. new mojs.Shape({ shape: MyCustomShapeClass })

Of course, my thinking is not complete, because I don't know much about the source code of mojs, and there is a better way that would be better. Hope Add support for modular use of custom graphics

[Sandstedt]

You can always separate your custom class with a separate name, but I understand your point.

I guess the philosophy here is that mojs is a library, and that you can extend the library with your own shapes. It's not mean to be used as a way of animating a single SVG, rather create animated interactive illustrations build by different shapes. If you just want to animate a hamburger icon from an open to a close state, I would use CSS animation and transitions, or a dedicated UI animations library, like Popmotion (understand it's just an example, but still).

Note that you can always change properties in a shape, like color, line-width etc directly from mojs, without to create a new custom shape.

What's your thoughts on this @xavierfoucrier? Maybe we could have both a global shape delcaration and a local one? (I also need to dig into the core of the custom Shape generation to see if it would be a big hassle to fix that)

[xavierfoucrier]

Hi all,

From my point of view, that would be probably a big changes in the code, because the structure was not designed like this at the beginning...

As of today, you can do this very simply:

• extend the class: class Bubble extends mojs.CustomShape { ... }
• add the shape: mojs.addShape('bubble', Bubble);
• use the shape: new mojs.Shape({ shape: 'bubble' });

See https://mojs.github.io/tutorials/shape-swirl/#custom-shapes.

[Sandstedt]

I guess the problem here was that the class Bubble is attached to the global namespace, so if you in another file, creates another Bubble class, this would override the previous one. But as I said before, this is easily solved by having a unique name. Or nest the extended class in a functional scope.

[ghost]

@Sandstedt @xavierfoucrier In fact, my idea is the same as ESM modularization, because the life cycle of global data is at the application level (GC is only performed after the application exits), so I think the more global data, the more it affects the performance of the application (consumption of more memory).

Therefore, I am more inclined to the idea of modularity, load when used, unload when not in use. That’s why I hope that Add support for modular use of custom graphics.

But now if I use mojs in a module like this

mojs.addShape( 'bubble', Bubble ); // passing name and Bubble class

// now it is avaliable on mojs.Shape constructor as usual
new mojs.Shape({ shape: 'bubble' });`

This will add a CustomShape to the global of mojs, which means that when the module is now uninstalled, the CustomShape will not be uninstalled (GC). I think this will take up more global resources.

Ideally, import mojs in the module. When this module is unloaded, all things created during this module will be GC. Of course, the global data generated by deliberate operations is not in this range. In fact, @Sandstedt said at the beginning what I wanted,'Maybe we could have both a global shape delcaration and a local one?'