please q. why no api document ?

[wjaxian]

This will make the development become difficult, even if it can be developed now, but the maintenance cost is still high in the later period, if the member changes, the new member will re-learn.
I hope that an official api document can be issued, which will make developers more favored. Thank you!

[atlasan]

We could maybe make a community documentation.
From the devs for the devs.

[coderofsalvation]

I'm on the fence on this one.
I mean, litegraph is something I keep coming back to, as it is so simple to use.
The README.md sortof says it all, and just dumping a node or graph using console.dir(graph) basically reveals all the functions.
The wrap-function-as-node paradigm is so powerful, not sure why no other visual editors use this philosophy.
Worstcase, the sourcecode of all the nodes basically demonstrate the usage of the .on**** event-hooks, so this in combination with README.md is totally fine for me.
I do understand there's always people out there who love reading docs though.

Btw. I just fiddled with this oneliner:

$ cat src/nodes/* | grep -E 'prototype.on' | sed 's/.*prototype\.//g;s/ .*//g;s/[^a-zA-Z]//' | sort | uniq

Which produces the following:

onAction
onAdded
onConfigure
onConnectionsChange
onDblClick
onDrawBackground
onDrawForeground
onDrawSubgraphBackground
onDrawTitle
onDropFile
onExecute
onGetCode
onGetInputs
onGetOutputs
onGetPropertyInfo
onInputAdded
onInputRemoved
onInspect
onMIDIEvent
onMIDIFailure
onMIDISuccess
onMouseDown
onMouseLeave
onMouseMove
onMouseUp
onPause
onPreRenderExecute
onPropertyChanged
onRemove
onRemoved
onResize
onResourceRenamed
onSerialize
onStart
onStop
onSubgraphNewInput
onSubgraphNewOutput
onSubgraphRemovedInput
onSubgraphRemovedOutput
onSubgraphRenamedInput
onSubgraphRenamedOutput
onSubgraphTrigger
onSubgraphTypeChangeInput
onSubgraphTypeChangeOutput
onUnpause
onWidget

Perhaps we can categorize them a bit, comment on them, and add them as markdown tables to README.md, something like:

Events

You can add functions to nodes to respond to certain events:

node hook func	node	info
onAdded	any	triggered when node is added to graph
....	...

Other thoughts

We could also just publish the /doc folder as a github page and publish the link in the README.md, here's the github action for that:

.github/workflows/website.yml:

# Simple workflow for deploying static content to GitHub Pages
name: Deploy static content to Pages

on:
  # Runs on pushes targeting the default branch
  push:
    branches: ["main"]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
permissions:
  contents: read
  pages: write
  id-token: write

# Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued.
# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.
concurrency:
  group: "pages"
  cancel-in-progress: false

jobs:
  # Single deploy job since we're just deploying
  deploy:
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
      - name: Setup Pages
        uses: actions/configure-pages@v3
      - name: Upload artifact
        uses: actions/upload-pages-artifact@v3
        with:
          path: './doc'
      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v2

[moritz89]

An action would be great. Currently I automatically build the docs for my fork (only used to publish current npm packages) and it would also have to run ./utils/generate_doc.sh. The output is published here: https://inamataco.github.io/litegraph.js/