Can one stop "semantic ui" from writing info to the console? - javascript

Using semantic-ui: http://semantic-ui.com/
It writes all kinds of info to the console, not just when an error occurs.
Is there an easy way to stop it from communicating with the console?
I am writing a laboratory page for an Ajax API, and developers will look at their console on my page to see what's going on when some Ajax calls are made. I don't want to see un-related messages about semantic-ui from the semantic-ui framework.

Just turn off debug mode for modules you don't need debug. Example for module 'modal' below.
There are 2 ways:
1) Set default value for module. Place it at the start of your script (before usage of module):
$.fn.modal.settings.debug = false;
2) Set value for each case of module usage:
$('.modal').modal({'debug': false});
The same for every other semantic-ui module such as popup etc.

Related

Debugging a React app from console as if the console was the app itself

When I used to program with python I could run a python app and then execute methods and access variables of the app from within terminal. This was a great way to test things around.
Working on my JS app I often use console.log to try things out but I am looking for a way to try things without having to rerun the app each time. I want to be able to call any method / variable of my React app (including imported classes etc) from within console "at run-time".
Is this possible? If yes, how?
If not, what is the best alternative to switching between code and browser back-and-force to see the effect of certain changes console.log ?

How to get javascript variables in a debugger when using webpack

I am developing a react application with the bundler Webpack.
I would like to debug this application with a browser console (here i use chrome).
I have used source-maps and equivalent in my webpack config:
devtool = 'inline-source-map';
Now errors are displayed with the exact line of the original file.
The problem is that i want to access to live variables with the console.
So far I found two ways to display them:
1- Add a library in webpack.config.js
output: {
library: "lib"
},
export variable in the code export var foo = 34; and finally inside the browser console use lib.foo.
2- use breakpoint and access to variable set in the file
Is there another solution to access live variables?
Thanks
There are other solutions, but that means defining global variables and that should be avoided as it can have side effects in the code you're trying to debug, so you might run into problems that are not identical with and without exposing the variables, which makes your debugging experience very frustrating.
Using breakpoints is the best you can do for debugging purposes. The browser debuggers, especially the Chrome devtools, are extremely powerful and it's absolutely worth spending some time to get familiar with them.
Because pausing the app at every breakpoint you set for getting to a certain point can be tedious, you can use conditional breakpoints. One way is to use the debugger statement in your code, in that case you can guard it by any JavaScript you like, for instance this will only pause when the input to the function is 5:
function debug(input) {
if (input === 5) {
debugger;
}
// Other code
}
Another way is to add conditional breakpoints in the Chrome devtools. As you've configure source maps, you can set the breakpoints in the original source under Sources > top > webpack:// > .
To set a conditional breakpoint you simply right-click a line and choose Add conditional breakpoint... and enter the condition, e.g. input === 5. You can also Edit breakpoint... to change or add a condition to an existing breakpoint. For more information about breakpoints in Chrome see Pause Your Code With Breakpoints.
In the Sources tab you can also right click anywhere and Add folder to workspace so you can edit the sources directly and save the changes to disk (in older versions of Chrome it's a bit more complicated to add a folder to the workspace). To let Chrome know that the source maps of webpack correspond to your workspace, you can right-click any webpack source map and select Map to File System Resource... and you simply choose the correct file of the workspace. After that, all the sources of webpack should automatically be mapped to the correct files. Now you can set the breakpoints there and when you change something and save it (Ctrl + S or Cmd + S), webpack will recompile it. See also Set Up Persistence with DevTools Workspaces.
Sometimes setting a breakpoint might be too much effort for only getting values of variables. With just console.log you probably end up with a lot of different messages. To make it easier to find the messages you need, you can use console.group which lets you put messages inside a group, that can be expanded and collapsed. The groups can also be nested. Use console.groupCollapsed if you want the group to be collapsed initially.

Debug angular app from outside (browser console only)

I have this angular website which for some reason cannot be debugged when everything is concat together (not minified). Fo example, if I try to set a breakpoint, the breakpoint is placed somewhere else (at the bottom of an other file) :(
So, to overcome this I would like to set a breakpoint using the browser console (if possible of course).
In my current situation I need to set a breakpoint inside a service method. So I figured, I need the reference holding that service. But where does angular keep those. For example, I tried this
$> var myApp = angular.module('myApp');
$> debug(myApp.injector('someSevice').someMethod);
If this would work, I would expect the debugger to kick in when someMethod is called.
Here is an other failed attempt:
$> myApp.run((someService) => { debug(someService.someMethod)});
Any help on how to do this would be appreciated?
UPDATE: Find a way to access a service
$> angular.injector(['myApp']).get('someService').someMethod
However, in my case, this function is called initially only
If you're trying to debug a live production app, there might be a chance where the debug info is disabled for the website which is actually done to increase performance of the website. So use angular.reloadWithDebugInfo(); in console and then try to debug.

EmberJS Reset Warning: Library is already registered with Ember

Some background...
We have an ASP.NET app we're slowly converting over to EmberJS. We have a single Ember application we instantiate for certain portions of the site. As we migration pages they get routes in the Ember app. The goal is to have everything in Ember over time. In the interim, the user can click on links that take them back to ASP.NET portions.
Our issue is with resetting the state of the Ember app if the user either clicks back to go back into Ember or clicks on a new link that takes them back into the Ember portion.
We've tried calling .reset on the application, but doing so gives us an error saying the following. Our application is called ConsoleCli and not the standard App.
Library "ConsoleCli" is already registered with Ember
Moreover, we get the following error saying one of our modules has already been registered.
Cannot re-register: `location:history-js`, as it has already been resolved.
I tried wrapping my registration of the history module with a check, but that creates a whole other slew of errors
if(!application.__container__.lookup('location:history-js')){
application.register('location:history-js', HistoryJsLocation, { singleton: true });
}
I read https://github.com/emberjs/ember.js/issues/10310 and I think it means reset() is supposed to clear all registries once this has all been merged into the main branches.
Shouldn't called App.reset() right in the middle of using an EmberJS application just reset it with no issue?
Excuse my lack of understanding, we're just learning all of this as we go.
We're running the following versions
Ember 1.11.0-beta.2
Ember Data 1.0.0-beta.15
jQuery 2.0.3
TIA!
I think you might have run into this bug: https://github.com/emberjs/ember.js/issues/10310
Try the fix mutewinter suggests in that thread, it has worked for most people (involving myself).

How do I change the underlying Phantomjs object settings using Chutzpah?

We have some QUnit javascript tests running in Visual Studio using the Chutzpah test adapter. Everything was working fine until we changed our api (the one being tested by the js files) recently, and added some validations over the UserAgent http header. When I tried to update the tests to change/mock the user agent I realized it was not directly possible even by overriding the default browser property.
After a few days of scavenging, I finally found what exactly is happening. Chutzpah is creating a phantomjs page object for the test files to run on. This is being done on a base javascript file (chutzpahRunner.js) located at the Chutzpah adapter installation path. These are the last lines on the file, that effectively start the tests:
...
// Allows local files to make ajax calls to remote urls
page.settings.localToRemoteUrlAccessEnabled = true; //(default false)
// Stops all security (for example you can access content in other domain IFrames)
page.settings.webSecurityEnabled = false; //(default true)
page.open(testFile, pageOpenHandler);
...
Phatomjs supports changing the user agent header by specifying it in the page settings object. If I edit this chutzpahRunner.js file in my machine, and manually set the user agent there, like this:
page.settings.userAgent = "MyCustomUserAgent";
My tests start to work again. The problem is that this is not in the project itself, and thus cannot be shared with the rest of the team.
Is it possible to change the properties of the phantomjs objects created by Chutzpah to run the tests? I'd like to either change them from inside my own tests, or from another script file I could embed on the pipeline.
Without a code change in Chutzpah it is not possible to set those properties on the PhantomJS object. Please file an issue at https://github.com/mmanela/chutzpah asking for this functionality and then fork/patch Chutzpah to add it (or wait for a developer on the project to hopefully get to this).
Update:
I pushed a fix for this issue. Once this is released you can use the following in a Chutzpah.json file:
{
"userAgent": "myUserAgent"
}

Categories