First updates to hashi documentation #8086
Conversation
There was a problem hiding this comment.
The main thrust of the issue is to document hashi for HTML5 app developers, in this PR we seem to be doing both this, and also documenting hashi for developers using Hashi in Kolibri, and for people developing hashi. I think it would be good to separate these concerns by documenting the different tracks separately.
The README seems like a good place for the latter, but not for the HTML5 app developer audience.
marcellamaki
force-pushed
the
first-updates-to-hashi-documentation
branch
from
4e4711f to
92a839a
Compare
| * Method to query contentnodes from Kolibri and return | ||
| * an array of matching metadata | ||
| * @param {Object} options - The different options to filter by | ||
| * @param {string=} options.parent - id of the parent node to filter by, or 'self' |
There was a problem hiding this comment.
I just noticed that been using a different "optional parameter" syntax in my JSDoc strings for the theming. Personally, I like the style I use more, since it's emphasizing the argument name, rather than the type, e.g.
| * @param {string=} options.parent - id of the parent node to filter by, or 'self' | |
| * @param {string} [options.parent] - id of the parent node to filter by, or 'self' |
| * @param {Object} options - The different options to search by | ||
| * @param {string=} options.keyword - search term for key word search | ||
| * @param {string=} options.under - id of topic to search under, or 'self' | ||
| * @return {Promise<PageResult>} - a Promise that resolves to an array of ContentNodes |
There was a problem hiding this comment.
Could you add the typedefs for PageResult and other Object types in the docs as well?
…, add to hashi README
|
@radinamatic - these were the original Gherkin scenarios drafted at the start of the project to help guide the outcomes. Please let me know if they are okay for now (in terms of how they are written - I know we will probably have to go over some of the functionality), or if any changes would be helpful. Thanks! |
marcellamaki
force-pushed
the
first-updates-to-hashi-documentation
branch
from
c539d3f to
21bb05a
Compare
|
|
||
| External/partner product teams can create HTML5 applications that are fully embeddable within Kolibri and can read Kolibri content data, which they otherwise wouldn't be able to access. This opens up possibilities for creative ways in which learners can engage with content, because partners can create any type of app they want. The app could be something completely new, developed for a content source that we are adding to the platform, or it could be a branded, offline recreation of a partner's existing learning app that previously would not have been able to exist on Kolibri. | ||
|
|
||
| When a user has permissions to access a custom channel, and they click on it in the main learn tab, rather than viewing "normal Kolibri," they will experience a full-screen HTML5 app. One "out-of-the-box" user interaction is the "navigateTo()" function, which opens a modal that displays a content node. For other data fetching requests, the app, not Kolibri, has the responsibilty of determining what to do with that data. |
There was a problem hiding this comment.
I would suggest italic formatting for what you've put between quotes, and pairs of backtics for code:
...rather than viewing the normal Kolibri, they will experience a full-screen HTML5 app. One out-of-the-box user interaction is the
navigateTo()function, which opens a modal that displays a content node.
At this point this is a pretty high-level overview, so would appreciate thoughts about
I think as this work continues we might need to continue to update the documentation, so my goal for this PR is to just get a foundation in place.