I'm still fairly new to coffeescript. What I would like to do, is be able to force single line comments to be put into the generated javascript. This is so I can load script references with the jasmine test runner built into Resharper.
Required Javascript output:
/// <reference path="/path/to/script.js" />
describe("Some test", function(){
it("Should do something", function(){
true.expectToBe(true);
}
}
Except, I can't seem to get this to happen with coffeescript. Another problem, is that the outputted comment needs to be added to the top of the file, where coffeescript dumps it inside the annonomous function:
(function(){
/* stuff goes here */
}).call(this)
Is there anyway to do this? I don't mind writing my tests with plain old javascript, but if I can use coffeescript that'd be ideal.
You can turn off the function wrapper with the "bare" flag
coffee --bare x.coffee
and you can output Javascript directly, including comments, by using quotes:
`/// <reference path="/path/to/script.js" />
`
describe 'Some test', ->
it 'Should do something', ->
true.expectToBe(true)
Related
I'm using JSDoc to document my javascript API.
I have an #example where I exhibit a minimized loader script (similar to the Google Analytics script). The loader script loads additional javascript from https://<server>/myProduct/lib/script.js.
My JSDoc documentation is bundled with myProduct, so there are aways /myProduct/lib/script.js and /myProduct/docs/ side-by-side. However, myProduct can be hosted by my customers anywhere, so I don't know what the <server> is.
I would like to be able to use document.location.href to detect current browser URL, and display a working loader script in my #example, so that customer can simply copy & paste a working script from documentation without having to manually edit the <server> part.
My question is: Does JSDoc offer any means to dynamically inject content into #example?
I could just manually edit the JSDoc output and include some custom javascript manually, which replaces <server> with the actual current server on run-time. However, this would be tedious to do every time my documentation updates.
No, JsDoc doesn't provide for injecting external content, and while it is certainly possible to create a JsDoc plugin to include external content during document generation, I don't think this would get you where you need to be.
I think the simplest answer would be to post-process the output of JsDoc to add a simple script, like
<script>
// retrieve the hostname from the current url.
const getServiceHostName = () =>
document.location.href.replace(/http:\/\/([\/]+)\/.+$/, '$1');
// replace the content of the span#service-host with the current hostname.
document.onload = function () {
document.getElementById("service-host").textContent=getServiceHostName();
};
</script>
to your html files just above the </body> tag.
Then, in the example content, insert a <span id="service-host"></span> where you'd like the service hostname to appear.
Another approach might be to take advantage of the fact that JsDoc passes the content attached to the #description tag directly into the html output.
So, this appears to do the expected:
/**
* Hostname: "<span id="service-host">hostname</span>"
*
* <script src="https://code.jquery.com/jquery-3.6.0.min.js"
* integrity="sha256-/xUj+3OJU5yExlq6GSYGSHk7tPXikynS7ogEvDej/m4="
* crossorigin="anonymous"></script>
*
* <script>
* $(document).ready(function() {
* $("#service-host").html(document.location.href);
* });
* </script>
*
* #name How-To-Monkey-Patch-JsDoc
*
*/
Note that the content of #example is wrapped in <pre><code>...</code></pre> in the html output which will definitely cause you problems, but it should be easy to post-process the html inline using the code above, by adding some recognizable token (perhaps [[HOSTNAME]]) into the example content and on document load, replace it with the desired value.
Please note also that this approach has the possibility of opening your docs to security issues, which is why I'd use the first solution above.
A proposed change to the Content Security Policy (CSP) of our web server to disallow inline script
is causing a problem with the documentation generated by doxygen. Specifically, the problem occurs
in the generated index.html file, and the following lines:
<!-- Generated by Doxygen 1.8.15 -->
<script type="text/javascript" src="menudata.js"></script>
<script type="text/javascript" src="menu.js"></script>
<script type="text/javascript">
/* #license magnet:?xt=urn:btih:cf05388f2679ee054f2beb29a391d25f4e673ac3&dn=gpl-2.0.txt GPL-v2 */
$(function() {
initMenu('',false,false,'search.php','Search');
})
/* #license-end */</script>
If the initMenu() code is put into a separate file that is just included like other JavaScript files, everything
works just fine. Is there a doxygen option to put all JavaScript into files rather that inline? We can
post process the generated file to do this, but may not know when the "pattern" of this code may
change due to updates in doxygen itself. And we may not know if using additional doxygen features will result in other inline JavaScript.
Any suggestions would be welcome.
Thank you
Fritz Sieker
First off Content Security Policy is useful but far from being an absolute authority. There are other completely useless headers such as those that block referrers based on "privacy".
Secondly there is no such thing as "text/javascript", perhaps they meant application/javascript?
If you're using good (though very non-common practices) you don't have any script elements in the body element (use defer="true" on script elements in the head). By doing that you'll better understand the structure of JavaScript and that in turn will help you become more proficient/capable/help more people/make more money/etc.
You can use document.getElementsByTagName('body')[0].getElementsByTagName('script') to find all the script elements in the body element that don't belong there.
If you do have script elements in the body element beforehand and moving them to the head element is not feasible right now you're likely going to have to work with inherent logic, in short those script elements will always be inserted in to the DOM in a specific and reasonably easily reproducible area of your code (like as the very last elements). In such a case you can find them via the following:
document.getElementsByTagName('body')[0].lastChild
document.getElementsByTagName('body')[0].lastChild.previousSibling
document.getElementsByTagName('body')[0].lastChild.previousSibling.previousSibling
Keep in mind that pressing Enter in your code to make it more readable will insert a textNode so you may want to append nodeName to those instances and look for "script":
console.log(document.getElementsByTagName('body')[0].lastChild.nodeName);
There is the DOM TreeWalker that might help you out here, subjective to the end result in your DOM. I don't know offhand if you can transverse all the elements in reverse (probably).
Once you know what you want to delete instead of making everything convoluted just send that object (or id) to the following:
function element_del(id)
{
if (typeof id=='string' && id_(id) && id_(id).parentNode.removeChild)
{
id_(id).parentNode.removeChild(id_(id));
}
else if (typeof id=='object' && typeof id.parentNode=='object') {id.parentNode.removeChild(id);}
}
//Example:
element_del(document.getElementsByTagName('body')[0].lastChild);
I hope this helps!
If you use doxygen, you'll have noticed how certain adornments can appear in the header bar for the detailed info for a given function. Here's an example, it has the inline adornment, another one I've seen is static and I expect there are others.
I'm actually using doxygen to document Javascript on a mixed C++/Javascript project and would like to put an async adornment into the documentation for functions that are asynchronous. I'm using Coherent labs excellent script to do to this.
So, is there a way to insert custom adornments? I'd like the syntax to be something like this:
/// #adorn async
I don't see a direct solution in doxygen for "custom" labels. Problem would of course also be that it should work for all output types.
In e.g. LaTeX / PDF the static is shown as [static].
In HTML I think the relevant part is:
<td class="mlabels-right">
<span class="mlabels"><span class="mlabel">static</span></span> </td>
Maybe you could do something with the css files / or embedding a javascript script in the HTML code.
Other solution would be to add a command to doxygen that handles this type of requests, but this would mean again a new command in doxygen.
I am learning on React JS and I have got information on JSX and babel. But I am not getting clarity on how these are helping React and how these or differ from each other
React JS
while building an app using React, you can create the components/views in two ways
using standard React object and methods
using JSX
JSX
JSX is a separate technology from React and completely optional while building React application, however it makes life much easier when you combine JSX with React.
Let's see how :
Approach 1 : standard React way
(function() {
var element = React.DOM.div({}, "Hello World");
ReactDOM.render(element, document.getElementById("app"));
})();
The above code can be found at this link.
Here, you just need to include the react and react-dom library to your page.
Nothing else is required. No JSX, no Babel.
Approach 2 : JSX way
(function() {
var HelloWorld = React.createClass({
render : function() {
return (
<div> Hello World </div>
);
}
});
var element = React.createElement(HelloWorld, {});
ReactDOM.render(element, document.getElementById("app"));
})();
The above code can be found at this link.
Note the difference here: <div> Hello World </div> is used inside JavaScript. This is called JSX syntax.
Now, compare the JSX approach with the vanilla JavaScript approach:
With JSX, You can add many more HTML like elements inline, just like standard HTML, to create the view layer.
Without JSX, the code can get messy because of the multiple layers of elements required to create HTML in JavaScript.
Babel
Now the question is, who understands JSX?.
Here We need a transpiler that understands JSX and converts it to a format that can run on browser. Babel does just this job.
Transpiling
Transpiling can be done two ways
Browser based/client side transpiling (use only for development
purpose)
include this file as a script tag
use type="text/babel" on your script tag which loads your JSX
Here's the sample code
Server based transpiling - e.g. Babel
You can use different tools like webpack etc.
Here's some sample code.
Hope this helps.
tl;dr;
JSX is an easy syntax to represent markup in your code, which Babel converts to pure JavaScript.
Long version:
JSX is a syntactical convention which aims to make element structure definition easier in a React Component's code. This XHTML-like syntax which you write inside your components gets converted into JavaScript (not very different from Hyperscript) by Babel.
A very simple Hello World component written in JSX:
class HelloWorld extends Component{
render(){
return <div><h1>Hello World!</h1></div>
}
}
And the equivalent in pure JavaScript:
class HelloWorld extends Component{
render(){
return React.createElement(
"div",
null,
React.createElement(
"h1",
null,
"Hello World!"
)
);
}
}
Do note that the above example is abbreviated to keep the focus on the JSX part.
You would soon learn that Babel actually lends a lot more power to the React world than mere JSX transpilation. It allows you to use a lot of cool new ES6/7 features right now.
i'm trying to get the starter-kit example of ember.js to work directly with an app written in coffeescript (with the use of http://coffeescript.org/extras/coffee-script.js).
I want to use this in an development environment, without the need to convert the coffescript to javascript first (manually or with tools like jitter).
Basically i just replaced the line
<script src="js/app.js"></script>
with the lines
<script src="js/libs/coffee-script-1.3.3.min.js"></script>
<script type="text/coffeescript" src="coffee/app.coffee"></script>
in the index.html
All changes i've made can be found in my fork on github at https://github.com/GordonSchmidt/starter-kit
The coffescript itself seems to be fine, because when i convert it to javascript first the starter-kit application works with this javascript. But when i use the coffeescript directly it throws the error "assertion failed: Unable to find view at path 'App.MyView'" in line 45 of ember-0.9.8.1.js. The coffee-script.js all by itself seems to work as well (see demo.html). So it has to be a conflict between ember.js and coffee-script.js.
But I'm not able to find this error. Can someone please point me in the right direction?
from coffeescript.org
The usual caveats about CoffeeScript apply — your inline scripts will
run within a closure wrapper, so if you want to expose global
variables or functions, attach them to the window object.
your coffeescript should look something like this:
<script type="text/coffeescript">
window.App = App = Em.Application.create()
App.MyView = Em.View.extend(
mouseDown: -> window.alert "hello world!"
)
</script>
see here for a fiddle