domvm: missing docs
Here is my (non-exhaustive) list of things to document. I will keep it updated as they are finished or as more are added.
API
domvm.utils.repaint(vnode)+ any other useful util methodsvm.patch()vm.patch(oldNode, newTpl)vm.patch(oldNode, {style:..., class:...})
vm.api(===thisin render() and init closure)domvm.view.extend(function(vm) {...})(view monkey-patching)vm.unmount()vm.mount(target, true)will treat target as root and clear it firstvm.update(newModel)forfalse-handle views (stateful slots)- namespaced refs:
_ref: "a.b.c"=>vm.refs.a.b.c - exposed refs (
_ref: "^moo")- using them for a restricted event bus/selective sub-view redraw
- node-level
_diff: [cmpFn, data1, data2]as alternative to splitting off sub-views & caching old values - vm-level
vm.diff(function(model) {return [model.data1, model.data2];}); - returning
falsefromrender()as sub-view perf optim (inactive sub-views, 0-diff) - explicit tagging of child arrays
kids._expl = true willUpdatevm hook- passing hooks into sub-view from parent via
opts ["p.moo", {class: "active"}is additive and results in<p class="moo active">watch,hooksandevctxparams in view opts- full sigs of all callbacks/user-supplied funcs
- examples of using
_data - entire
watchmodule- w.get/post/etc
- signatures
- success/error callbacks
- w.prop
- async props with initial values
- asyc prop.update()
- pass
falseto mutate without firing handler, or alternate handler middleWareparam for validation/value transforming
- w.sync
- w.fire
- w.get/post/etc
- todo: add vm.route.extend?
General
- explain what that vm is the lib’s native api portion of the ViewModel
- make it clear that all views require a single root node
- the fact that
nameand_refimplicitly set _key if not present - no need for explicit props of some common input attrs, like “.checked” etc…
- more detailed lifeycle hooks docs
- more routing examples
- document vtree/vm architecture https://github.com/leeoniya/domvm/issues/72#issuecomment-217569703
Footguns
- add section explaining handle/key and model persistence implications for state retention and DOM recycling #83
- if model is destroyed and recreated on every redraw() (like via JSON.parse), opt view out of persistence to ensure dom is reused rather than re-created:
[myView, tempData, false] - encourage use of sub-renderers to break up templates instead of sub-views when not necessary, since perf is better and nodes can carry persistent state via a combo of
_refand_data - explain that using _key is not a perf optimization and not required if model is persistent. and should be used only for json-style re-created data or to enforce destruction of state and prevent dom recycle.
- show that while viewFn (init closure) and render() sigs are the same, the former is immutable while latter is mutable in cases of non-persistent models via
vm.update(newModel)or[myView, newModel, false] - add section about ensuring that dynamic form elem props are always re-synced back to model
- dont re-create event handlers inline, pull them out of render()
- explain that dom event handlers have a sig of
handler(arg1..., e, node, vm)if defined asonclick: [handler, arg1, arg2], elsehandler(e, node, vm). - debugging slow perf using DOMInstr
- shorthand id/class attrs on elems must be in
div#id.class1.class2...order - more visible docs about explicit child array restrictions & work-around
mount(body, true)from in-body script, ensure to wrap inDOMContentLoaded: https://github.com/leeoniya/domvm/issues/56#issuecomment-213210948- avoid holding references to the
vm.refsobject to dom nodes #58
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Reactions: 3
- Comments: 29 (14 by maintainers)
v1.2.5 is out with the fixes.
https://github.com/leeoniya/domvm/issues/104#issuecomment-263949311
My concern is the devs new to domvm, since the default branch is 2.x and there isn’t a link to docs in the readme.md. I think domvm is a great work, it must be learned, used, shared, but newcomers could feel bashed by the missing docs.
no objections to splitting, but we should decide if the topics are split by complexity (which helps people learn), or by API (which helps with reference).
Personally I prefer to stick with the 80/20 rule, leaving the more nuanced parts for later while giving most users what they need to get pretty far before WTFs start to kick in.
That being said, I’d probably want to discuss how to use DOMInstr early rather than late so that people can understand how their view structure affects performance and recycling behavior. That way there are more people asking about why something is not working as expected and the lib can be refined for v2, or the docs can be tweaked to highlight common misunderstandings.