Closed dbauszus-glx closed 1 week ago
It is important to add some standards how modules and methods should be documented.
/**
## mapp.utils.xhr(params)
The default method of the xhr module returns a promise which resolves with an response from a XMLHttpRequest.
@module /utils/xhr
*/ /**
The params object/string for the xhr utility method is required.
The params are assumed to the request URL if provided as a string argument.
The request params and response are stored in a Map() if the cache flag is set in the params object argument.
The method is assumed to be 'POST' if a params.body is provided.
@function default
@param {Object} params The object containing the parameters.
@param {string} params.url The request URL.
@param {string} [params.method=GET] The request method.
@param {string} [params.responseType=json] The XHR responseType.
@param {Object} [params.requestHeader={'Content-Type': 'application/json'}] The XHR requestHeader.
@param {string} [params.body] A stringified request body for a 'POST' request.
@param {boolean} [params.resolveTarget] Whether the target instead of target.response should be resolved.
@param {boolean} [params.cache] Whether the response should be cached in a Map().
@returns {Promise} A promise that resolves with the XHR.
*/
Going forward we need to look at a better template in regards to nested argument objects.
This would look much better if not shifted.
I still believe the high water mark is the Mapbox documentation.
https://docs.mapbox.com/mapbox-gl-js/api/map/
I like very much everything about the layout.
It's better to create a DOCUMENTATION.md or even JSDOCS.md referenced by CONTRIBUTING.md as well as DEVELOPING.md
Examples should give clear use on documentating modules, functions, and how to use @params
, @requires
, @description
, @returns
, headings, etc.
Information in regards to contributing, building, and viewing documentation needs to be added to the readme.
https://github.com/GEOLYTIX/xyz/blob/main/CONTRIBUTING.md