mavoweb / treecle

WIP. A toolbox for hierarchical JS objects.
https://treecle.mavo.io
MIT License
7 stars 0 forks source link

Node type flexibility & TypeScript #3

Closed adamjanicki2 closed 8 months ago

adamjanicki2 commented 8 months ago

One important thing we need to work out before converting this library to TS is how flexible node types are. If they're too flexible, TypeScript becomes useless. For example, we could choose to enforce that nodes have to be objects, or we could allow them to be custom classes. If we allow them to be custom classes and objects, TS isn't going to be much help.

The main question is: if a developer has specific-enough needs to want to build their own Node class, would they even be using Treecle? Are there any common use cases where someone with a non-object type of node would want to use Treecle?

adamjanicki2 commented 8 months ago

@LeaVerou thoughts on this?

LeaVerou commented 8 months ago

A good design principle for any artifact you develop is the priority of constituencies: End-users > Authors > Implementors > Theoretical purity.

Our convenience is lower priority than our users’ convenience (called "authors" here to distinguish from their own end-users), and their convenience is less important than their end-users’ convenience. Do not inconvenience users to make our life developing or testing easier. Favor internal (implementation) complexity over external (API) complexity.

We should not be making API design decisions based on what TypeScript supports.

The main question is: if a developer has specific-enough needs to want to build their own Node class

It’s not just about making their own Node class; they may not want to treat every object as a node. It's entirely reasonable to want to scope it down to objects that pass certain criteria.

adamjanicki2 commented 8 months ago

Sure makes sense, let's just stick with plain JS then

LeaVerou commented 8 months ago

@adamjanicki2 Is there any way to tell TS that something is a "Node" without having to define what a node means? It seems like that could give us the best of both worlds.

adamjanicki2 commented 8 months ago

The best compromise I can think of is setting type Node = any to provide the flexibility we want while getting good type checking in most other places with other basic typing

LeaVerou commented 8 months ago

Do you think TS still offers us benefits in that case?

adamjanicki2 commented 8 months ago

Not enough to justify using it over regular JS

LeaVerou commented 8 months ago

Ok, I trust your judgement on this! If you decide to move to TS, I'm game to try it.