my team is working on project using Angular 1.5.* + typescript.
Can someone give me advice for best TSLint configuration for such project as mine?
I want now to add TSLint config ( https://github.com/Microsoft/TypeScript/blob/master/tslint.json) from official TS repo and with ESlint rules set. https://github.com/Microsoft/TypeScript/blob/master/tslint.json
Will it be enough? What do you think?
Thank you in advance for your answers.
Will it be enough? What do you think?
Personally I don't switch it on till it becomes a problem. Fortunately I have the luxury of having my team mates respect and love so they know I mean well.
You can pick that one or just go with :
{
"extends": "tslint:recommended"
}
To use palantir defaults: https://github.com/palantir/tslint/#configuration
I'm in a similar situation. I used tslint-microsoft-contrib as a baseline.
"extends": "tslint-microsoft-contrib",
It definitely helps in all the ways you'd expect. However, some rules need to be reconfigured or turned off for AngularJs TypeScript code. I made the following configuration changes to function-name, member-ordering, no-import-side-effect, and no-unsafe-any:
"function-name": [
true,
{
// allow public methods to start with $ for $onChanges
// and other Angular lifecycle hooks
"method-regex": "^[a-z$][\\w\\d]+$",
// otherwise unchanged
"private-method-regex": "^[a-z][\\w\\d]+$",
"protected-method-regex": "^[a-z][\\w\\d]+$",
"static-method-regex": "^[A-Z_\\d]+$",
"function-regex": "^[a-z][\\w\\d]+$"
}
],
// Variant ordering that places public statics before constructor
// So we can place AngularJs $inject just before the constructor
"member-ordering": [
true,
{
"order": [
"public-instance-field",
"protected-instance-field",
"private-instance-field",
"public-static-field",
"protected-static-field",
"private-static-field",
"constructor",
"public-static-method",
"protected-static-method",
"private-static-method",
"public-instance-method",
"protected-instance-method",
"private-instance-method"
]
}
],
// angular.module(...).component(...) is a side-effect
"no-import-side-effect": false,
// ng.IController, among others in #types/angular, uses "any"
// and is flagged by this rule
"no-unsafe-any": false,
Depending on how you define AngularJs components, you may not need to set no-import-side-effect to false. I've not seen any consensus on the best way to define AngularJs components in TypeScript, which is a shame given that this is listed as step 1 for migrating from AngularJs to Angular 2+.
Sadly, this is missing out on the possibility of custom tslint rules for AngularJs to match best practices. I'm toying with the idea of running eslint-plugin-angular on the generated code, or converting those rules to TypeScript. But the better solution may be to migrate to Angular 2+ and use
codelyzer.
Related
just starting with react. I have a question about #HostListener from angular. Can I use that in React? If yes, what is the correct syntax?
I tried to check my method, please look at the following snippet:
#HostListener('document:fieldInput', ['$event']);
fieldInput() {
console.log(fieldInput); }
Further I get this error message. Experimental support for decorators is a feature that is subject to change in a future release. Set the 'experimentalDecorators' option in your 'tsconfig' or 'jsconfig' to remove this warning.ts(1219)
I am coding in .js instead of .ts
My reactjs app consists of a bunch of typescript files with a clean separation of GUI and model. The webworker needs most of model files, so maybe half of all files. I could imagine loading the webworker from exactly the same URL as the app as the model does reference neither the GUI nor React nor other unavailable stuff (At least, it shouldn't, and if so, it'd easy to clean it up).
There seem to be some problems:
finding the correct javascript files
injecting proper start up code into them
and probably others I haven't thought about yet.
The communication to the webworker is not a problem as all I need is a single async call passing and receiving some simple data.
There may be more issues like e.g., https://github.com/microsoft/TypeScript/issues/20595.
Before I learnt what I really need, I tried e.g., ttps://www.npmjs.com/package/#koale/useworker, which is nice, but seems to be able to deal with plain javascript dependencies only.
Finding the correct javascript files
What I can see in index.html is
<script src="/myapp/static/js/bundle.js"></script>
<script src="/myapp/static/js/0.chunk.js"></script>
<script src="/myapp/static/js/main.chunk.js"></script>
<script src="/myapp/main.4e45e2b4b645351b7733.hot-update.js"></script>
I guess, I could live without hot updates, however the names of the other three files change in production to something like "/myapp/static/js/2.28cf00cf.chunk.js".
Injecting proper start up code into them
When the worker loads, it executes some webpack code generated code which most probably crashes it. I'd need to avoid it somehow.
The questions
Is this doable at all?
Does it make sense or is there a better approach?
For a seamless integration of worker code with main-thread code, I recommend using comlink-loader. For example, if you have a main.ts file and a thingy.worker.ts file, you could seamlessly load it as a worker by using TS imports:
// main.ts
import { getThing } from "./thingy.worker.ts"; // make sure the file name ends with .worker.ts
async function test() {
console.log(`the thingy is: ${await getThing()}`);
}
// thingy.worker.ts
export async function getThing() {
return 3;
}
You'll need to add it to your webpack config like this:
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /\.worker\.(js|ts)$/i,
use: [{
loader: 'comlink-loader',
options: {
singleton: true
}
}]
}
]
}
}
The best part is that your editor's intellisense will work across modules and type safety will not be compromised. More documentation is available here.
You need to compile a separate js file for your WebWorker. There is a React lib called react-webworker that makes this easier for you. It in turn uses WebPack’s worker-plugin.
I've gotten used to using slim and jade and I recently moved to writing applications on the front end with React and find that now I'm writing bloated HTML again inside my components. I'm currently using Ruby on Rails and .jsx files with babel, etc using:
gem 'react-rails', '~> 1.4.0'
gem 'react-router-rails', '~>0.13.3.2'
But I'm also using React with node and express using the react-starterify boilerplate and it's the same story with Node.
Is there anything that can allow me to start writing my html in React using a syntax like slim or Jade?
One thing to keep in mind is that JSX isn't HTML—it just looks like it. This is important because the JSX transpiler (usually Babel these days) takes the JSX syntax and modifies it from this:
<div className="container">
<p>Testing!</p>
</div>
to something like this:
React.createElement("div", { className: "container" },
React.createElement("p", null, "Testing!")
)
By abstracting over React.createElement calls, you can end up with a project like r-dom, which does the same thing but with a nicer syntax:
r.div({className: 'container'}, [
r.p('Testing!'),
])
or react-hyperscript, which allows an alternative syntax for some properties:
h('div.container', [
h('p', 'Testing!')
])
However, since JSX turns into plain JS calls, any language or syntax that can be converted into React.createElement calls will work great with React, as long as you set up your Rails asset pipeline so that it correctly does the transpilation as part of serving assets.
There is a project that does this with Jade's syntax called react-jade; there are a few differences from regular Jade and some unsupported features, but it may do what you want it to do. In a Rails project, you'd need to find or create a preprocessor that turns the appropriate Jade code into React-specific JS.
There's one other thing I wanted to mention based on a comment in your question:
now I'm writing bloated HTML again inside my components
If you're just talking about HTML's syntax then no problem, but if you're finding that the render methods of your React components are getting large and hard to manage, then it's probably a good sign that you need to break your component into smaller components (see "Tip 4: Embrace composition!" at this link).
So I've inherited this extjs 4.1.3 project and I'm trying to understand it.
I've noticed that there are both Ext.require and Ext.define requires EVERYWHERE. The code is made of a lot of boilerplate code from sencha docs and I feel there is a lot of redundancy. It makes a whole lot of clutter and I feel like its wrong that when I add a file, I have to add it more than once (to Ext.require and Ext.define requires).
Couple of questions:
1) How can I tell if a require is actually ... required? From my understanding, it only tells the web page to load something now or later (this might be related to question 3). Am I guaranteed to see warnings from Ext saying "you should include abc" if those files are needed?
2) Is there any difference between Ext.require and Ext.define requires? Do I need both? If I only need one, is one more "standard" than the other?
3) What exactly does "Ext.Loader.setConfig({enabled: true});" do? I am guessing that lets ext dynamically load things if I don't specifically require them. Shouldn't I not need requires at all then? I'm not saying this is good practice, but is it true? Actually, if anything, isn't using this bad practice? You'll end up losing track of dependencies if you don't have them written down. Or do you "trust" Ext.Loader to take care of everything relating to dependencies so that you don't even have to worry about it.
The reason I ask because I thought this was true, but after the below experience, I am thinking it is not.
I thought I figured this out, but apparently my interpretation of Ext.Loader (Question 3) is wrong because if I comment out all of my requires, I get
[07:15:05.577] Error: [Ext.createByAlias] Cannot create an
instance of unrecognized alias: layout.border
If I take out 'Ext.layout.*. How come this isn't loaded dynamically if have Ext.Loader.setConfig({enabled: true})?
TLDR: I don't know when it is safe/good practice to use Ext.require/Ext.define requires. If I don't see any warnings and my app works, does that mean I'm good or is there still a chance something is being "loaded" as well as it could be? And what does Ext.Loader.setConfig({enabled: true}) do?
EDIT: Here is an example: the app.js file. It just feels to wordy doesn't it?
Ext.Loader.setConfig({enabled: true});
Ext.Loader.setPath('Ext.ux', 'ux');
Ext.require([
'Ext.layout.*',
'Ext.ux.*',
'Ext.grid.*',
'APP.controller.Controller',
'APP.view.MapPanel',
'APP.view.FilterPanel',
'APP.view.Viewport'
]);
var start_app = function() {
var app = Ext.application({
name: 'APP',
appFolder: 'app',
requires: [
],
autoCreateViewport: true,
uses: [
'APP.controller.Controller',
'APP.view.MapPanel',
'APP.view.FilterPanel',
'APP.view.Viewport'
],
launch: function() {
},
controllers: [
'APP.controller.Controller'
]
});
}
In the above code you only need controllers:['Controller']. In turn, in the controller file you need views:[], stores:[] and models:[] depending on what you want the controller to pull from the server.
Another example: Let's say you code a grid and it uses number column, so you need requires:['Ext.grid.column.Number' in the grid config.
What I do is that I put there minimum I think is required, and then I watch the console. Either I get an error and I fix it or I get "Synchronous Loading" warning that I also fix.
For more details see: http://www.sencha.com/blog/countdown-to-ext-js-4-dynamic-loading-and-new-class-system
I'm working on UI testing an ExtJS web-app, and I'm a beginner.
I am trying to test the ExtJS widgets by using CasperJS/PhantomJS tool.
Also, I generate the required CasperJs script using Resurrectio and by making necessary changes to it.
Since ExtJs generates unique ids dynamically for the DOM elements that it creates, I want to know how to provide those ids in CasperJs script for testing.
For example, The following Casper Script was generated by Resurrectio:
casper.waitForSelector("#ext-gen1142 .x-tree-icon.x-tree-icon-parent",
function success() {
test.assertExists("#ext-gen1142 .x-tree-icon.x-tree-icon-parent");
this.click("#ext-gen1142 .x-tree-icon.x-tree-icon-parent");
},
function fail() {
test.assertExists("#ext-gen1142 .x-tree-icon.x-tree-icon-parent");
});
casper.waitForSelector("#gridview-1038",
function success() {
test.assertExists("#gridview-1038");
this.click("#gridview-1038");
},
function fail() {
test.assertExists("#gridview-1038");
});
Here #ext-gen1142 and #gridview-1038 are the ids dynamically created. How should one provide data in the tests? Is there any stub or mocking tools which works with ExtJs in the code to provide these ids at runtime during tests?
I came across SinonJS. Can it be used or Do I need to used CSS or XPath Locators as mentioned in this answer? How reliable it is to use CSS or Xpath Locators?
Thanks in advance!
Not so easy to answer this, but here a few thoughts...
Don't rely on generated IDs. Never. They'll change in moments you won't like and if you have luck very much earlier.
Your best friends will probably be pseudo CSS classes you attach to your components. You could also use IDs, but this is only reasonable when you have elements which occur only once in your page. If that is the case, they are very good anchors to start with selections/queries.
XPath with ExtJS is possible, but you have to carefully choose the elements. ExtJS is so verbose in generating little things so your paths can be quite complicated. And when Sencha drops support for problematic browsers (IE < 8) maybe they change their templates and your XPath doesn't find anything.
SinonJS is great. But it won't help you much in DOM problems. But sure you can use it in your tests. I suppose it will payoff most in testing parts of your controllers or non-trivial models.
Model your test components after your real UI components and screen sections. Don't just record a script. Test code should be engineered like production code. If you create reusable components of test code and logic, you don't have to fear changes. In the best case the changes in one component will only touch the testing code of that particular component.
I know you have ExtJS. But take some time to look at AngularJS and see how easy it can be to test all parts of a JavaScript web application. I'm not saying you should switch to AngularJS, but you can learn a lot. Have a look at Deft JS as it has many concepts which enhance testability of ExtJS applications.
I use Siesta for my ExtJs testing. It works amazingly good for all JavaScript (jQuery based and others), but is specifically designed for ExtJS/Sencha Touch.
It has the feature to combine CSSquery and ComponentQuery to select your elements I think that will fix a lot of problems for you.
In the paid version there is even a test recorder to record scenario's and use them for your tests.
Here's a demo
Here's some sample code:
StartTest(function(t) {
t.chain(
{ waitFor : 'CQ', args : 'gridpanel' },
function(next, grids) {
var userGrid = grids[0];
t.willFireNTimes(userGrid.store, 'write', 1);
next();
},
{ waitFor : 'rowsVisible', args : 'gridpanel' },
{ action : 'doubleclick', target : 'gridpanel => .x-grid-cell' },
// waiting for popup window to appear
{ waitFor : 'CQ', args : 'useredit' },
// When using target, >> specifies a Component Query
{ action : 'click', target : '>>field[name=firstname]'},
function(next) {
// Manually clear text field
t.cq1('field[name=firstname]').setValue();
next();
},
{ action : 'type', target : '>>field[name=firstname]', text : 'foo' },
{ action : 'click', target : '>>useredit button[text=Save]'},
function(next) {
t.matchGridCellContent(t.cq1('gridpanel'), 0, 0, 'foo Spencer', 'Updated name found in grid');
}
);
})