Comments (20)
Please see the new dt-umd
branch.
from mithril.d.ts.
@spacejack You said that you would ultimately want a UMD version and a ES6 module version. Are you still aiming for that?
from mithril.d.ts.
I think what we want is this UMD version and a global version for scripts?
I'm going to try a global version that imports the UMD types then exports some customized global types so we don't have to copies of everything. Eg., building on this idea.
from mithril.d.ts.
Oops I think I missed your point... I suppose these types don't need to be UMD since they're not correct for global usage, they only need to work for module usage. So should probably remove the export as namespace m;
from mithril.d.ts.
That line means the difference between m.Comp
and Mithril.Comp
, right? Maybe it should be consistent in both versions. The latter seems to be a better option.
from mithril.d.ts.
Well the module version should be whatever name you use. So if you import * as m from 'mithril'
then everything is attached to m
. If you import * as mithril from 'mithril'
then it's mithril.Comp
etc.
For the global version, everything should be on m
because m
is the global exported from the mithril.js script.
I'm playing around with a global version of types, but can't quite get it to work... I was hoping something like...
import * as mithril from 'mithril';
import * as stream from 'mithril/stream';
declare const m: mithril.Static & stream.Static;
from mithril.d.ts.
Also trying this but it's not working, hmm...
import * as mithril from 'mithril';
declare namespace Mithril {
type Lifecycle<A,S> = mithril.Lifecycle<A,S>;
type Hyperscript = mithril.Hyperscript;
type RouteResolver<S,P> = mithril.RouteResolver<S,P>;
...
}
declare const m: Mithril.Static;
from mithril.d.ts.
All right, I think I have it. This seems to work:
// mithril-global.d.ts
import * as mithril from 'mithril';
import * as stream from 'mithril/stream';
declare global {
namespace Mithril {
type Lifecycle<A,S> = mithril.Lifecycle<A,S>;
type Hyperscript = mithril.Hyperscript;
type RouteResolver<S,P> = mithril.RouteResolver<S,P>;
...
type Stream<T> = stream.Stream<T>;
type Static = mithril.Static & {stream: stream.Static};
}
const m: Mithril.Static;
}
Then usage is:
// test.ts
let c: Mithril.Component<{},{}>
m(c, ...)
let s: Mithril.Stream<number> = m.stream(1)
from mithril.d.ts.
Ugh, no, we should be using UMD style for global usage. Sigh...
// mithril-global.d.ts
import * as mithril from 'mithril';
import * as stream from 'mithril/stream';
declare namespace Mithril {
export type Lifecycle<A,S> = mithril.Lifecycle<A,S>;
export type Hyperscript = mithril.Hyperscript;
export type RouteResolver<S,P> = mithril.RouteResolver<S,P>;
//...
export type Stream<T> = stream.Stream<T>;
export type Static = mithril.Static & {stream: stream.Static};
}
declare const Mithril: Mithril.Static;
export = Mithril;
export as namespace m;
Script usage:
// test.ts
let c: m.Component<{},{}>
m(c, ...)
let s: m.Stream<number> = m.stream(1)
Now you have minimal differences between script and module app code.
from mithril.d.ts.
How about importing with /// <reference path="..."/>
?
from mithril.d.ts.
I have created a new branch: dt-module which is now exclusively for module use. (This simply removed the export as namespace...
lines and updates the readme.)
On the mithril-global.d.ts
repo, I've created the branch dt-global. Installable with npm install -D github:spacejack/mithril-global.d.ts#dt-global
Finally, here is a test repo for the global types.
This repo includes a small but necessary additional types file in the case that you are writing modules but are including mithril.js as a standalone script file. See the test.ts file for notes on the nuances.
This accommodates all 3 forms of usage as best as I can see at this point.
Let me know if you think there are any possible improvements yet.
from mithril.d.ts.
@spacejack Looks great!
from mithril.d.ts.
Previously you'd indicated that mithril.d.ts was going to be moved into mithrild.js project itself, is that still on the road map?
from mithril.d.ts.
Hi @winksaville, sorry, plans have changed. We'll be submitting to DefinitelyTyped instead. It will be easier to maintain if the release cycles are decoupled, plus makes it easier to switch between type definitions if a user prefers.
These are the types that will be submitted: https://github.com/spacejack/mithril.d.ts/tree/dt-module
and for now can be installed with:
npm install -D github:spacejack/mithril.d.ts#dt-module
from mithril.d.ts.
from mithril.d.ts.
Mithril 1.1 was released today. I've merged the working branches into master for mithril.d.ts and mithril-global.d.ts. See the readmes in the respective repos for current install urls.
Time permitting, I'll try to prepare a PR for DefinitelyTyped tomorrow.
from mithril.d.ts.
from mithril.d.ts.
Well, trigger pulled! PR is here.
Had to make some organizational and config changes to conform to DT's repo. Would like to roll those changes back into this repo in order to make future work easier to create PRs for.
@winksaville It's up to you. I don't think there are any plans to change the definitions unless DT rejects us for some reason. So you should be able to simply switch your package.json to point from here to npm. I'm not sure how long it'll be before the new types appear on npm assuming the PR is merged, but I'm sure several days at least(?)
from mithril.d.ts.
from mithril.d.ts.
Types have been merged! You can now install from npm with:
npm install -D @types/mithril
from mithril.d.ts.
Related Issues (20)
- Add types of all html properties HOT 2
- m.request.config type HOT 6
- Lifecycle params for attributes have `this` set to the attrs object, not the state object.
- Cannot use m directly, m.default is required HOT 5
- Support for JSX out of the box? HOT 3
- Arguments when using m.route.link in <a> lifecycle method HOT 2
- Changes to file structure to also support using Mithril globally HOT 6
- Breaking `Stream` constructor when using optional value HOT 2
- ospec.d.ts HOT 6
- m.route.Link type issue HOT 1
- PSA: I've added a bunch of default community health files org-wide
- Why is `ComponentTypes` plural? HOT 4
- TypeScript: m.fragment without Attrs not allowed HOT 1
- Using Stream in a React project is complicated because of clashing Component definition
- Types for vnode style attribute
- Event binding & DOM property hints for `attrs` input HOT 4
- Child shouldn't allow null or undefined
- Is there support for TypeScript and JSX/TSX syntax? HOT 2
- Stream types have problems being inferred?
- m.request deserialize should be any not string
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from mithril.d.ts.