What should be here?

[leeoniya]

This repo will be home to official widgets / reusable components that carry a domvm dependency.

• I am currently working on a stacked-modal component with configurable in/out transitions. This will be something that can easily replace native alert() confirm() prompt() - like https://github.com/alertifyjs/alertify.js and also jquery's blockUI (but per-element as well as whole-window)
• Afterwards i want to make a slider/gallery component like [1] that can be seamlessly used within the content of the stacked modal widget. This results in an easily composable lightbox.
• Some of the demos already written [2] could be good starting candidates for others: date picker, auto-complete/list-filter, checklists, accordions, infinite-scroll w/ajax, drag/drop things, form validation/building, off-canvas multi-view nav, responsive mediaquerylisteners, etc etc..

I'd like to have some non-trivial and useful implementations here which reduce the need to re-invent proper hook setup and node patching sequences, and promise setup. The widgets should be pretty useful, flexible/unopinionated, easily fork-able/hackable.

If you guys make something you feel is generally useful for others and are willing to MIT-license it, please pull-request to discuss.

[1] https://github.com/leeoniya/domvm/issues/32 [2] https://github.com/leeoniya/domvm/tree/master/demos

@lawrence-dol @iamjohnlong

[l-cornelius-dol]

This is probably where I'll be able to contribute much more, since I build such things habitually as I code.

One major difficulty I foresee will be isolating such things from other generic utilities which I don't want to publish / commit to maintaining with a frozen API.

I can pretty much guarantee none will like my coding style since I indent closing parens to the same level as the code block they close and use consonant-oriented 3 letter abbreviations at the function level (argument and internal vars). But hey, I write good code, by and large, and you can't complain about free, right?

[leeoniya]

complain i cannot. but a uniform coding style and decipherable variable names is kind of a must for any officially sanctioned widgets. the goal is for these widgets to be starting points for hacking and adding more functionality in your own app code. it is not meant to be a kitchen sink of black boxes. each widget will need to have its own readme and API docs. i will come up with a template when i make some initial widgets that others should use.

along the same lines, i plan to write some form of issue reporting guidelines. for example, adhering to the naming and style conventions that match the documentation. i find it cognitively more difficult to follow your code snippets, for instance where you have chosen to shorten all variable names to 3 chars and renaming things like "vm" to "dva". my time and willingness to assist is far from unconditional (such is the nature of open source, pro-bono work)

all code contributed here (or to the core) will have to be reviewed by me to ensure it is idiomatic and at least mostly understandable. having to grok and rewrite people's contributions is not what i have in mind for future domvm maintenance.

[l-cornelius-dol]

What's the status of support for integrating, say, pikaday.js? Is this just a guarded empty top-level div and then business as usual? I ask, because that's one component I integrated into Mithril and it was, at the time, reasonably difficult to do. But a date-picker and a time-picker are two things I don't particularly care to write from scratch.

Though if I do, I will definitely reformat to whatever standards you require and contribute it here.

Are you interested in dependent integrations like this as widgets. I think it would not take long for me to convert what I did for Mithril.

[leeoniya]

@lawrence-dol

First the bad news:

_guard isn't implemented yet, though it's top priority for v1.1.

Now the good news:

As luck would have it, i've already done most of the leg-work for a day-picker widget [1] [2] which is easily hackable. I don't know what specific pikaday options you're using in your apps, but the gritty calendar rendering logic & day selection works well (from my non-exhaustive testing). Additional features should be easy to add in.

I trust that you can handle making/adding a time picker ;)

[1] https://leeoniya.github.io/domvm/demos/calendar.html [2] https://github.com/leeoniya/domvm/blob/master/demos/calendar.html

[leeoniya]

@lawrence-dol

v1.1.0 is tagged

_guard is dead; long live insertion of pre-existing elements: https://jsfiddle.net/gtgau73j/

You can insert existing elements (maybe created by external libs) into domvm templates and they should work normally. In addition (and you could always do this before), you can have domvm's template create the container or target element, and then manually modify its contents or target it using an external lib. domvm only ever diffs/patches things that are defined in the tpls, so it will not touch externally added properties or content.

cheers!

[l-cornelius-dol]

Cool!