AngularJS allows the use of finally after the return of a promise. However, when I have a grunt-jshint running I keep getting
Expected an identifier and instead saw 'finally' (a reserved word).
Does any one know how to turn this off in jshint?
es5 option
This option enables syntax first defined in the ECMAScript 5.1
specification. This includes allowing reserved keywords as object
properties.
If you are using a version of jshint prior to 2.0.0, then you have the option of setting an es5 flag. Starting with 2.0.0, es5 is the default. I assume you are using an older version.
Alternatively
You can also say promise['finally'](function(){}); rather than promise.finally(function(){});
See
http://jshint.com/docs/options/#es5
https://jslinterrors.com/expected-an-identifier-and-instead-saw-a-a-reserved-word
http://jshint.com/blog/2013-05-07/2-0-0/
Related
I come from Angular where there you have the possibility of calling a property like this: object?.property.
If the object is null your app then not breaks down but it performs like an inline if-statement. As far as I know it is angular specific.
Does anyone know how this "ternary" is called?
Can one use this syntax in React?
Help would be appreciated
Yes the same is called Optional chaining operator. It is not angular specific. In case your react app uses typescript with a version 3.7 and above, you might as well go ahead and use it.
Check these articles as well :
https://dev.to/akirautio/optional-chaining-with-react-2l28
How to enable optional chaining with Create React App and TypeScript
Usage something like this:
let author = book?.author?.name;
This is a feature coming up in one of the next versions of ECMAScript. You can already use this, but you will need change some configurations to be able to use it. See the article by John Au-Yeung here: https://dev.to/aumayeung/how-to-use-the-optional-chaining-operator-in-your-react-app-right-now-1ocj
I'm trying to inline-bind my functions using this kind of syntax:
onChange = () => {
}
However, my sublime editor isn't correctly highlighting it:
I'm using the Babel package for sublime for syntax highlighting.
Does anyone know how to make it recognize this sort of style?
Check this
View -> Syntax -> Open all with current extension as... -> Babel -> Javascript(Babel).
or
Ctrl - Shift - P, type "Babel" and select Set Syntax: Javascript(Babel)
Source
ST3 relies on language definitions for providing language features such as code folding, syntax highlighting etc. However, with JavaScript, you have many different flavors of the language - like ES5, ES6, JSX etc. To correctly understand and parse each one of them is not easy given ST3's design (using a language definition file which is mostly regex matching).
So depending on what you're looking for, you may want to install JavaScriptNext - ES6 Syntax which helps ST3 better understand the language and its syntax. There are few others like these on marketplace if I'm not mistaken.
Then comes the notion of syntax highlighting - again, without the core editor natively understanding what's JS and what's JS-like out, these plugins are dependent on how good the language definitions are and so, have one or more shortcomings. There are a few options that you can try and see what suits best:
naomi - Enhanced syntax definitions for Sublime Text 3. Supports stage-0 features
babel-sublime - Syntax definitions for ES6 JavaScript with React JSX extensions. But has some issues with arrow functions, see #301
sublime-react - It's actually deprecated in favor of babel-sublime but you may want to check it out.
Whatever you choose, you need to do some due diligence. Check with their issue lists, see if anything stands out to you. Relying on transpilers can only go so far.
As a long time ST3 user, I've constantly found one or more issues. And depending on whether you're working on pure JS, or React, you may have to keep switching or accept some compromises.
Ultimately, I switched to VSCode (tried Atom too) which understand the language and it's flavors natively and provides extensions API that authors can build upon. Consequently, the syntax understanding and highlighting capabilities are far greater than what you can get out of ST3 + Extensions.
The only solution that comes to mind is to create a custom snippet, for Sublime, to "recognize" the arrow function or in general the reduced syntax to declare a function.
Here are two links that could be useful:
https://medium.freecodecamp.org/a-guide-to-preserving-your-wrists-with-sublime-text-snippets-7541662a53f2
and
https://gist.github.com/LeZuse/2324352
or
https://gist.github.com/ZYinMD/860926a178ccd6d107ffe2c6727b5845
I am in the process of testing the release build of a react native app and found that the minification process is breaking the xml parser library. In this case, there is a [ReferenceError: Can't find variable: dc], which I found out by diving through the minified bundle and logging, to be related to the above referenced library.
Is there a way to disable minification only for this library?
Also, would this be the best approach to tackle this kinds of minification problems?
Disable minification for React App
What is the current behavior?
When bundling production builds for React Native, names are mangled by default. This can break code (if it relies on Function.name) and the issue is kinda hard to track down (especially if the code accessing Function.name is deep into your dependency tree).
What is the expected behavior?
There should be at least an option to disable mangling, but I believe ideally it should be opt-in rather than opt-out. (Since it can break code in unpredictable ways)
For now relying on manually patching minify.js
Solved by disabling mangling:
Prevent UglifyJS from changing function argument names.
According to the documentation you can use mangle options to do that:
mangle (default true) — pass false to skip mangling names, or pass an object to specify mangling options.
Object options:
except - pass an Array of identifiers that should be excluded from mangling
toplevel — mangle names declared in the toplevel scope (disabled by default).
eval — mangle names visible in scopes where eval or with are used (disabled by default).
keep_fnames - default false. Pass true to not mangle function names. Useful for code relying on Function.prototype.name.
in node_modules/metro-bundler/src/JSTransformer/worker/minify.js
function minify(filename, code, sourceMap) {
const minifyResult = uglify.minify(code, {
fromString: true,
inSourceMap: sourceMap,
outSourceMap: true,
mangle: false, // ADD THIS LINE
output: {
ascii_only: true,
screw_ie8: true,
},
});
})
OR
May be your issue is due to the combination of running webpack -p and using Uglify Plugin.
Try omitting -p when running build and use uglify plugin, might this fix your issue.
I have created a single jar for Java 7 & 8 for a JDBC driver (using -source/-target compile options). However, I am having difficulty compiling applications that use the new/overloaded methods in the ResultSet interface:
//New in Java 8
updateObject(int columnIndex, Object x, SQLType targetSqlType)
// Available in Java 7
updateObject(int columnIndex, Object x, int targetSqlType)
Note that SQLType is a new interface introduced in Java 8.
I have compiled the driver using Java 8, which worked fine. However, when any application using the driver accesses the method updateObject(int, Object, int) from Java 7, it gets a compilation error saying “class file for java.sql.SQLType not found”, although the application is not using SQLType. I think this is because Java looks at all the overloaded methods to determine the most specific one, and when doing so it can not access the new updateObject method in Java 8 (as SQLType is not defined in Java 7). Any idea how I can resolve this issue?
Note that the updateObject method has a default implementation in the ResultSet interface in Java 8 --- so I can not even use a more generic type instead of SQLType in the new method. In that case any application that uses the new method gets a compilation error saying updateObject is ambiguous.
You can't use something compiled in Java 8 (for instance) in a lower version (say Java 7). You will get something like Unsupported major.minor version.... You need to use two JARs, one for version 1.7 and the other one for version 1.8. Eventually, the one for the 1.7 can't have that SQLType if it's not supported on that JDK; on the other hand, you are encouraged to maintain the overloaded version when you do the 1.8 version.
Notice that this doesn't have nothing to do with backwards compatibility.
In this case, I would call it the application’s fault. After all, your class is implementing the ResultSet interface and applications using JDBC should be compiled against that interface instead of your implementation class.
If a Java 7 application is compiled under Java 7 (where SQLType does not exist) against the Java 7 version of the ResultSet interface, there should be no problems as that interface doesn’t have that offending updateObject method and it doesn’t matter which additional methods an implementation class has. If done correctly, the compiler shouldn’t even know that the implementation type will be your specific class.
You may enforce correct usage by declaring the methods of your Statement implementation class to return ResultSet instead of a more specific type. The same applies to the Connection returned by the Driver and the Statement returned by the Connection. It’s tempting to use covariant return types to declare your specific implementation classes but whenever your methods declare the interface type instead, you are guiding the application programmers to an interface based usage avoiding the problems described in your question.
The application programmer still may use a type cast, or better unwrap, to access custom features of your implementation if required. But then it’s explicit and the programmer knows what potential problems may occur (and how to avoid them).
I used "com.google.appengine.repackaged.com.google.common.hash.Hashing" in my project so far, but since a while I get "Use of com.google.appengine.repackaged may result in your app breaking without warning" error. What is best to use instead?
I used guava library com.google.common.hash.Hashing. It worked.