(I posted this in the discord group but got crickets...)
I'm having to use scripts in the html template (of a component) for access to the DOM/Window
If I use a bare <script> tag, astro squirrels it away somewhere and I can't get to it in the debugger, nor do console.log() statements produce anything (that I can see, anyway...).
If I use <script is:inline> then it becomes part of the DOM and I can debug it in the browser. Well and good. Except that every instance of the component instantiates an instance of the script on the page, so I get multiple <script> tags. And that's a problem because they interfere with each other.
Going back to the bare <script> tag solves that problem because astro makes it a module. Good, I like it.
But, beyond debugging, the next problem is that the bare <script> tag expects typescript, and using the <script is:inline> form only expects javascript. So, to develop and debug, I have to write the script in javascript and then to convert to the bare <script> tag, I have to put in TS types to remove the syntax errors. (It does work without typing, but it's ugly).
(I did try <script lang: typescript> but, that's not supported.)
So, what are you all doing for template <script> tags to get around this?
Related
I'm working on small .js which is going to be embedded on multiple websites, it will be loaded in a classic way - via script tag: <script src="myscript.js"></script> in sites body tag. I cannot add any more scripts to those sites.
I would like to track errors with error tracker such as Sentry, Rollup or HoneyBadger. However, all of them require being loaded with another script tag, most preferred before everything else.
Note: Those services need to load before everything else to catch errors property.
As I cannot add another script tag in the site's code, I need to execute their code inside my script, but before my actual script code.
I tried taking the content of HoneyBadger javascript library and putting it directly inside my file - it worked, however, I feel like it's terrible practice, as their code is written with modern browsers in mind, and mine supports older ones.
Is there any good way in my situation to load their .js externally?
I don't think that would work because of the way honeybadger.js v0.5 parses the script tag to get those attributes--it looks for the script tag in the dom when it's loaded.
Also, we've moved away from using the data- attributes in honeybadger.js v1.0, which was just released. In that version, you must use Honeybadger.configure to set your API key. Take a look at the new docs here:
https://docs.honeybadger.io/lib/javascript/integration/browser.html
I'd recommend going with v1.0, and using Honeybadger.configure for the configuration.
I finished developing and testing my HTML intake form and it is working nicely with ajax, json, and validation, and mailing. To finalize the form for production, I attempted to move the JavaScript from the HTML page to an external file and provide a link to the file in the HTML page. The js file is called formjs.js, and the link to it was placed at the bottom of the HTML page as <script src="../js/formjs.js"></script>.
The way I moved the JavaScript is cutting the scripts and pasting to the new js page and same the page and linked to it in the HTML page as mentioned above.
Upon doing so, I received tons of error messages on the js page because many of the functions are looking for information that exists on the HTML and had no idea how to get it. For example, a document. For example, this following script:
var Server_response_value_failure = document.getElementById("server_response_value_failure");
gets the following error:this variable is assigned and value but was never used.
Another example:
end of function};
at the end of each function get the error message that unnecessary semicolon.
I am not sure how to link the formjs.js file back to the HTML. Otherwise, the form works perfectly fine if I leave the script on the HTML page.
its fine, its just eslint that gives these warnings. for example, it will complain if you declare a variable and assign a value but you dont use the variable later on.
or if you call a function that you declare "later down" in the file.
I don't know if this will help, but sometimes you want to put the entire body of your javascript file in round parenthesis like this
(function(...) {
...
})();
in the end, you put another round parenthesis. This basically acts like $.ready() in jQuery.
I don't know if this will help you. You might want to rewrite your code.
I am looking for best practices on how to create a reusable "control" for use on several MVC 3 views. I could make an Html helper extension method (programmatically or with the declarative helpers in razor) or I could create a partial view.
The trick, in my case is that I need to do more than just dump some HTML in precisely the spot that the view calls the helper/partial. In addition to putting some HTML markup in that spot, I also need to add some javascript code to make it work. Normally, I would put this code elsewhere in the page (e.g. the bottom). This is of course strictly not required. Also, note, the javascript is not control instance specific. In other words, it is possible to write javascript that finds all instances of the control HTMl markup on a page and "activates" it with appropriate events, etc.
I have thought of several possibilities.
Have the helper/partial dump out the HTML and a <script> tag right in the place it is called. This seems like a bad idea since it means the control could only be used once per page.
Have two helpers. One to output the HTML markup, and a second that spits out the javascript. The second would be called only ever once and would be called from the bottom of the page so that the script ends up in the right place. If I invented a second control that was like this, I would have 4 helpers (2 for HTML, 2 for Javascript).
Invent some kind of ScriptManager that controls can register javascript with. The scriptmanager would have some kind of helper that would be added to the bottom of pages and would dump out the javascript for all controls that had registered some snippet of script. The call to the scriptmanager helper could be in the _layout.cshtml so that it automatically happens on any page that needs it. It would do nothing when a page didn't need it. This doesn't seem very MVC-ish, I guess.
Just have a helper that spits out the HTML and then add the javascript to the site.js that is included on every page. The javascript would be smart enough to not do anything if it could not find any relevant markup on the page (markup would have a wrapper element with a particular class). There would be overhead of this search for markup on all pages though, including pages that don't have any of these controls.
Same as #4, but put the javascript in its own .js file and include it only on pages that use the control. This is more efficient for pages that don't use the control, but it is an additional .js file and associated HTTP request for pages that do.
I am leaning towards #4, but is this a solved problem? Is there a better, 6th option?
My company is employing MVCContrib portable areas to package the code into a DLL for reusable "components"
Each of these components can be called via an extension method. For example:
Html.Components().ShowPoll();
Within each of these components, there is a way to register multiple css/js files that are embedded resources. Our main site will extract the resource files and minify + combines them before serving it.
The component will also register any on page event that will be called during the Document.OnReady event of JQuery. This allows each of the components to be mini-sites, standalone functionality with its own routes, models, and views.
Across the entire site, the same zip up JS for all the components are served. One because the file will be cached, and two - removes the complexity of determining what components are on the page and the resources it needs.
Let me know if you want more information regarding this setup.
I managed this issue with a layout page that had a section called jsCode.
#RenderSection("jsCode",false)
Then when I need it, I create in the content page:
#section jsCode
{
<script type="text/JavaScript" src="myJsCode.js"></script>
}
you could also create a helper that spits out the scripts you need for a particular page and encapsulate it that way, like this:
#helper MyJSFunction(string FunctionName){
switch(FunctionName)
{
case "firstFN":
<text>
<script type="text/JavaScript">
function SaySomethingSilly()
{
var sillySaying="We are the knights who say 'ni'!";
alert(sillySaying);
}
</script>
</text>
break;
case "secondFN":
<text>
<script type="text/JavaScript">
function SaySomethingElse()
{ var sillySaying="We are looking for a shrubbery...";
alert(sillySaying);
}
</script>
</text>
break;
}
}
Then my content page (assuming I want both functions) looks like this:
#{
Page.Title="Using helpers to create scripts";}
#section jsCode
{
#JSHelpers.MyJSFunction("firstFN")
#JSHelpers.MyJSFunction("secondFN")
}
<p>It works!</p>
which produced the output:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<title>Using helpers to create scripts</title>
<script type="text/JavaScript">
function SaySomethingSilly()
{
var sillySaying="We are the knights who say 'ni'!";
alert(sillySaying);
}
</script>
<script type="text/JavaScript">
function SaySomethingElse()
{ var sillySaying="We are looking for a shrubbery...";
alert(sillySaying);
}
</script>
</head>
<body>
<p>It works!</p>
</body>
</html>
Now if you wanted to get super-efficient, (though other words come to mind) you could pass the function a JSON array or a dictionary or even a string array with the names of the scripts you wanted to use, or the JavaScript to import, or whatever, and just use a single call to the helper. I think separate calls is easier to maintain, regardless of how you load the return values of the helper function, because you can see cleanly at a glance which scripts you are using on a given page, and to eliminate or add one is a simple one-line change rather than changing one element of an array.
As always, your mileage may vary, but I ran the sample based on this code in WebMatrix Beta 2 without any issues.
Lisa Z. Morgan
http://www.lairhaven.com
I have created a string builder JavaScript object and I'm using it with many different .js files in my project.
Can I create this class in a separate .js file and call it from all the other scripts that instansiate it, just like a C# class file?
Is this possible, or do I continue copying and pasting it into the bottom of every .js file that uses it?
Yes, this should not be a problem. Just include the .js files in the correct order in your html pages.
If you include the file in your main HTML page with your other js, you can then use the "class" as you wish:
<script src="js1.js" type="text/javascript"></script>
<script src="js2.js" type="text/javascript"></script>
In the above example, you can now instantiate a new instance of an object from js1.js with the code in js2.js. To do this with pure javascript, you would have to add the script tag to the DOM, or use AJAX to fetch the script file and eval() it.
// Create a <script> element
var scriptEl = document.createElement("script");
scriptEl.src = "js2.js";
scriptEl.type = "text/javascript";
// Append it to the <head>
document.getElementsByTagName("head")[0].appendChild(scriptEl);
To be perfectly correct, it's not the order of inclusion that matter, but rather the order of executing code. In most cases, Andy's and Segfault's instructions are just fine, but sometimes including the class file before its consumers isn't sufficient. For example, if you use ExtJS and you happen to define your class inside an onReady handler like this:
Ext.onReady(function() {
myClass = ...
}.bind(this));
then it won't get executed by the time your second src file is included into the page and executed.
I know, the example is a bit far-fetched :) but just make sure that your code is executed in the right order, not just included in the right order.
I came across this question and I wanted to add something (which probably wasn't there a few years ago).
Even thought you can add every single script to your "index.html" it's not a very beautiful practice (imho). Especially if you consider that you may want to write a extension (~ framework). You don't want to annoy the user with a bunch of script tags he has to add to his code. What you want is a single line like this:
<script src="yourFramework" (...) />
However, with the use of RequireJS you are able to achieve this. You've the freedom to separate your code and "your user" still don't have to add a novel to his "script section".
I have a .tag file that requires a JavaScript library (as in a .js file).
Currently I am just remembering to import the .js file in every JSP that uses the tag but this is a bit cumbersome and prone to error.
Is there a way to do the importing of the .js inside the JSP tag?
(for caching reasons I would want the .js to be a script import)
There is no reason you cannot have a script tag in the body, even though it is preferable for it to be in the head. Just emit the script tag before you emit your tag's markup. The only thing to consider is that you do not want to include the script more than once if you use the jsp tag on the page more than once. The way to solve that is to remember that you have already included the script, by addng an attribute to the request object.
Short of just including the js in every page automatically, I do not think so. It really would not be something that tags are designed to to.
Without knowing what your tag is actually doing (presumably its its outputting something in the body section) then there is no way that it will be able to get at the head to put the declaration there.
One solution that might (in my head) work would be to have an include that copies verbatim what you have in the head after the place in the head to import tags right up to where you want to use the tag. This is really not something that you would want to do. You would have to have multiple 'header' files to import depending on the content and where you want to use the tag. Maintenance nightmare. Just a bad idea all round. Any solution I can think of would require more work than manually just adding in the declaration.
I think you are out of luck and stuck with manually putting it in.
edit: Just import it in every page. It will be cached and then this problem goes away.