(Re)generate docs

[thecodrr]

Currently, there are a couple of JS APIs that are not yet documented (like Window.this.argv). It would be better to generate these using a documentation generation — something like an API reference. Doesn't have to contain examples or anything. This could also help in generating complete Typescript definitions for all the Sciter.JS modules.

[8ctopus]

The documentation is really a work in progress, I don't think @c-smile is ready to dedicate the time to do that but I know for a fact he welcomes pull requests.

[thecodrr]

@8ctopus unfortunately there is nothing that anyone else can do without looking through the code (or is there an external source that i don't know about?). I am talking about a documentation generator that directly extracts all the public/global methods, properties & functions of all the modules and puts them in a file. Like a reference.

[8ctopus]

I've got a business license with access to the source, I can run it if you give the instructions.

[thecodrr]

@8ctopus that'd be awesome. However, I can't know what documentation generator will work without knowing which language is being used internally. If you can tell me that, it'd be simple to figure out how to automatically generate docs.

If you can't figure it out, perhaps, you could dump the list of file names and share it with me?

[thecodrr]

I was able to reconstruct sys, sciter, and env modules type definitions using runtime introspection tricks but it's quite painful to figure out the function arguments etc. Generating types for all these modules would be a huge help during development. Same for different props available on all the components.

[c-smile]

was able to reconstruct sys, sciter, and env modules

@sys module is pretty much Txiki.JS as it is.

I think it makes sense to contribute documentation to txiki.js project, and I will take it from there.

And as for now @sciter and @env modules are documented in full.

[thecodrr]

@c-smile

I was able to find 3 undocumented functions in @sciter module. Would appreciate if you shed some light on these:

  /**
   * No idea what this does. The only return value I have been able to get
   * is -1.
   */
  export function unicode(): number;

  /**
   * Compiles a Javascript file?
   * @param filePath Path to a Javascript file
   */
  export function compileFile(filePath: string): ArrayBuffer;

  /**
   * Import an JS file/module. Much like `require` on other platforms.
   * 
   * @param modulePath Path to the module relative to current file
   * @returns Everything exported by the module
   */
  function import<T>(modulePath: string): T;

[c-smile]

unicode() function is not complete yet.

Essentially that is UNICODE classification function similar to String.indexOf().
This for example:

let idx = sctr.unicode(sometext, "rtl");

will return index of first strong RTL character in sometext string, or -1

compileFile() is not ready for prime time. Now it compiles file source into bytecodes (in ArrayBuffer).
It should also be a function that will load those bytecodes, But I've not decided yet how it should look like.
It could be just standard import .... from "somename"; where somename can be somename.js or somename.jsbc (compiled bytecodes). For now it can be used for syntax validity check.

The only function that is really battle tested and needs to be documented is sciter.import()
sciter.import(path):Object is a synchronous equivalent of standard import(path): Promise, Will do.

[leumasme]

@thecodrr It looks like you are making typescript definitions for sciterjs APIs - i've done the same in my project over the past few days.
What is your status on this (how complete are your typedefs/are they open source)?
What tricks are you using to find these functions? Object.keys and getPrototypeOf doesn't seem to find anything.