If you’re working on a web app in Visual Studio and want to launch it in Incognito mode to make sure you have a 100% reset state you can do this from the ‘Browse With…’ option which is next to the run button. From here you can add a browser with any supported launch switches you desire such as ‘–incognito’ (shown below) or perhaps ‘–disable-extensions’ to speed browser load time up.
Brotli can compress HTML, CSS and JS files more than Gzip. If you can’t enable Brotli compression on the server level but want to use it in your ASP.NET Core app you can use the response compression middleware to enable it from your Startup.cs file. Setup is easy and looks like below..
Note the app.UseResponseCompression() in the Configure method needs to be before app.UseStaticFiles() as otherwise headers have already been sent. The default setup above will use Brotli if the client supports it else it will use Gzip if it’s supported. By default the Brotli compression provider will be set to a compression level of 1 (fastest).
The compression level corresponds to how aggressive an algorithm will compress a document. Brotli has 11 levels, 1 being the fastest but least compressed and 11 being the most compressed but also the slowest. Brotli at its highest level (11) is extremely slow compared to Gzip at its highest level (9). Slow compression is fine for static CSS/JS files which we can compress ahead of time. For on the fly compression (eg. dynamic web pages) slow speeds can negatively impact web app performance..
.. for Brotli compression to be advantageous over Gzip we need to find the compression level which gives us the best balance between compression amount and speed..
If your outputting a list of checkboxes using CheckBoxFor from within a loop and are having problems getting the checkboxes to bind back when submitting make sure you are looping with a for loop rather than a foreach loop. This is because looping through a collection with a foreach loop will output the same name for all checkboxes which will be based on the name of the iteration variable (not the particular item in the viewModel collection) in your foreach statement and the name of the bool property and thus MVC will not find anything to bind to.
You can have multiple non nested forms all posting to different action methods from different submit buttons, you can also have multiple submit buttons posting to the same form and hence action method. In an MVC action method which is posted to by multiple submit buttons, how does one tell which button was responsible for the form post? Two easy ways are outlined on stackoverflow which I’m reposting as is here just to add a bit of extra ‘commentary’. Author is highlighted in yellow.
In your razor mark-up each submit button has a different name property. Since only the name of the button which caused the submit will be posted in the HTTP request header, in your action method you can check the Request.Form collection to see which submit button property name exists and take action accordingly. In this case you don’t have to change your action method signature and given that the value property of your submit buttons is insignificant to determining which button was pressed, all your submit buttons can have the same label/text if needs be.
In your razor mark-up each submit button has the same property name but different value, since only the name (and significantly value) of the button which caused the submit will be posted in the HTTP request header, you can add a property to your action method signature for MVC to bind to and populate. You can then check the value of that property and take action accordingly. This is the more MVC (and perhaps elegant) way I guess as your using default model binder rather than checking form collections directly, personally however I prefer the approach above as you don’t have to change the action method signature and the button test is not based on some visible on page property which could matter in some scenarios.
When using ASP.NET MVC sometimes after a request viewModel properties you expect to be binded and populated are not. For HTTP GET action methods debugging why this might be is easy as the params are visible in your URL. For HTTP POST requests the name/value pairs are sent in the header so they are not as easy to review.
One could use Fiddler or the Chrome/IE developer tools to look at the raw name/values pairs being posted across from the view but the Visual Studio Locals window gives you access to this information too. Just set a breakpoint in your action method and examine the current request object in the Locals window as shown below, the particular property you want to look at is Form. In the example below we can see the raw name/value pair string isSelectedCity=4&Country=United+States