Road to 1.0

Road to 1.0

My hope is to release a stable version by April 1st. This means no further breakage of:

• The published API (Docs)
• Defined behavior (Tests)

There’s a lot of work just in the above items for functionality that already exists in the lib. Since I’m currently the only dev, claims of IE9+ compat will have to wait till post-1.0 as I simply have no time to fix everything that might be broken in older browsers and vet all needed polyfills. If anyone cares to help with this, great. IE9+ is done!

Generally, I’m satisfied with the view and html modules’ semantics and performance at this point. However, there’s still some significant effort to be put into the route and watch modules. I’d prefer to stabilize each module indepedently, but this prevents offering a stable concat+min dist build that includes everything. I’m not sure what to do here, but either remove/re-branch some features that are experimental or simply leave them out of the docs; the latter would be simpler, but would bloat the lib size to a small degree to include codepaths that shouldn’t run.

Big-Ticket Items (besides more tests and docs)

• Hash-based routing interop, query params (https://github.com/leeoniya/domvm/issues/11#issuecomment-186761920) Done.
• Prop/attr magic (#18). Maybe needed for 1.0 since it affects ergonomics/expectations. Not sure if this magic should be opt-out or opt-in? If implemented, will need clear and simply-explained behavior plus tests to ensure it doesn’t do wonky things. Done.

Small-But-Necessary Items

• Event handlers can be arrays w/args: {onclick: [cb, arg1…]} Done.
• Ponder arguments & order provided to various callbacks and pass-through semantics.
  • view: Event handlers (delegated handlers should also get attachment node) Done: function(arg1..,e, node) where arg1.. only appears when using [cb, arg1..] style handlers.
  • view: Emit arg pass-through format vm.emit("myEvent", arg1..) or vm.emit("myEvent", args) Done: vm.emit("myEvent", arg1..)
  • view: Lifecycle hooks handlers and what’s valuable in each case? didMount/willRecycle/etc, oldNode, newNode
  • route: handlers (e, arg1…) how should this interop with named querystring params when implemented? Done.
  • route: rt.goto("routeName", args), same concerns as above, named vs ordinal? both can exist in URI. Done.
  • route: rt.href("routeName", arg1...) Done.
  • watch: allow setting a context for handlers (vm, vnode?)
  • probably more i’ve forgotten here

Maybe Items (probably post-1.0)

• Third-party lib interop (#7)
  • {_guard: true} for nodes
  • vm.absorb(vnode, el, props)
  • Accept existing DOM elements in tpl defs (assume guarded?)
• Optimization channel: allow vtree diff & re-build suppression for known-static trees at both self and children levels. Would just graft the old vtree branch to new.

@lawrence-dol @yosbelms

[leeoniya]

I’ve decided to postpone the completion of docs and tests till after 1.0. Hopefully i will get some help with these 😉

IMO there is an adequate combination of tests, benches plus feature-focused, non-trivial demos, such that their bug-free operation is a sufficient vote of confidence for 1.0. The API churn has settled at this point and aside from catching up watch.sync and re-validating Node/isomorphism, everything is in place for API freeze.

Another thing that won’t be fully tested is that all demos work flawlessly in all browsers. Polyfills/shims are not perfect and sometimes the way rAF queues and Promise resolution works is wonky. I will only validate that demos work in the latest browsers w/polyfills along will all core tests passing in IE9+.

[iamjohnlong]

👊 Good work sir!