Phoenix Channel JavaScript Client documentet at hexdocs.pm

Just mentioning, now the documentation is online with official phoenix docs: https://hexdocs.pm/phoenix/js/

But you’ll still miss some methods documented there. Maybe I’ll do a PR for it. :slight_smile:

4 Likes

Ow My Eyes!! o.o

Had the entire hexdocs.pm set to Night mode, but apparently that page is not themed like the rest of hexdocs and is not using ex_docs… Ow… That needs fixing… o.o…

EDIT: Also it is themed quite badly, there is stuff going off the edge of their containers:

Perhaps this is a job for Markup by @tmbb? ^.^

1 Like

Yep… Lot of work to do!

Why should this use ExDocs to document javascript code? It’s probably using a javascript documentation tool, right?

Regarding Makeup: in the unlikely fact that the javascript API docs are generated using Elixir, you’d have to write a javascript lexer/parser for Makeup, because it doesn’t support it yet… Makeup is probably up to the task of documenting the Elixir part of phoenix of course, as long as you don’t mind the fact that the function names are not yet highlighted - they are rendered as normal identifiers. This can and will be changed, as soon as I get the grammar right.

Exactly! You could replace it with something that would render ‘into’ ex_docs then (thus using the entire ex_docs ecosystem too, like night mode and consistent theming). ^.^

This seems like a lot of work just to get a consistent theme… The javascript implementation might be parsing and introspecting some javascript code, and it’s not practical to do so with Elixir.

It’s probably much easier to just add a night mode to the javascript theme.

Possible, but ‘inside’ ex_docs regardless somehow. Currently that single page does not seem to use anything from ex_docs… o.O

Other libraries could benefit from ex_docs knowing how to document javascript as well, Drab has a Javascript API for example.

Though I’m wondering if it would just be better to make a mock-module in Phoenix that documents the javascript interface instead… Hmm, perhaps using ElixirScript to actually generate the javascript from it too… That might be a lot better of a way if phoenix ever wanted to use elixirscript…

You can document javascript “modules” (packages? I don’t know exactly, because JS doesn’t seem to have real modules) using ExDoc already, right? Just do it in a custom page

Is this the beginning of an implementation of Javascript that targets the BEAM? Truly a match made in heaven xD

Now, seriously, you don’t need to actually implement javascript on the BEAM to document it. There is probably a format of documentation comments that can be parsed by Elixir into something usable… Sphinx (from python) can do it, apparently, and I doubt it is executing or compiling any Javascript into python (they do introspect python code). So, as long as you can parse the comments, you’re probably good to go (I’ve heard Elixir has a great work-in-progress Parsing Expressions-based parser that could be the right tool for the job ;))

But when there are probably 104962 node packages that already do this, you should start to question whether reimplementing it in Elixir is such a good idea…

2 Likes

A custom page which Phoenix is not doing as it would duplicate the docs into two places, thus making it easy to get one out of sync. ^.^;

Lol, Drab exposes ‘Commanders’ to a running webpage for async/sync communication between them both over Phoenix Channels. ^.^

Indeedy…