DefinitelyTyped Bacon.js
alexander-matsievsky opened this issue · comments
Good day!
As a big fan of Bacon, I recently started to cook a TypeScript definition file for the library.
The method was to go through the API Reference and extract the typings from there. However, I've encountered a significant problem of differentiating between Observable, EventStream and Property, for example, in Common methods in EventStreams and Properties, what started as
interface Observable<A> {
map<B>(f:(value:A) => B): Observable<B>;
}has turned to
interface EventStream<A> {
map<B>(f:(value:A) => B): EventStream<B>;
}
interface Property<A> {
map<B>(f:(value:A) => B): Property<B>;
}What I want to achieve
- A typesafe definition for Bacon.js (resolving the kind of problems described above);
- A comprehensive documentation for the library. Primarily for intellisense, but the possibility of JSDoc autogen is attactive as well.
What kind of help I'd be grateful to get
I would much appreciate a person with an familiarity with the library helping me figuring out the typings. Also, I think I've messed up some of the JSDoc syntax, would be nice to fix it.
The result
After achieving the above-mentioned goals, I'll push the definition to the official repo.
While going through this MD I've noticed things like
[observable.takeUntil(stream)](#observable-takeuntil "observable.takeUntil(@ : Observable[A], stream : EventStream[B]) : Observable[A]")
d.ts definition would formalize this ad-hoc typing.
You may have a look at this d.ts https://github.com/bodil/baconts/blob/master/src/bacon.ts.
Might be obsolete, yet still useful.
Might be obsolete, yet still useful.
Thanks for the link.
However, it has the same flaw as mentioned above.
It has
export interface Observable<T> {
map<U>(fn: (value: T) => U): EventStream<U>;
}which contradicts this description:
maps values using given function, returning a new stream/property.
The type definition language is a bit ad hoc, but it predates union types in TypeScript. It seems you can get quite close by substituting [] to <>. Yet in the documentation where functions are spread away from class, the type of this should be still visible somewhere.
@phadej Yes, I get it. Thanks for the comment.
I think I'll be able to figure out the correct types from API ref and the src.
I'll close the issue after pushing the d.ts to DefinitelyTyped repo.
It might make sense to change a scripts how README.md is generated, shouldn't be difficult to produce d.tsas another artefact. I could do a small experiment ASAP.
@phadej That's worth a try, thank you.
I'm working on the typings at the moment.
First I tried to model the Observable as
interface Observable<A> {}Then I realized that I need to account for Error
interface Observable<E, A> {}My question is whether there is a library method to transform error types?
interface Observable<E, A> {
transformError<E2>(f:(error:E) => E2):Observable<E2, A>;
}My understanding is that mapError behaves as follows
interface Observable<E, A> {
mapError<B>(f:(error:E) => B):Observable<E, A|B>;
}Type definitions have been pushed to the DefinitelyTyped repo.
Feel free to use, evaluate, improve!
@alexander-matsievsky where did your types go? the repo is gone.
@fatso83 Hi! It was moved one level down to types folder.
It actually seems like that will be quite superfluous in the near future 😄
@fatso83 Nice seeing the library which introduced me to FRP evolving+) IIRC I wrote these definitions for v0.7.77.