require('./foo.css'). That said I am sure that eventually css will be obsolete for TS / React projects and thus I'm focusing on a great TS only experience :rose:
// Images.ts
// Faux types to achieve type safety at assignment
export declare class ResourceImage {
type: "resourceImage"
}
export declare class ResourceIcon extends ResourceImage {
subtype: "resourceIcon"
}
export declare class ResourceBigIcon extends ResourceImage {
subtype: "resourceBigIcon"
}
export const closeIcon: ResourceIcon = require("./close-icon.svg");
export const someOtherIcon: ResourceIcon = require("./some-other-icon.svg");
// ... list of all images
// Then use like this
import { ResourceIcon } from "./Images";
export class Button extends React.Component<{
icon?: ResourceIcon
}, {}> {
}
// This forces the users of the Button to import icons
import { closeIcon } from "./Images";
<Button icon={closeIcon} />This forces the users of the Button to import icons
Users will not get a good error message though. and they can give it {type:'resourceImage',subtype:'reousrceIcon'} object instead of an actual icon (at least thats what the error will guide them to)
@basarat, actually it's only about the first load on the tree that annoys me. The project I work is an Angular 2 app with multiple components (a few hundreds, maybe) and the list of dependencies in node_modules is something of 400 or such.
The other reason is that my expectation is to use alm to build a live demo of our controls lib, so other devs can try out our styles and controls coding, etc. but I want to make sure they see only what I want them to see, then edit everything on browser, build that also on browser and finally display that in another panel on the right. Very similar to plnkr, but I cannot use plnkr as the project is still very private. So, being able to manipulate the tree is a need.
The project I work is an Angular 2 app with multiple components (a few hundreds, maybe) and the list of dependencies in node_modules is something of 400 or suc
@marinho Perhaps you might not know of these features:
- The files that are in the compilation context are colored green. Everything else is pseudo noise as far as TypeScript is concerned.
- There is also project filepath search which only filters the same files (files in the compilation context).
That should reduce some of the noise
https://github.com/driftyco/ionic-site/pull/780#event-796252124
cheers, i love your project.
alm -o . run Chrome rather then Edge on Windows 10.? I'd rather not change my default browser, but Chrome seems to run alm better in the zoomed-in mode I need to read comfortably.
can I run my script directly in ALM and see the console output?
Not quite. You can however run a ts->js conversion and see the output in the dev tools console. with Ctrl|⌘ + M. Covered here : https://basarat.gitbooks.io/alm/content/features/build.html :rose:
Is there a way I can make alm -o . run Chrome rather then Edge on Windows 10.? I'd rather not change my default browser,
Sadly you have to. open chrome url didn't work reliably on all OSSes and would crash silently if user didn't have chrome, so I just send open url to all OSSes and the OS load the default browser : https://github.com/alm-tools/alm/blob/f3c89d0a69fbb0e62e203b5de7d55ea8e006bceb/src/server.ts#L134-L136
const user = observable({
userName : ""
});
setTimeout(() => {
user.userName = "Jack"
}, 3000);
@observer
class SomeComp extends React.Component<any, any> {
render() {
return <div>
{user.userName}
</div>
}
}
.editorconfig before writing to disk. But keeping the in memory version of the contents unchanged