restrictMovementArea didn't seem to work

[staltz]

If you take the example in cyclejs/examples/http-search-github, I tried to add this library by including this line:

  // Convert the stream of HTTP responses to virtual DOM elements.
  const vtree$ = sources.HTTP.select('github')
    .flatten()
    .map(res => res.body.items)
    .startWith([])
    .map(results =>
      div([
        label('.label', 'Search:'),
        input('.field', {attrs: {type: 'text'}}),
        hr(),
        ul('.search-results', results.map(result =>
          li('.search-result', [
            a({attrs: {href: result.html_url}}, result.name)
          ])
        ))
      ])
-   );
+   ).compose(makeSortable(sources.DOM, { restrictMovementArea: '.search-results' }));

Apparently it added .x-sortable-item to all of the elements under the div. I would expect only li elements under ul.search-results would get the .x-sortable-item.

[jvanbruegge]

at the moment it makes all children of a given vnode sortable, in your example you would have to branch out the ul, compose the makeSortable with that and merge them back together
Specifiying a subnode is a feature I have to add.

So you can only restrict the items to a parent component of them

[staltz]

The less we have config options and the more we have smart defaults and "just works", the better. Maybe most of the options could be removed, and maybe some option can be used to specify a section where to apply makeSortable.

[jvanbruegge]

Yes, I agree, the less options there are, the less I have to maintain.
There are basicly two possible views:

• Make the children of the top VNode sortable, option to restrict movement to a higher VNode
• Make the children of a selected VNode (through options) sortable, restrict movement to top VNode

Currently it's the first Version.
Both have pros and cons:

• The first one does not need options to work, but the restriction would not work when using isolate and not the top VNode.
• The second one has to have an option to specify the sortable (although this could default to the top VNode, eliminating that con), but using isolate would not be a problem.

At the moment I'm in favor of the second version.