Closed orbitbot closed 3 weeks ago
Only m.route
and m.stream
are affected by this, since they seem to be the only parts of the API that are particularly overloaded, but it would be really beneficial to immediately be able to see an overview of both the default signature and the static members instead of scrolling (particularly in the stream case) the whole page looking for whatever that method was called again. Partially touched upon above already.
@ feature/idea point: "@porsager suggested putting all the docs on one single page, so users can Ctrl-F their way to happiness"
any progress?
@talentlessguy and others interested: Here's the status on most of them.
Wrt
@porsager suggested putting all the docs on one single page, so users can Ctrl-F their way to happiness
Basically https://mithril.js.org/api.html.
... I believe the original intent by @porsager was perhaps more to have something like https://rollupjs.org/guide/en/ , so that everything can be searched in the browser itself. Personally I've tended to use google with site:mithril.js.org <searchterm>
which works well enough, albeit I probably have a decent recollection of the appropriate terminology.
Not really a fan of neverending webpages from a reading perspective, personally, so ideally some kind of search functionality might be neater, though that'd require some kind of infrastructure addition I guess.
@orbitbot We can have both ;) - example: http://pm2.keymetrics.io/docs/usage/pm2-doc-single-page/
Aaah, cake and a full stomach. Yeah, guess that might work if someone feels it's worth it.
@orbitbot @porsager Okay, I see what you all are referring to now. I'd be open to a generated single-page document exposed through the main navigation, with a header giving the tip of "If you want to search for something a little more advanced, try using site:mithril.js.org <query>
in your favorite search engine". We'd also need to drop a robots.txt
that prevents that page from being indexed, so we can point people to the standard pages.
I've seen a lot of docs sites lately using Agolia to a similar end lately (like Babel and Vue), but I'm hesitant to add a full third-party search engine plugin just to enable a basic text search of various docs.
@isiahmeadows following @porsager's suggestion obviates the reliance on external search engines. I think it's a really good idea!
Probably not really worth the effort, but I guess it would be feasible to do full clientside search if the whole docs site would be SPA'd, especially with some page containing the whole documentation...
@orbitbot Maybe we could use this and feed it parsed data from the docs. (I just found it minutes ago.) I could make sure it loads early enough in the background to not delay search too much, and I'd only need a service worker to cache the search index (to avoid unnecessary network requests).
So new update: here's the items remaining, of @orbitbot's original list. Everything else has been addressed, either resolved and published (most of them) or rejected entirely.
This is a braindump issue over suggestions regarding the docs that can be improved on, on different levels. All IM(H)O, of course, so consume with the appropriate sodium nitrate dose (colloquially, a pinch). I've read through the entire docs twice approximately twice about a month or so apart, and have been paying attention to related discussions (although not in a completely structured manner) on the gitter chat, so apologies for the wall of text... Feel free to chip in with your own observations etc. In the second read-through just now, I did skim quite a bit (fe. most of the code content).
Features / ideas:
<div id="sth">
tomount
orrender
into? that's otherwise empty, f.e. at the beginning of each page?)m.route
vsm.render
vsm.mount
, vdom libs vs jquerymithril-awesome
list of relevant links)GH Readmes:
<br>
before each headline for better readability, docs site doesn't have this issue since it's handled with CSS marginslanding page
m()
has reserved object keys that breaks stuffinstallation
package.json
, likewise for other toolssimple-application
examples
in the GH repo, as a cheat sheet.jsx
es6
css
testing
all the pages under Key concepts
vnodes
changelog:
m.redraw
is not consistently async (yet?)m.request
.serialize -> request happens -> .extract -> .deserialize
" flow or something similar, there has been confusion about these methods (and perhaps others) on gitterm.withAttr
m.stream and ospec