issa marie tseng

Migrate off Coffeescript

1

This has been an eventual goal for years. It's just not the most important thing yet. But I should probably file this ticket just so it's on the record.

Most of the time when `_initialize` or `_wireEvents` are used, the reason is to write a series of `(…).get(…).react(…)` statements (or, more correctly, `this.reactTo(this.get(…), …)`). I dislike needing to actually...

Maybe: Pass Observation ticket as final arg of Varying#react

1

so that `this` binding is not required for `const`less context

Maybe: dollarless janus

2

This has been obvious for a long time now, I just want it down in writing. I didn't want to reimplement the low-level stuff but I also didn't want to...

DomView#subviews() List should update after #artifact()

2

right now if you do `domview.subviews()` before you call `artifact()` you get an empty List back. but then if you call `.artifact()` later, that list does not update with the...

Should App take resolver via a property rather than an override?

1

Might harmonize better with the way libraries are done.

[stdlib] Add bridge from Varying to various other common abstractions

1

eg: `Varying.asPromise(v).succeedIf(f).failureIf(f) -> Promise` Promises, Rx Observable, anything else that's popular and semantically harmonious enough can be considered. Probably rely on `peerDependencies` or dependency injection to keep our own dependencies...

Map/Model custom constructors break .with()

1

because it presumes the standard data/opts signature.

Maybe: restore IE support by using extendNew (instead of Object.assign)

2

Would rather not do this, but willing to revert the change if people need/want this. Consider this issue a ticket to vote on it.

This would _really really_ centralize all the magic into `App`. The main issues standing in the way are: 1. ~~`Model` `bind` should work without an App instance. This is the...