Export base functions to compute elements as they are needed

[nemo9955]

Hello, would it be possible to export "all" the functions in this library so we can create custom/liter geoDelaunay for example ?

My use-case is to use geoDelaunay to create the edges on a big set of points but i am not interested in anything after edges = geo_edges(triangles, points),.
Looking at performance, ~50% of load is used of generating edges and the rest on neighbors,hulls,etc.

Something like this as a basic example is what I am thinking (with export to all the functions inside the .js files):

export * as rawGeoDelaunay from "./src/delaunay.js";
export * as rawGeoVoronoi from "./src/voronoi.js";
export * as rawGeoContour from "./src/contour.js";

[Fil]

We don't want to export all because it would be a mess to document, but we can think of a lighter call that returns the triangulation only. Maybe call it geoTriangulation, and it returns {delaunay, triangles, edges, find, neighbors }? It would also bring more performance to the geoContours I believe?

If you want to build a pull-request, please make it against #35 (I plan to merge it in main very soon).

[nemo9955]

Feel like geoTriangulation would solve my problem specifically, not verry flexible if people want other parts extracted.

How about an optional parameter to existing geoDelaunay and geoVoronoi with a map string:bool which parameters to be computed ?
Or what would be the issue in exporting functions and documenting then in a bunch as Base functionality functions, for advanced use if needed. ?

[Fil]

The issue is maintenance. If you want to take the code and do what you want with it, no problem, but if we offer an API it must (ideally!) be documented, tested and maintained.

It would be nice to see which of the functions really consume CPU. I would understand that computing all the circumcenters or the polygons is expensive, so it makes sense to stop before that.

Another approach maybe would be to rewrite all the methods as lazy functions that start computations only when needed. But I'm afraid it would introduce yet another API. This module already has 2, which is 1 too many :)

[nemo9955]

Understandable about the maintenance issue, but the functions already exist and are part of main objects, so should already be tested and maintained indirectly.
And regarding documentation, they sort of are already, but it's not the function being documented, but it's return.

Maybe issue with 2 modules is that this lib should have as "convenience" functions just geoVoronoi and geoContour.
geoDelaunay be provided as the base functions of the library .
This way, people that rely on existing geoDelaunay can just implement it with 14-26 lines of code, using the base functions, if it becomes "deprecated".

As a tangent, for lots of points geoVoronoi is slow considering the preparation of the arrays beforehand, geoDelaunay is faster as it uses more direct array, could be faster with #7 (could be used with THREE.js *BufferAttribute ), but that is another discussion.