Is it possible to add or remove scripts from a bundle based on the debug setting of the application?
I.e. Given a bundle definition of-
var jQueryBundle = new ScriptBundle("~/js/main").Include(
"~/Scripts/jquery-1.{version}.js",
"~/Scripts/jquery-migrate-{version}.js",
"~/Scripts/script.js");
Remove the jquery-migrate reference when the site is not running in a debug profile, or conversely add it under debug.
Nb. I actually came up with a solution to this whilst formulating the question, I have tested it and it seems to work. I have answered it but left it unaccepted for now should a better solution present. In the mean time the answer will at least now be available for reference should anyone want to make use of it.
I actually came up with an answer to this whilst writing out the question. Since I hadn't been able to find an answer through searching I decided to post the question anyway and answer it - both so it is available as reference for anyone else wanting to do the same thing, and to get feedback from wiser minds than mine if this the most performant way of achieving this - or even a sensible thing to do.
var jQueryBundle = new ScriptBundle("~/js/main").Include(
"~/Scripts/jquery-1.{version}.js",
"~/Scripts/script.js");
if (HttpContext.Current.IsDebuggingEnabled)
{
jQueryBundle.Include("~/Scripts/jquery-migrate-{version}.js");
}
bundles.Add(jQueryBundle);
I have tested this and whilst debugging the script is listed (I have retained the defaults of bundling and minification left off in debug mode) and whilst running normally the contents of the migration script were not in the combined minified script. Over the next couple of days I will profile this to compare to "vanilla" bundling to see what (if any) performance impact this has on application start.
Related
I found many languages provides some way to change code runtime. Many people ask queries regarding how to change code in this or that language runtime. Here I mean by change code is that rewrite code itself at runtime by using reflection or something else.
I have around 6 year of experience in Java application development. I never come again any problem where I have to change code at time.
Can anyone explain why we require to change code at runtime?
I have experienced three huge benefits of changing code at runtime:
Fixing bugs in a production environment without shutting down the application server. This allowed us to fix bugs on just some part of the application without interrupting the whole system.
Possibility of changing the business rule without having to deploy a new version of the application. A quicker deploy of features.
Writing unit test is easier. For example, you can mock dependencies, add some desired behaviour to some objects and etc. Spock Framework does well this.
Of course, we had this benefits because we have a very well defined development process on how to proceed on this situations.
At times you may need to call a method based on the input, that was received earlier in the program.
It could be used for dynamic calculation of value based on the key index, where every key is calculated in a different way or calculation requires fetching required data from different sources. Instead of using switch statement you can invoke a method dynamically using methodName+indexOfTheKey.
I've been developing a lot of small web development projects in various IDEs, and find myself laboriously typing in jslint configuration headers to silence JSLint. Its warnings and errors are all valid, and I want to keep JSLint in my work cycle, but I spin up 2-3 isolated environments a day, sometimes from generators in Yeoman, other times by hand. These all end up with gripes from JSLint that require the following in every .js file:
/*jslint browser:true*/
/*global require,yada,yada,yada*/
JSHint has a wonderful feature whereby you can declare all these in a parent folder using the body of the .jshintrc file. Does JSLint have something like this? It seems like such an obvious addition, but I can find nothing like this which will work across IDEs (Visual Studio, IntelliJ, Brackets, Sublime Text,...).
I found this for .NET, but I find Visual Studio heavy for projects I might only spend a couple hours on and then throw away (https://jslintnet.codeplex.com/wikipage?title=JSLint.NET%20Settings).
Does someone have some insight on this?
Edit: (See my new answer below.)
I think the quick answer is that setting global settings for every file you JSLint is the job of your IDE or favorite text editor. That is, JSLint is essentially just a big javascript file. It doesn't care about file paths, etc, and won't look for a server-wide config.
I mean, you can change the options used when JSLint is called, but that essentially reduces to the same problem you have now.
So then the question is, if you don't like Visual Studio, what tools do you use? In VS, I've used this tool and liked it a good deal. I think that's different (as in not forked or related, but I could be wrong) than the one you found. In Sublime Text, there are two. I've been using Darren Deridder's, but I get the impression that it's the less popular of the two. Etc etc.
So this isn't a javascript/JSLint question so much as a JSLint wrapper question.
It should be said that JSLint's code is very clean, and it's easy to rig up your own process using Node or something similar. I've done it with JavaScript.NET, though I'd use Node if I was doing it again.
And I'd also suggest you consider keeping the file-by-file JSLint headers. I tend to do so, and it keeps your use "excuses" to a minimum, keeping your code tighter. It's way too easy to get a giant /*global ...*/ header line, for instance, if you have a lot of shared config info. It also means that when someone else uses a "shell" tool different than yours to JSLint your files, you know they're using pretty close to your intended accepted behaviors.
So the literal answer to your question is, "No, JSLint doesn't inherently support a box-wide config file." The longer answer is, "Tell us where you do like to work." ;^)
EDIT: Debated staying out of the usual 'Hint vs. 'Lint discussion, but I will quickly say I like how you're thinking. JSLint is more draconian, but JSLinted code means something more specific than code that's been JSHinted. I won't argue that more specific means better, per se, but I will say that I see JSLint's draconian-ness to be an advantage. It might not be the only way to do something, but there's nothing that Crockford's telling you that's a bad idea, and it's nice to get familiar with those conventions. In the parlance of my times, Crockfords's not wrong, Walter.
EDIT 2: So Brackets looks like it's come a long way since I last used it. Seems to have JSLint by default.
It looks like you can set global JSLint options using the jslint.options setting in your preferences file (and there might be/have been a goal to make that a more interactive UI eventually), like this...
{
"debug.showErrorsInStatusBar": false,
"styleActiveLine": true,
"jslint.options": { "sloppy":true, "white":true, "browser": true }
}
And it does allow settings at the top of the file to override these settings.
This really is approaching a golden age of text editors. I still fall back on VIm a lot, but mainly live VS and Sublime Text, with even jEdit, Coda, and PhpStorm for specific tasks. Looks like this might be my new Sublime for Node & html frontend dev. The quick CSS edit is wonderful, though bindings will complicate it. Thanks!
While the previous excepted answer is an excellent one (and many thanks to its author for making it even better over time!), the world has moved on from JSLint. I'd recommend to anyone reading this very old question that you seriously consider chucking JSLint out of your development cycle in favor of its very effective successor, ESLint. For an even better experience, I'd suggest taking a hard look at the ES7 vs. TypeScript paths, with TSLint being your best option for TypeScript linting.
However, for the development experience that trumps even these modern libraries, go directly for Prettier.js. With Prettier, your linting woes become irrelevant, since Prettier will rewrite your code in an opinionated manner every time it's run.
For the best results with Prettier, add the packages "lint-staged" and "husky" to your dev-dependencies, then add the following in your package.json:
"husky": {
"hooks": {
"pre-commit": "lint-staged"
}
},
"lint-staged": {
"*.{js,json,css,md}": [
"prettier --write",
"git add"
]
},
This will force Prettier's auto-linting behavior to run every time Git's commit command runs.
I can't tell you what a relief using Prettier has been for the front-end development teams and projects I am responsible for. We've gone from code reviews bleeding with linting correction comments to zero almost immediately. Feedback from the teams has been universally positive.
The only modification I've made has been to the tabs-vs.-spaces setting. I've modified my .prettierrc.json file to select tabs instead of spaces, because use of spaces at different widths causes dirty git merge histories. You can't control the indentation of 250+ developers spread over multiple hemispheres, some of whom drop in and out of the project before you even know their names. So, setting tabs as the default indentation allows all of the developers to operate with the indentation they're comfortable with without modifying lines in Git. Here's my .prettierrc.json file, with some other slight modifications:
{
"arrowParens": "always",
"bracketSpacing": false,
"singleQuote": true,
"useTabs": true,
"trailingComma": "none"
}
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
For a big single page web application using ASP.net, MVC5 and Angular JS I'm looking to serve dynamic generated stylesheets. The application will have an big amount of users (> 1000s) that individually can set about 10 variables. These include a few colors and logos. These colors and logos will be used in the less stylesheet to generate lots of classes/styles. The stylesheet is compiled from a lot of files, about 50 .less files.
I'm planning to use the following approach:
On loading index.html, after user login, I call an ASP action to load the stylesheet <link href="Give/Me/My/Dynamic/Stylesheet/For/User/12122312">
The controller action will do its magic and gets the 10 user variables from the database
The server will than use .dotless to compile the less to css
Server returns string
This approach will work, but I'm afraid the performance will be not so good. My questions:
Is dotless the fastest way to compile less?
How long will the databasecall + compiling take?
Is this the way other application do this?
I'm looking if there's a way to cache the css request - maybe check if there has been a change since the last time the css was compiled.
What will not work:
Compile the less to css and then change the variables in the css (saves a compile every time). Some of the colors in the stylesheet will be based upon on of the variables. (eg lighten(#333, 0.3) etc).
Use a static stylesheet and then override these in the head of the HTML doc. There will be a whole lotta custom styles involved!
Some other thoughts:
This solution seems to do the same, but compiles on build:
This solution saves the variables to a static file and uses that for compiling. This saves a database call, but the directory gets crowded with lots of users.
Your planned approach sounds fine. As far as your specific questions go:
Is dotless the fastest way to compile less?
"Fastest" is relative and debatable. The only way to know would be to run this and any available alternatives on your production machine using some sort of benchmarking. Even then, outside factors such as how much load the server is getting, how many requests are being handled simultaneously, etc. can affect those benchmarks. For example, maybe one solution is "faster" handling an ideal scenario, but has a large overhead that causes it to run much slower than another solution when the server is actually being taxed. Overall, it's impossible for anyone to give you any sort of definite answer to this, and really, it's probably too early to even be that concerned about the question. If it becomes a problem in production, then you can start investigating alternatives.
How long will the databasecall + compiling take?
Also completely impossible for anyone to give a definitive answer to. There's way too many variables involved in that relatively simple question. What database are you using? What version? What are the specs of the server it's running on. What else is running on that server? How have you configured the database server? What kind of query are you running? How many tables are involved? What's the size of the resultset being returned? What type of network infrastructure is in place? What's your latency? How capable is your network infrastructure at handling load? There's probably more questions I could ask if I though long enough and that's just about the database call portion. I don't expect answers to those questions; I'm merely trying to point out 1) there's no way anyone can answer that for you and 2) you're going to have to do a lot of research to come up with those answers yourself.
Is this the way other application do this?
This is highly speculative. First, it assumes this is somewhat common, when it's probably anything but. In my 20-some-odd years of doing web development, I've yet to encounter a scenario where I needed a dynamic stylesheet. Granted, for a large part of those years stylesheets didn't even exist or at least weren't heavily used yet and just because I haven't had a need doesn't mean there's not still a perfectly valid business-case for this. I understand the desire to want to find an accepted pattern or best practice to follow, but the sample set here is probably so small that no such thing exists. Trust your gut. Build things in a way that makes sense. Then test, refine and refactor. That's really the best advice I can give you.
I'm looking if there's a way to cache the css request - maybe check if there has been a change since the last time the css was compiled.
This one is pretty easy. Just make sure to set the appropriate response headers before returning your response. Expires is really your go-to here. If the stylesheet virtually never changes for the user, then you can set a far future Expires header and the client's browser should cache it requiring all this infrastructure to not have to do its thing again for a while. If the change-ability is variable (any time the user updates a setting, they need a new version, and this can happen at a whim), then you can still use a far-future Expires header and employ a cache-busting querystring param that will force the browser to get a fresh copy. A good choice might be adding the last modified date for the settings when rendering the link for the stylesheet. If the user hasn't modified anything, then the date won't change and the original cached version will be used. But if the date has changed, it will look like a new URL to the browser, and it will be fetched fresh.
I'm using reactive extensions (well, trying, learning) in a windows store app. I have a series of async operations that will eventually navigate to an authorization web page for RTM. Given the reading I've done, I would expect to write something like the following:
var result = rtm
.GetFrob()
.Select(s => rtm.GetAuthenticationUrl(s))
.ObserveOnDispatcher()
.Do(uri => AuthWebView.Navigate(new Uri(uri)))
.First();
However, I can't seem to find a method ObserveOnDispatcher, and further there is no Scheduler.Dispatcher property either, leading me to think on a Windows Store application there is something deeper gong on with the main UI thread and how you reference it.
GetFrob, btw, creates an IObservable sequence using Observable.FromAsync (if that helps with this).
BTW, if I remove that line, I fail in the call to the Navigate as posting it from the wrong thread. So, what is the proper thing to do here to make sure I'm back on the correct thread?
BTW, Excuse the ".Do" operation here, I know it isn't "nice", however, I'm still experimenting in throw-away code.
Many thanks in advance!
Argh. Apparently I just am not good enough at search. :(
Turns out that adding the nuget package Rx-Xaml includes the proper assemblies for the scheduler, etc. Details can be found on the main Rx blog. Of course, my app is back to hanging now, but that may be due to something else dumb on my part.
It seems like a fairly large hassle to set up a proper debug environment in ASP.NET and I'm just wondering if using Asserts are the way to go or not. I've read a bit and saw that you need to modify your web.config to properly use Asserts. Is this usually the best way to go or are there other methods of debugging that might be easier to use?
We don't use a unit testing framework so that isn't really relevant to the question.
How do you know the difference between them working properly or not working at all? Currently I can put in asserts in my code and it will do absolutely nothing because they are not configured in the web.config. This seems dangerous to me.
I would direct you here: When should I use Debug.Assert()?. There are several good answers that can tell you when it's good to use them, and you can figure out from there if it's worth it in your app.
Having Debug Asserts will ensure your code is correct. With the right combination of test cases will definitely help you.
Several Unit test frameworks come with handlers that can log messages and throw exceptions on asserts. Choosing one of these framework or writing your own handler is something that you may have to think about. But once the Unit test code catches these exceptions, they should be logged and marked as failed.