Proof of concept: base classes for options, events, interactions

[mggower]

nothing in here is "plugged" in to the renderer yet, but this stands as a proof of concept for some structured base classes

[mggower]

I am anticipating some push back against the use of interfaces over types here. When it comes to inheritance/sharing properties interfaces are by far the easier/cleaner approach. By leaning into inheritance we will be less likely to have inconsistencies in our type model

[jameslaneconkling]

This is probably just my preference for functional programming over oop, but my assumption was that anything you can do w/ types you can do with interfaces. e.g.

interface X extends Y { foo: string, bar: string }
// same as
type X = Y & { foo: string, bar: string }

With the notable difference that types can express both intersections & and unions |. Typescript briefly notes the differences here, and honestly I like it that you can't mutate a type while you can mutate an interface (mutating an interface feels like a bug in waiting).

It's worth noting that the creator of Typescript also created C#. C#, like Java, is heavily oriented towards oop, but has also incorporated a lot of functional concepts on top. What if they both (and Typescript...) had just started with a simple functional pattern, avoided oop, and cut the language's surface area in half...?

[mggower]

RenderObject

• abstract class serves as a base for any display object in an app. i.e. Strokes, Icon, etc.
• creates a required structure for all display objects making them easy to manage in a generic way
• simple base methods can be overridden or enhanced in practice

[mggower]

RendererOptions

• straight forward class that manages and updates renderer options
• automatically applies defaults
• single instance that can be a shared as a dependency without losing reference to the object after updates

[mggower]

ApplicationEvents

• similar to RendererOptions, this class will manage and update application events
• can also manage other properties like the EventSystem for easy access in relevant classes

[mggower]

InteractionManager

• primarily for organization and usability

this:

this.renderer.dragInteraction.dragging
this.renderer.zoomInteraction.zooming
this.renderer.interactionObjectManager.mount(this.hitArea)
this.renderer.interaction

becomes this when you share the reference instead of the entire renderer:

this.interactions.isDragging
this.interactions.isZooming
this.interactions.manager.mount(this.hitArea)
this.interactions.container

[mggower]

EventsManager

• will be the base class for defining things like node events, viewport events, etc.
• simplifies the relationship between hit area + events

[mggower]

HitArea

• base class can be used on its own or extended to define a particular shape (circle, line, rect, etc.)